הקדמה
2026 מסתמנת כשנה חריגה בפגיעויות ליבת הלינוקס. אחרי Copy Fail, Dirty Frag, Fragnesia ו-pedit COW, הצטרפה לרשימה פגיעות נוספת מאותה משפחה ואפילו מאותה תת-מערכת בדיוק: RtabRace, המתועדת כ-CVE-2026-68138.
אנחנו ב-SPD מטפלים בפגיעויות מהסוג הזה כמעט מדי חודש, על פני עשרות שרתים ואלפי אתרים. הזווית שלנו כאן היא לא אקדמית אלא מבצעית: מה הפגיעות הזו אומרת בפועל לשרת שמארח לקוחות, מי באמת חשוף, ומה סדר הפעולות הנכון.
מה זו RtabRace, בשפה פשוטה
RtabRace היא פגיעות מסוג Race Condition מצב תחרות בתת-מערכת בקרת התעבורה (Traffic Control, בקיצור tc) של ליבת הלינוקס.
הליבה מנהלת רשימה גלובלית של טבלאות קצב, יחד עם מונה הפניות פשוט שאינו אטומי. היסטורית, כל גישה לרשימה הזו הייתה מסונכרנת באמצעות נעילה מרכזית פעולה אחת בכל רגע נתון. בשלב מסוים נפתח מסלול שמאפשר לחלק מהפעולות לרוץ בלי הנעילה הזו, וכאן נולדה הבעיה.
כששתי בקשות מקבילות ניגשות לאותה טבלת קצב באותו שבריר שנייה, מונה ההפניות והרשימה עלולים להשתבש. התוצאה היא Use-After-Free או Double-Free של אובייקט בזיכרון הליבה: הליבה ממשיכה להשתמש בזיכרון שכבר שוחרר, או משחררת אותו פעמיים. מכאן, בשרשרת ניצול מדויקת, אפשר להגיע לכתיבה מבוקרת לזיכרון ובסופו של דבר להרצת קוד בהרשאות root.
נקודה שחשוב להבין: הרשימה הפגיעה היא גלובלית ולא לפי Network Namespace. כלומר, גם בקשות שמגיעות מ-namespaces נפרדים לגמרי מנגנון שכל תפקידו הוא בידוד מתנגשות על אותו אובייקט. הבידוד שאמור להגן פשוט לא חל כאן.
למה זה קריטי דווקא בסביבת אחסון
חשוב להיות מדויקים: זו לא פגיעות מרוחקת. אף אחד לא יתקוף אתכם דרך האינטרנט באמצעות RtabRace. תוקף חייב קודם כל דריסת רגל מקומית על השרת.
וזו בדיוק הסיבה שהיא מסוכנת בסביבת אחסון. "דריסת רגל מקומית" זה לא תרחיש תיאורטי זה יום שלישי רגיל:
- תוסף וורדפרס פגיע באתר של לקוח כלשהו על השרת
- סקריפט שהועלה דרך טופס לא מסונן
- סיסמת FTP ישנה שדלפה במאגר סיסמאות
בכל אחד מהמקרים האלה התוקף מקבל הרצת קוד בהרשאות של משתמש אתר בודד. וזה בדרך כלל הסוף של הסיפור האתר נפרץ, המחיצה חוסמת את השאר.
פגיעויות מסוג LPE (Local Privilege Escalation) הן מה שהופך את "הסוף" הזה להתחלה. עם RtabRace, אירוע שהיה אמור להישאר מבודד לחשבון אחד עלול להפוך לשליטה מלאה על השרת: כל האתרים, כל מסדי הנתונים וכל הגיבויים על אותה מכונה.
זו הסיבה שאנחנו מתייחסים ל-LPE ברצינות שלא תמיד תואמת את ציון ה-CVSS שלהן. בכל אירוע פריצה משמעותי שטיפלנו בו בשנה האחרונה, שלב ההסלמה המקומית הוא זה שקבע את גודל הנזק.
מי באמת חשוף
הפגיעות קיימת בליבות רבות, אבל ניצול מעשי דורש כמה תנאים שמתקיימים יחד:
- גישה מקומית משתמש רגיל, בלי sudo, מספיק לחלוטין.
- User Namespaces לא מורשים מופעלים המנגנון שמאפשר למשתמש רגיל להשיג הרשאות רשת בתוך namespace משלו. זהו התנאי החוזר כמעט בכל גל הפגיעויות של 2026.
- מודולי בקרת תעבורה זמינים בעיקר
cls_flower(המסווג היחיד שרץ במסלול הלא-נעול) ו-act_police. - ארכיטקטורת x86-64 ומספר ליבות מעבד התקיפה היא מרוץ, ולכן הסתברותית ודורשת מקביליות אמיתית.
לגבי גרסאות: הבאג נכנס לליבה בגרסה 5.1 ותוקן בגרסאות 7.1.6 ו-7.2-rc5. אבל וזו הנקודה שהכי מבלבלת בשטח הפצות לינוקס מבצעות Backport של תיקוני אבטחה בלי לשנות את מספר הגרסה המוצג. מספר גרסה ישן לא בהכרח אומר שאתם פגיעים, ומספר גרסה חדש לא מבטיח שאתם מוגנים. הבדיקה האמיתית היא האם התיקון הספציפי קיים בקוד הליבה שרצה אצלכם בפועל.
סדר הפעולות המומלץ
1. עדכון ליבה זה התיקון האמיתי. כל השאר הוא הפחתת סיכון עד שהוא מותקן. שווה לבדוק את סטטוס העדכון מול ההפצה שאתם מריצים לפני שמתכננים כל דבר אחר.
2. צמצום משטח התקיפה בינתיים. אם השרת לא משתמש בכללי tc מתקדמים וזה המצב ברוב שרתי האחסון אפשר למנוע טעינה של המודולים הרלוונטיים. במקביל, השבתת User Namespaces לא מורשים סוגרת לא רק את RtabRace אלא חלק ניכר מגל הפגיעויות של השנה. חשוב לבדוק תאימות מראש: חלק מסביבות הקונטיינרים תלויות במנגנון הזה, ולכן זו לא החלטה אוטומטית.
3. ניטור, לא רק תיקון. ניצול מוצלח משאיר סימנים: קריסות ליבה, פעילות tc חריגה מתהליכים של משתמשי אתרים, ותהליכים שמנסים ליצור namespaces בקצב לא סביר. גם אחרי שתיקנתם, כדאי לדעת אם מישהו ניסה.
4. תעדוף לפי סוג הסביבה. שרת ייעודי עם משתמש אחד סיכון נמוך יחסית. שרת שמריץ קוד של גורמים מרובים, סביבות CI/CD, או אחסון עם מספר לקוחות כאן הפגיעות הופכת ממטרד לעדיפות ראשונה.
המענה המנוהל: SPD Kernel Shield
הבעיה עם סדר הפעולות שלמעלה היא לא שהוא מסובך אלא שצריך לחזור עליו כל שלושה שבועות. Copy Fail, Dirty Frag, Fragnesia, pedit COW, RtabRace. חמש פעמים בחודשים ספורים.
בכל אחת מהן, השלב שמעכב הוא אותו שלב: אתחול השרת. לקוח שמנהל חנות פעילה או פורטל עסקי לא יכול לספוג הפסקת שירות מתוזמנת כל כמה שבועות, וכך נוצר הפער המסוכן הפאץ' קיים, אבל הוא לא מותקן.
זו הסיבה שהתשתית המנוהלת שלנו בנויה סביב תיקון ליבה חי (Live Kernel Patching): עדכוני האבטחה מוזרקים ישירות לליבה הפעילה, בזמן ריצה, בלי אתחול ובלי חלון תחזוקה. ברגע שתיקון לפגיעות משוחרר, הוא מגיע לשרת אוטומטית במקום להמתין לחלון התחזוקה הבא.
לצד זה, לקוחות התשתית המנוהלת של SPD מקבלים:
- הקשחה מונעת חסימת מודולים שאינם בשימוש והידוק הרשאות משתמשים, כך שהתנאים לניצול פשוט לא מתקיימים
- ניטור SOC/NOC 24/7 מעקב אחר קריסות ליבה ופעילות חריגה של תהליכי משתמשים, וזיהוי ניסיונות ניצול בזמן אמת
- טיפול יזום כשמתפרסמת פגיעות חדשה, הצוות שלנו בודק את החשיפה בפועל ומטפל בה. לקוח לא צריך לקרוא אדוויזורי כדי להיות מוגן
לסיכום
RtabRace היא תזכורת לכך שאבטחת שרתים היא לא פרויקט חד-פעמי אלא תהליך מתמשך. גם אתר מאובטח היטב חי על שרת ואם הליבה של השרת פגיעה, רמת האבטחה של האתר מוגבלת לרמת האבטחה של הסביבה שסביבו.
אם אתם מנהלים שרת עצמאי ולא בטוחים מה מצב הליבה שלכם זה הזמן לבדוק. ואם אתם לא רוצים לעשות את הבדיקה הזו שוב בעוד שלושה שבועות, שווה לבחון תשתית מנוהלת.
זקוקים לעזרה? מומחי האבטחה של SPD זמינים בטלפון 03-6221258, דרך מרכז המדריכים והתמיכה באתר, או במייל helpdesk@spd.co.il
פורסם על-ידי צוות אבטחת המידע של SPD Hosting איפה שסייבר פוגש אחסון. מאז 2001
