בליבת לינוקס תוקנה חולשה שבה מנת רשת עם נתוני סיכום ביקורת פגומים, שהגיעה לרכיב ה-IPv4, מביאה את הפונקציה שמשלימה את הסיכום לשבש את כותרת הרשת של המנה. הציון הוא 9.3 מתוך 10. הרשומה אינה מונה גרסאות ליבה מושפעות, אלא מפנה לארבעה תיקונים בעץ הגרסאות היציבות.

מה החולשה?

כל מנה שעוברת ברשת נושאת איתה מספר ביקורת, סיכום של התוכן שלה שמאפשר לצד הקולט לזהות שמשהו השתבש בדרך. מערכות הפעלה מודרניות לא תמיד מחשבות את הסיכום הזה בעצמן. הן מעבירות את החישוב לכרטיס הרשת ומסמנות במנה את הנתונים הדרושים לכך, בהם המקום שממנו הסיכום מתחיל.

הרשומה מתארת מה קורה כשהסימון הזה שגוי. אם מנה עם נתוני סיכום פגומים נכנסת לרכיב ה-IPv4, הפונקציה שמשלימה את החישוב, skb_checksum_help, עלולה לשבש את כותרת הרשת של המנה ולגרום משם לשרשרת של תקלות. התיקון עצמו ממוקד: הוא בודק את הערך שמסמן מאיפה הסיכום מתחיל, לפני שהוא ניגש להשלים את החישוב.

הרשומה מייחסת את הגילוי ואת הדיווח למי שהיא קוראת לו Paulos, ומוסיפה שאחרים שחזרו את הבאג באופן עצמאי מאז.

ושווה לקרוא את מה שהמפתחים עצמם כתבו שם, כי הם לא מתארים את התיקון כפתרון מלא. לדבריהם מנות כאלה לא אמורות להיכנס לרכיב הזה מלכתחילה, והבדיקה שנוספה כאן היא שכבת הגנה נוספת בלבד. בדיקה מקיפה יותר בנקודת הכניסה, כך הם כותבים, עוד נדרשת ודורשת עבודה.

הדירוג מסמן גישה מקומית, בלי צורך בהרשאות ובלי פעולה של המשתמש, וגם שינוי היקף, כלומר הפגיעה חורגת מהרכיב שבו החולשה יושבת. השילוב של שינוי ההיקף עם פגיעה גבוהה בסודיות, בשלמות ובזמינות הוא מה שמייצר ציון 9.3 לתיקון שנראה בקוד כמו בדיקה אחת.

מי מושפע?

כאן צריך לומר במדויק מה הרשומה כן נותנת ומה לא. היא אינה מפרטת גרסאות ליבה מושפעות ואינה מונה מוצרים, וזה אופייני לרשומות שמגיעות מעץ הליבה עצמו. מה שיש בה הוא ארבעה קישורים לתיקונים בענפי הגרסאות היציבות. המשמעות המעשית היא שאי אפשר להכריע מהרשומה אם אתם מושפעים, והמקום להכריע הוא ההפצה שאתם מריצים.

ליבת לינוקס רצה על שרתים, על תשתית ענן ועל מכונות שמריצות מכונות אחרות. בישראל זה אומר בפועל את רוב השרתים של הארגונים ואת רוב מה שרץ בענן אצלם.

ומכיוון שהדירוג מסמן גישה מקומית יחד עם שינוי היקף, המקומות שבהם זה מטריד במיוחד הם אלה שבהם קוד שאינו שלכם רץ על אותה מכונה: מכונות וירטואליות של דיירים שונים, מכולות של לקוחות שונים, וכל סביבה שבה הגבול בין שני גורמים הוא הליבה עצמה.

האם מנוצלת בפועל?

אין דיווח מאומת על ניצול, והחולשה אינה בקטלוג ה-KEV של CISA, סוכנות הסייבר האמריקאית, שמרכז חולשות שיש עליהן עדות לשימוש בשטח.

ושווה להפריד בין שני דברים שקל לבלבל ביניהם כאן. הרשומה אומרת שאחרים שחזרו את הבאג בעצמם, וזה נשמע מדאיג, אבל שחזור של באג הוא לא ניצול שלו: זה אומר שהצליחו להגיע למצב התקול, לא שהצליחו להפוך אותו לכלי. המרחק בין השניים הוא בדיוק מה שהקטלוג מודד.

מה עושים?

1. בדקו איזו ליבה רצה אצלכם. בטרמינל הפקודה היא uname -r, והיא מדפיסה את מספר הגרסה.

2. התקינו את עדכוני הליבה של ההפצה שלכם, ולא מעץ הקוד. התיקון נכנס לענפי הגרסאות היציבות, וההפצות אורזות אותו לעדכון רגיל של חבילת הליבה.

3. אתחלו את המכונה אחרי העדכון. ליבה חדשה אינה נכנסת לתוקף עד אתחול, ומכונה שהתקינה את העדכון ולא אותחלה ממשיכה להריץ את הקוד הקודם. אם אתם משתמשים בתיקון חם של הליבה, ודאו שהתיקון הזה נכלל בו.

4. בסביבות שבהן מריצים מכונות וירטואליות או מכולות של גורמים שונים, הקדימו את המכונות המאחסנות על פני האחרות, בגלל שינוי ההיקף שהדירוג מסמן.

5. את ארבעת התיקונים עצמם אפשר לקרוא בעץ הגרסאות היציבות, למשל את הראשון שבהם, ומשם לראות לאיזה ענף כל אחד נכנס.