web

spd.co.il

03-6221258

21 שנה ישב בשקט בליבת הלינוקס: איך bridge-stp-uaf (CVE-2026-72389) הופך לקוח אחסון אחד לבעל שליטה מלאה על כל השרת

פורסם בספטמבר 14, 2026

הקדמה: השנה שבה הליבה לא מפסיקה לרעוד

שנת 2026 מוכיחה את עצמה כשנה עמוסה וחריגה במיוחד בפגיעויות מסוג הסלמת הרשאות מקומית (Local Privilege Escalation – LPE) בליבת הלינוקס. רק לאחרונה עקבנו אחר פרצות כמו Copy Fail, Dirty Frag, Fragnesia, RtabRace, ופגיעות BadGarbage (CVE-2026-53361) שחשפה באג ותיק במנגנון התקשורת של הליבה. כעת נחשפה פגיעות יסודית ועמוקה אף יותר: CVE-2026-72389, הידועה בכינוי bridge-stp-uaf.
הפגיעות נחשפה על ידי חוקרי האבטחה n132 ו-sven sze דרך פלטפורמת SSD Secure Disclosure. מדובר בבאג שנמצא בקוד ה-Bridge (גישור רשת) בלינוקס ומלווה את המערכת כמעט מכל גרסה ששוחררה מאז שנת 2005 (החל מ-Linux 2.6.12).
בסביבות אחסון אתרים, שרתי VPS שיתופיים ומערכות Multi-Tenant, המשמעות של הפגיעות הזו מרחיקת לכת: כל משתמש מקומי רגיל — כולל אתר וורדפרס בודד שנפרץ עקב תוסף פגיע — יכול לנצל את הפרצה כדי להשיג הרשאות Root מלאות על שרת הלינוקס המארח כולו.

מה בעצם קרה? המנגנון הטכני מאחורי bridge-stp-uaf

הפגיעות ממוקמת במנגנון ה-STP (Spanning Tree Protocol) — הפרוטוקול הוותיק שאחראי על מניעת לולאות ברשת כאשר מחברים מספר גשרי רשת (Bridges) במקביל.
בליבת הלינוקס, כל גשר כזה מחזיק שלושה טיימרים פנימיים שרצים ברקע כל עוד הגשר פעיל:

  1. hello_timer
  2. tcn_timer
  3. topology_change_timer

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

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

התוצאה הישירה היא מצב שבו טיימר ממשיך "לרוץ" ולהפנות לכתובת זיכרון שכבר שוחררה — פגיעות קלאסית וקטלנית מסוג Use-After-Free (UAF).

למה הפגיעות הזו מסוכנת כל כך?

  1. אין צורך בהרשאות מיוחדות: משתמש מערכת רגיל וחסר הרשאות ניהול (Unprivileged User) שיכול לפתוח Network Namespace ולהגדיר Bridge מסוגל להפעיל את שרשרת התקיפה.
  2. שרשרת פעולות "תמימה": התקיפה כולה מתבססת על 3 פעולות רשת סטנדרטיות: יצירת גשר רשת, הפעלת STP עליו, ומחיקתו בעיתוי הנכון.
  3. השתלטות מלאה על הזיכרון: תוקף ששולט בזיכרון המוקצה מחדש לאותה כתובת, שולט בפועל בפקודות שה-Kernel מריץ כאשר הטיימר מתעורר — נתיב ישיר מ-UAF להרצת קוד שרירותי בליבת השרת, ומשם לשליטת Root מוחלטת.
  4. 21 שנה של חשיפה רחבה: הקוד הפגיע מוטמע בליבות לינוקס מאז גרסה 2.6.12 שיצאה ב-2005. כמעט כל הפצת לינוקס קיימת מכילה את הבאג הזה בקוד המקור שלה.

מדוע מדובר בסיוט לאתרי אינטרנט באחסון משותף וענן?

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

  • תוסף וורדפרס פגיע שלא עודכן בזמן.
  • תבנית עיצוב עם פרצת File Upload שאיפשרה העלאת Web Shell.
  • סיסמת FTP או SSH שנחשפה בפישינג.

ברגע שלתוקף יש אחיזה באתר בודד, המחיצה שאמורה לבודד אותו משאר הלקוחות נשברת:

  1. התהליך הזדוני באתר הפרוץ פותח מרחב רשת פרטי משלו (Network Namespace).
  2. בתוכו הוא יוצר גשר, מפעיל עליו STP ומוחק אותו כדי להפעיל את ה-Race Condition.
  3. תוך שניות בודדות, התוקף מטפס מהאתר הפרוץ להרשאות Root של השרת הפיזי כולו.

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

