בליבת לינוקס תוקן מצב שבו משתמש אחד יכול לדעת מתי משתמש אחר קרא או כתב לקובץ מיוחד, גם כשאין לו הרשאת קריאה לאותו קובץ. לרשומה אין ציון CVSS, והתיקון עצמו קטן: הליבה מפסיקה לייצר התראות על הקבצים האלה. מה שמעניין כאן הוא איך הדליפה עבדה.
מה החולשה?
בלינוקס יש מנגנון שמאפשר לתוכנה לבקש שיעדכנו אותה כשקורה משהו לקובץ: הוא נקרא, נכתב, נמחק, שמו שונה. למנגנון הזה קוראים inotify, ולגרסה המורחבת שלו fanotify. עורך טקסט משתמש בו כדי לזהות שהקובץ שאתם עורכים שונה מאחור, וכך גם מערכות גיבוי וניטור.
ההרשאות שלו בנויות על כלל סביר: מי שאין לו הרשאת קריאה לקובץ אינו יכול להירשם להתראות עליו. אבל יש גם דרך שנייה להירשם, ובה רושמים תיקייה שלמה ומקבלים התראות על מה שקורה לקבצים שבתוכה. בשביל הדרך הזאת די בהרשאת קריאה לתיקייה, ולא לקובץ.
הדרך השנייה אינה פרצה בפני עצמה, ויש מאחוריה היגיון. מי שיכול לקרוא את התיקייה ממילא יכול להריץ על הקובץ פקודת stat ולראות בה את זמן הקריאה והכתיבה האחרונים שלו, ומהם להסיק מתי מישהו נגע בו. ההתראות אינן חושפות יותר ממה שכבר גלוי בלעדיהן.
כאן נכנסת לתמונה הקבוצה שבה ההנחה הזאת אינה מחזיקה: קבצים מיוחדים, כמו /dev/null והתקנים אחרים תחת /dev. בקבצים האלה זמני הקריאה והכתיבה אינם מתעדכנים כשמישהו קורא או כותב אליהם, אלא רק כשמישהו קובע אותם במפורש. כלומר ב-stat לא היה מה לראות, ובהתראות של inotify כן.
פער בין שני מנגנונים שהיו אמורים לחשוף אותו דבר.
ומה עושים עם פער כזה? הרשומה אומרת שהתיקון סוגר ערוצי צד שאפשר היה לנצל להוצאת מידע. ערוץ צד הוא דרך להעביר מידע דרך משהו שלא נועד להעביר מידע: שני תהליכים שאינם מורשים לדבר זה עם זה מסכימים ביניהם שכתיבה אל התקן מסוים בזמן מסוים מסמנת אפס או אחד, ואחד מהם צופה בהתראות במקום לקבל הודעה. הרשומה מפנה למאמר מחקר שבו המתקפות האלה מתוארות: המאמר על מתקפות דרך מנגנוני התראה על קבצים
התיקון מיישר את ההתראות לפי מה שפקודת stat מראה. על קריאה וכתיבה לקובץ מיוחד לא נוצרת יותר התראה למי שרשם את התיקייה, ועל קביעה מפורשת של הזמנים, דרך הקריאה utimensat, ההתראה נשארת, כי אותה גם stat חושף.
מי מושפע?
כל מכונה שמריצה ליבת לינוקס בגרסה שטרם קלטה את התיקון. הרשומה אינה נוקבת בטווח גרסאות, ומה שיש בה הוא ארבעה קישורים אל commit-ים בעץ היציב של הליבה, אחד לכל ענף שהתיקון נכנס אליו. הם מופיעים במידע הטכני למטה.
אבל השאלה המעשית כאן אינה איזו גרסה אלא איזו מכונה. הדליפה עובדת בין משתמשים על אותה מערכת, ולכן היא נוגעת למי שמריץ שרת או מכונה שיש בה יותר ממשתמש אחד: שרת שמתחברים אליו כמה אנשים, מכונה שמריצה קוד של לקוחות שונים, סביבה שיתופית באקדמיה. למי שמריץ מכונה שרק הוא עצמו נכנס אליה אין כאן תרחיש.
לרשומה אין ציון CVSS, וזה עצמו נתון שכדאי לשים לב אליו. בלי ציון אין את הסימון של מקומי מול רשתי ואין מדידה של רמת ההשפעה, ומה שנשאר להסתמך עליו הוא התיאור עצמו, שמדבר על משתמשים על אותה מערכת.
האם מנוצלת בפועל?
אין ידיעה על ניצול, ואין לחולשה רשומה בקטלוג ה-KEV שמנהלת CISA, סוכנות הסייבר האמריקאית, הרשימה של חולשות שנראה בהן שימוש בתקיפות אמיתיות.
במקרה הזה הרקע מסביר למה. התיקון לא הגיע בעקבות מתקפה אלא בעקבות עבודת מחקר, והוא מוגדר ברשומה כסגירה של ערוצי צד ולא כתיקון של באג שמאפשר השתלטות. ערוץ צד דורש בדרך כלל שלתוקף תהיה כבר דריסת רגל על המכונה ושיהיה לו מה להוציא דרכו, ולכן הוא מופיע בשלבים מאוחרים של תקיפה ולא בפתח שלה. זה אינו אומר שהוא לא חשוב, אלא שהוא אינו מה שמוצאים בסריקה רחבה.
מה עושים?
עדכנו את הליבה דרך מנגנון העדכונים של ההפצה שלכם, והפעילו מחדש אחרי העדכון. תיקון בליבה נכנס לתוקף רק אחרי אתחול, או אחרי החלה חמה אם ההפצה שלכם תומכת בכך, כך שעדכון שהותקן ולא אותחל אינו סוגר אותו.
כדי לבדוק אם הליבה שאתם מריצים כבר כוללת את התיקון, השתמשו בארבעת הקישורים ל-git.kernel.org שמופיעים ברשומה. כל אחד מהם מראה לאיזה ענף יציב התיקון נכנס ובאיזה commit, וזו הדרך להשוות אותו לגרסה המדויקת שההפצה שלכם מספקת. טווח גרסאות מסודר אין כאן, ולכן אין מספר אחד שאפשר להשוות אליו.
ותנו לעניין את הדחיפות הנכונה. אם זו מכונה עם משתמש אחד, זה עדכון שייכנס בתור הרגיל ואין סיבה להקדים אותו. אם זו מכונה משותפת, או כזאת שמריצה עומסים של גורמים שונים זה לצד זה, ההפרדה בין אותם גורמים היא בדיוק מה שהחולשה הזאת שוחקת, ואז כדאי להקדים.