בקצרה: פגיעות חדשה בקרנל של לינוקס בשם BadGarbage (CVE-2026-53361) מאפשרת לכל משתמש מקומי כולל תהליך בתוך קונטיינר להפוך ל-root על המכונה המארחת. הפגיעות נמצאת ברכיב AF_UNIX, מנגנון ה-socket המקומי שמשמש כמעט כל תהליך בכל שרת לינוקס. קוד ניצול (PoC) ציבורי כבר זמין ב-GitHub ותומך ב-Debian, Ubuntu, RHEL 10, CentOS Stream ו-AlmaLinux. במאמר: מה קרה, מי חשוף, מה עושים, ולמה לקוחות SPD Kernel Shield לא נדרשו לעשות דבר.
הקדמה: "עוד פגיעות קרנל" עד שהיא מגיעה אליכם
אני מניח שחלקכם כבר נתקלו בכותרת "פרצה חדשה בקרנל של לינוקס" ופשוט גיללתם הלאה. בצדק. הן מתפרסמות בקצב מסחרר כתבנו על זה בדיוק כשיצאה OVSwrap לפני שבועיים, ולפני זה כשיצאה DirtyClone.
אבל BadGarbage שונה בכמה דברים, וכדאי לעצור עליהם:
- הרכיב הפגיע הוא AF_UNIX מנגנון סוקטים מקומי שנמצא בכל שרת לינוקס ללא יוצא מן הכלל. אין מודול שאפשר לשלוף, אין שירות שאפשר לכבות. הוא חלק מהליבה.
- PoC ציבורי עם תמיכה בהפצות נפוצות. לא צריך להיות חוקר אבטחה כדי להריץ את זה צריך shell על המכונה ו-
make. - בריחה מקונטיינר. תהליך שרץ בתוך Docker או LXC יכול לנצל את הפגיעות כדי לצאת מהקונטיינר ולקבל root על ה-host. בשרת שיתופי, זה אומר שלקוח אחד פרוץ = כל השרת חשוף.
אז בואו נעבור על זה בסדר.
מה זה BadGarbage בשתי דקות
הפגיעות נמצאת במנגנון Garbage Collection של Unix domain sockets הרכיב שאחראי לפנות סוקטים "יתומים" שנתקעו במחזורי הפניות שאף תהליך לא מחזיק בהם יותר.
הבאג: מרוץ תזמונים (Race Condition) בן 25 שנה
כשתהליך אחד מבצע MSG_PEEK (הצצה להודעה בלי לשלוף אותה) על file descriptor שעף בתוך סוקט, הוא לוקח reference שהאספן אף פעם לא סופר. במקביל, אם ה-GC רץ באותו רגע, הוא עלול לשחרר סוקט שעדיין חי ולהשאיר מצביע תלוי (dangling pointer) שהתוקף שולט בתוכנו.
ה-MSG_PEEK אמור לחכות כש-GC רץ הוא בודק דגל בשם gc_in_progress. אבל הדגל הזה נקבע מאוחר מדי בתוך הפונקציה unix_gc(). בחלון הזמן הקצר שבין הקריאה לפונקציה לבין הצבת הדגל, ה-peek מצליח לחמוק פנימה, והמרוץ פתוח.
אותה אינטראקציה בדיוק תוקנה שלוש פעמים בהיסטוריה:
- CVE-2021-0920 תיקון ראשון ב-2021
- CVE-2026-23394 תיקון שני מוקדם יותר ב-2026
- CVE-2026-53361 התיקון הנוכחי: להזיז את הצבת
gc_in_progressלתחילת הפונקציה
מ-use-after-free ל-root
ברגע שלתוקף יש use-after-free בקרנל, המסלול ל-root הוא הנדסה נקייה: לאתר את מבנה ההרשאות של התהליך בזיכרון הקרנל, לשנות את ה-uid ל-0, ולקבל שליטה מלאה. ה-PoC הציבורי ב-GitHub עושה בדיוק את זה container escape שמסתיים ב-root על ה-host.
הנקודה שהכי חשוב להבין: אי אפשר לכבות AF_UNIX
זה ההבדל המהותי בין BadGarbage לפגיעויות קרנל אחרות שכתבנו עליהן לאחרונה:
- ב-OVSwrap אפשר היה להוציא את מודול ה-OVS ולחסום את הווקטור.
- ב-DirtyClone אפשר היה לצמצם חשיפה דרך network namespaces.
כאן אין מיטיגציה חלקית שעוזרת. AF_UNIX הוא חלק מליבת המערכת. systemd משתמש בו, D-Bus משתמש בו, MySQL, Nginx, PHP-FPM כולם מתקשרים דרך Unix sockets. לחסום אותו זה לכבות את השרת.
מה כן צריך כדי לנצל:
- גישה מקומית חשבון SSH, סקריפט PHP פגיע, תהליך בתוך קונטיינר.
- היכולת ליצור Unix domain sockets זו פעולה שכל משתמש מקומי יכול לבצע.
- שימוש ב-
SCM_RIGHTSו-MSG_PEEKקריאות מערכת סטנדרטיות, בלי שום הרשאה מיוחדת.
מי חשוף? טבלת הפצות
פגיע PoC ציבורי זמין
| הפצה | קרנל | הערות |
|---|---|---|
| Debian 13 (trixie) | 6.12 | פגיע עד 6.12.94, תיקון ב-DSA-6381-1 |
| Ubuntu 24.04 HWE | 6.17 | פגיע עד 6.17.0-41, טרם תוקן |
| RHEL 10 / AlmaLinux 10 | 6.12 | פגיע, טרם תוקן |
| CentOS Stream 10 | 6.12 | פגיע, נבדק עד 6.12.0-257.el10 |
פגיע וקטור שונה (לא מכוסה ב-PoC הנוכחי)
| הפצה | קרנל | הערות |
|---|---|---|
| Ubuntu 24.04 GA | 6.8 | פגיע, וקטור non-PEEK |
| קרנלים 7.x | 7.x | פגיע, מחוץ לטווח ה-PoC הנוכחי |
גרסאות קרנל מתוקנות (upstream)
התיקון נכנס ל-stable בקומיט d82ba05263c6. גרסאות מתוקנות כוללות: 6.12.95, ונוספות בדרך.
הפיל שבחדר: הקצב
בואו נשים את 2026 על ציר זמן. אלה רק פגיעויות הקרנל שדרשו מאיתנו התייחסות תפעולית מאפריל:
| תאריך | פגיעות | סוג |
|---|---|---|
| אפריל 2026 | Copy.Fail (CVE-2026-31431) | הסלמת הרשאות מקומית |
| מאי 2026 | CIFSwitch | Local root |
| יוני 2026 | pedit COW (CVE-2026-46331) | net/sched |
| יוני 2026 | DirtyClone | הסלמה ל-root |
| יולי 2026 | Januscape (CVE-2026-53359) | KVM בריחה מ-guest ל-host |
| יולי 2026 | GhostLock (CVE-2026-43499) | futex ללא מיטיגציה זמינה |
| יולי 2026 | RefluXFS (CVE-2026-64600) | XFS reflink → root |
| יולי 2026 | OVSwrap (CVE-2026-64531) | Open vSwitch → root |
| אוגוסט 2026 | BadGarbage (CVE-2026-53361) | AF_UNIX GC → root + container escape |
תשעה אירועים בחמישה חודשים. וזו לא אנומליה זה הנורמל החדש. כלי AI מאיצים דרמטית את קצב מציאת החולשות (כתבנו על זה כאן), ובמקביל תוקפים משתמשים באותם כלים כדי לכתוב exploit תוך שעות במקום שבועות.
המשמעות המעשית: שיטת "נתזמן ריסטארט לסוף השבוע" לא עובדת יותר. היא לא נכשלה בגלל רשלנות היא נכשלה כי המתמטיקה השתנתה. חלון החשיפה נמדד היום בשעות, ותהליך התחזוקה המסורתי נמדד בימים.
מה עושים עכשיו צ'קליסט מעשי
- לעדכן קרנל. אם ההפצה שלכם כבר שחררה גרסה מתוקנת זו התשובה. תמיד.
- לבדוק את גרסת הקרנל
uname -rולהשוות מול הטבלה למעלה. - לצמצם שטח תקיפה מקומי. BadGarbage היא פגיעות מקומית ההנחה שלה היא שכבר יש למישהו דריסת רגל. סקירת חשבונות SSH, מפתחות, הרשאות, תוספי וורדפרס מיותרים זה חלק מהתגובה, לא נספח לה.
- סביבות קונטיינר תשומת לב מיוחדת. אם אתם מריצים Docker/LXC על שרתים משותפים, הפגיעות הזו היא בדיוק התרחיש שצריך להטריד אתכם: דייר אחד שמנצל container escape כדי להשתלט על כל ה-host.
- לתעד. אם אתם ארגון שכפוף לתקנות הגנת הפרטיות אירוע כזה ותהליך הטיפול בו הם בדיוק מה שצריך להיות מתועד בלוגים, כפי שכתבנו בהרחבה כאן.
מה עשינו ב-SPD ומה לקוחות Kernel Shield נדרשו לעשות
נתחיל מהחלק החשוב: לקוחות שרצים תחת SPD Kernel Shield לא נדרשו לעשות דבר. לא ריסטארט, לא חלון תחזוקה, לא מיטיגציה ידנית.
הנה מה שקרה אצלנו בפועל:
- שעות ראשונות ה-SOC שלנו קיבל את ההתראה. צוות הסייבר מיפה את הצי: אילו שרתים רצים על קרנלים בטווח הפגיע, ואילו לא.
- ה-livepatch ברגע שה-patchset שוחרר, הוא הוחל על השרתים המכוסים ב-Kernel Shield בזמן ריצה, בלי ריסטארט אחד.
- אימות בדיקת
kcarectl --patch-infoעל כל שרת שקיבל את התיקון, כדי לוודא שהוא לא רק "אמור להיות" מוגן.
זה בדיוק אותו תסריט שהפעלנו ב-OVSwrap, ב-DirtyClone, וכשהתפוצצה הפצצה של wp2shell. ההבדל? זה כבר לא אירוע חריג. זו שגרה.
למה זה נקרא "פתרון כפול"
כשאנחנו מדברים על SPD Kernel Shield, אנחנו מדברים על שתי בעיות שונות:
1. הבעיה הסייברית חלון החשיפה.
- עדכוני אבטחה לליבת Linux מוחלים בזמן אמת, מיד עם פרסום ה-patch.
- אינטגרציה עם סורקי חולשות (Nessus, Qualys, Rapid7) בלי False Positives.
- תמיכה מלאה ב-UEFI Secure Boot וב-FIPS-140.
2. הבעיה התפעולית המחיר של ריסטארט.
- אפס Downtime. אין ניתוק משתמשים, אין השבתת שירות.
- אין חלונות תחזוקה. אין תיאום עם מחלקות, אין הודעות מראש.
- אין Restart Fatigue. כשקצב הפגיעויות הוא אחת לשבועיים, ההפרדה בין "דחוף" ל"מתוזמן" היא ההבדל בין צוות שמתפקד לצוות שרוף.
עדיין מבצעים Restart בשביל Kernel Patches?
ה-BadGarbage הבאה כבר בדרך כנראה בעוד שבועיים. השאלה היחידה היא אם תשמעו עליה מהחדשות, או שפשוט לא תצטרכו לעשות שום דבר.
➜ כל הפרטים על SPD Kernel Shield | SOC 24/7 של SPD | דברו איתנו | 03-6221258
שאלות שכבר נשאלנו
ה-WAF שלנו עוצר את זה?
לא, ולא אמור. זו לא מתקפה שמגיעה דרך HTTP. WAF מגן על שכבת האפליקציה; BadGarbage היא הסלמת הרשאות מקומית בשכבת מערכת ההפעלה. אלה שתי שכבות שונות בהגנה לעומק, וצריך את שתיהן.
האם יש ניצול בשטח?
PoC ציבורי ועובד קיים ב-GitHub. נכון לכתיבת שורות אלה לא אושר ניצול in-the-wild, אבל ההנחה הסבירה היא שזה עניין של זמן קצר במיוחד לאור העובדה שהקוד תומך בהפצות נפוצות מאוד.
מה עם שרתי אחסון שיתופי?
זה בדיוק התרחיש הגרוע ביותר. בשרת שיתופי עשרות או מאות לקוחות חולקים קרנל אחד. אם חשבון אחד נפרץ דרך סיסמה חלשה, תוסף וורדפרס פגיע, או סקריפט PHP ישן BadGarbage מאפשרת לתוקף לעלות מחשבון רגיל ל-root על כל המכונה. כל האתרים, כל מסדי הנתונים, כל הקבצים.
אנחנו על קרנל ישן (5.x / 4.x), אז אנחנו בסדר?
לגבי BadGarbage הספציפית יתכן, תלוי בגרסה ובהפצה. אבל אם הסיבה שאתם שם היא שלא שדרגתם מזה שנים, יש לכם בעיה גדולה יותר מ-CVE אחד. גרסאות EOL הן חוב אבטחה שנצבר בריבית.
שורה תחתונה
BadGarbage היא עוד דוגמה מושלמת לאיפה שעולם אבטחת התשתיות נמצא ב-2026: באג שנמצא ברכיב כל כך בסיסי שאי אפשר לכבות אותו, שתוקן שלוש פעמים ועדיין חזר, ושקיבל PoC ציבורי עם container escape תוך ימים.
אף אחד לא יכול למנוע את גילוי הפגיעות הבאה. מה שכן אפשר לשלוט בו זה כמה זמן לוקח לכם לסגור את הפער, וכמה זה עולה לכם בזמן, בהשבתה ובשקט נפשי.
שרתים שמכוסים ב-SPD Kernel Shield קיבלו את התיקון בזמן ריצה, ללא ריסטארט וללא פעולה מצד הלקוח. אם אתם מנהלים שרתים בעצמכם זה הזמן להפסיק להתייחס ל-live kernel patching כאל "נחמד שיהיה", ולהתחיל להתייחס אליו כאל תשתית בסיסית. בדיוק כמו גיבוי.
מקורות ולקריאה נוספת
- PoC ציבורי: sgkdev/bad_garbage GitHub
- SentinelOne ניתוח טכני: CVE-2026-53361
- zero downtime Live Kernel Patching ולמה זה שינה את כללי המשחק
- OVSwrap: לא התקנתם Open vSwitch? אתם עדיין פגיעים
- DirtyClone: כך חבילת רשת אחת מעניקה לתוקף הרשאות root
- 24 שעות ב-SOC של SPD: יומן מתקפה אמיתי