המיטיגציות הקיימות — ומדוע הן אינן מספקות מענה שלם

קיימת מיטיגציה זמנית שחוסמת את נקודת הכניסה ברמת מערכת ההפעלה ללא שינוי הקרנל: חסימת טעינת מודול ה-Bridge באמצעות הכלל:

install bridge /bin/false

צעד זה עוצר את התקיפה בשלביה הראשונים, אך הוא חסר תועלת לחלוטין בשרתים שמריצים גישור בפועל. כל שרת המריץ קונטיינרים מבוססי Docker, סביבות וירטואליזציה של KVM, libvirt או LXC, טוען את מודול ה-Bridge כברירת מחדל של פעילותו התקינה.
עבור שרתים אלו, הדרך היחידה היא עדכון ליבה מלא (Kernel Patch) — וכאן מתחילה הדילמה המבצעית הגדולה.

המלכוד הקלאסי: כל עדכון קרנל = אתחול, חלון תחזוקה והשבתה

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

  • ארגונים דוחים את העדכון לסוף השבוע או לחלון תחזוקה לילי.
  • השרתים נותרים חשופים ופגיעים במשך ימים ואף שבועות מרגע פרסום ה-CVE.
  • תוקפים מנצלים בדיוק את חלון הזמן הזה (Time-to-Exploit), כיוון שקודי ניצול מתפרסמים ברשת לעיתים שעות ספורות בלבד לאחר חשיפת הפרצה.

הפתרון: SPD Kernel Shield — סגירת הפרצה בזמן אמת וללא השבתה

כדי לפתור את הפרדוקס שבין אבטחה מקסימלית לרציפות עסקית מלאה, פיתחה SPD את שירות SPD Kernel Shield — מעטפת הגנה פרואקטיבית המאפשרת הטמעת תיקוני אבטחה קריטיים בליבת הלינוקס על שרת חי, בזמן אמת, וללא צורך באתחול (Zero Reboot).

היתרונות המרכזיים של SPD Kernel Shield:

  • אפס זמני השבתה (100% Uptime): עדכוני האבטחה מוזרקים ישירות לזיכרון הפעיל של הליבה תוך כדי ריצה מלאה של כל התהליכים והאתרים.
  • סגירה מיידית של חלון החשיפה: ברגע שמשוחרר Patch רשמי לפרצה (דוגמת bridge-stp-uaf), הוא מוחל על השרתים באופן מיידי ואוטומטי על ידי צוות ה-SOC והתשתיות של SPD.
  • תאימות רגולטורית מלאה: תמיכה מלאה בסביבות עבודה מאובטחות (FIPS-140) ו-UEFI Secure Boot, המבטיחה עמידה קפדנית בתקני אבטחה ופרטיות (ISO 27001, ISO 27017, תקנות הגנת הפרטיות).
  • סנכרון מול סורקי פגיעויות: אינטגרציה מלאה מול כלי סריקה מובילים (Qualys, Nessus, Rapid7) המזהה שהליבה מוגנת ומאובטחת, ללא התראות שווא (False Positives).
  • תמיכה בכלל הפצות הלינוקס המובילות: תמיכה רחבה ב-Ubuntu, CloudLinux, RHEL, AlmaLinux, Rocky Linux, Debian, Amazon Linux וסביבות וירטואליזציה (Proxmox, Virtuozzo).

לסיכום

פרצת bridge-stp-uaf (CVE-2026-72389) מוכיחה שוב שבתחום אבטחת השרתים אין מקום לשאננות. בעולם שבו אתר בודד עלול להפוך למקפצה להשתלטות על שרת שלם, ההמתנה לחלון התחזוקה הבא היא סיכון ששום עסק אינו יכול להרשות לעצמו.
שרתים המנוהלים בתשתית המאובטחת של SPD נהנים ממעטפת הגנה רב-שכבתית הכוללת ניטור 24/7/365, מוקד SOC ייעודי, ותיקוני ליבה חיים שסוגרים איומי Zero-Day עוד לפני שהם מגיעים אל הלקוח.
רוצים לוודא שהשרת שלכם מוגן מפני פרצות קרנל ללא שום השבתה?
לפרטים והצטרפות לשירות SPD Kernel Shield ←
זקוקים לייעוץ בנושאי אבטחת שרתים?
מומחי הסיסטם והאבטחה של SPD Hosting זמינים עבורכם 24/7 בטלפון 03-6221258 או דרך מרכז השירות באתר החברה.

תוכן עניינים

לכתבות נוספות: