web

spd.co.il

03-6221258

לא התקנתם Open vSwitch מעולם? אתם עדיין פגיעים. הכירו את OVSwrap

פורסם באוגוסט 2, 2026

בקצרה: ב-28 ביולי 2026 פורסמו הפרטים המלאים וקוד ניצול (PoC) ציבורי לפגיעות חדשה בקרנל של לינוקס OVSwrap (CVE-2026-64531). שורה אחת בטרמינל מספיקה כדי שמשתמש רגיל, בלי שום הרשאה מיוחדת, יהפוך ל-root על השרת. הפגיעות עובדת גם אם לא התקנתם ולא הפעלתם Open vSwitch מעולם. רוב ההפצות הנפוצות Debian 12/13, Ubuntu 22.04, AlmaLinux, Rocky, CentOS Stream, Fedora, Amazon Linux 2023 נמצאו פגיעות בתצורת ברירת המחדל. במאמר: מה קרה, מי חשוף, מה עושים היום, ולמה לקוחות שרצים עם SPD Kernel Shield לא נדרשו לעשות דבר.

הקדמה: "עוד פגיעות קרנל" עד שהיא שלכם

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

אבל OVSwrap שונה בשלושה דברים, וכדאי לעצור עליהם:

  1. אין דרישות מקדימות משמעותיות. לא צריך הרשאות, לא צריך שירות פעיל, לא צריך תצורה חריגה.
  2. הניצול דטרמיניסטי. אין הימור, אין "grooming" של הזיכרון, אין סיכוי סביר להפיל את השרת בניסיון. זה פשוט עובד.
  3. ה-PoC ציבורי עם טבלת ערכים מוכנה לכ-800 גרסאות קרנל שונות. כלומר, גם מי שאין לו יכולת לפתח exploit יכול פשוט להריץ.

אז בואו נעבור על זה בסדר: מה זה, למה זה עובד, מי חשוף, ומה עושים בפועל.

מה זה OVSwrap בשתי דקות

הפגיעות נמצאת ברכיב Open vSwitch (OVS) שבתוך קרנל הלינוקס. OVS הוא מתג רשת תוכנתי  הרכיב שמנתב תעבורה בין מכונות וירטואליות, קונטיינרים וסביבות ענן. הוא מחולק לשני חלקים: תהליך בשם ovs-vswitchd שרץ ב-userspace ומחליט אילו "זרימות" (flows) צריכות להתקיים, והקרנל שמבצע אותן בפועל, מהר, על כל חבילת רשת.

כל זרימה מורכבת ממפתח (איזו תעבורה היא תופסת) ורשימת פעולות (מה לעשות איתה): לשלוח לפורט, לשנות שדות, להעביר דרך conntrack, לשכפל את החבילה ולהריץ עליה רשימת פעולות נוספת, וכן הלאה.

הבאג עצמו: מספר שלא נכנס במקום שהוקצה לו

הקרנל שומר את הפעולות הפנימיות שהוא מייצר כמבנה נתונים בשם Netlink attribute. לכל attribute כזה יש שדה אורך, nla_len, שהוא 16 ביט בלבד — כלומר מקסימום 65,535 בייט.

עד מרץ 2025 היה בקרנל מגבלת עזר של 32KB על אורך רשימת הפעולות הכוללת. המגבלה הזו הוסרה (מסיבות לגיטימיות היא גרמה לכשלים בלתי צפויים), ומה שקרה בפועל: נעלמה שכבת ההגנה האחרונה שמנעה מ-attribute מקונן יחיד לחצות את הרף של 65,536 בייט. הבאג עצמו, אגב, ישב בקוד 13 שנה הוא פשוט לא היה ניתן לניצול עד אז.

מכאן זה פשוט להחריד. התוקף שולח פעולת CLONE תקינה לחלוטין שמכילה בתוכה מאות פעולות conntrack קטנות. הקרנל מרחיב כל פעולת conntrack ל-164 בייט פנימיים, ובסך הכול נוצרת פעולה באורך 65,612 בייט. כשהקרנל בא לרשום את האורך הזה בשדה של 16 ביט, המספר עולה על גדותיו ומתגלגל ל-76.

4 + 8 + (400 × 164) = 65,612 bytes
65,612 mod 65,536   = 76  →  nla_len = 0x004c

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

ומרגע שהתוקף יכול לשתול "פעולות מזויפות" שהקרנל מבצע יש לו יכולת קריאה מהזיכרון של הקרנל, יכולת הפחתה (decrement) של ערך בכתובת שהוא בוחר, ומשם המסלול ל-root הוא הנדסה נקייה: לאתר את מבנה ההרשאות של תהליך, להוריד את ה-fsuid ו-fsgid שלו ל-0, ולכתוב לתוך /etc/sudoers.d.

למה זה מדאיג יותר מפגיעות זיכרון רגילה: ברוב הפגיעויות מסוג memory corruption התוקף צריך "לסדר" את הזיכרון בצורה מסוימת, וכל ניסיון עלול להפיל את המכונה. כאן לא. ההיסט שאליו הפרסר נוחת הוא קבוע וידוע מראש עבור כל גרסת קרנל, וניתן לגזור אותו ישירות מ-System.map או מ-BTF. החוקר שגילה את הפגיעות שחרר PoC עם ערכים מוכנים מראש לכ-800 בילדים של קרנל. אמינות של באג לוגי, בלבוש של באג זיכרון.

הנקודה שהכי חשוב להבין: אתם לא צריכים להשתמש ב-Open vSwitch

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

  • לא צריך גשר OVS קיים.
  • לא צריך ש-ovs-vswitchd ירוץ. אפילו לא צריך שהוא יהיה מותקן.
  • לא צריך CAP_NET_ADMIN ברמת המערכת.
  • לא צריך שמודול ה-OVS יהיה טעון. ברוב ההפצות המודול קיים על הדיסק כמודול נטען וכשמישהו מבקש את משפחת ה-Generic Netlink של OVS לפי שם, הקרנל טוען אותו בעצמו.

מה כן צריך? הרשאת CAP_NET_ADMIN בתוך user namespace שהתוקף עצמו יצר. וזה, בהפצות שבהן unprivileged user namespaces מופעלים כברירת מחדל, זו פקודה אחת:

unshare -Urn

משתמש רגיל לגמרי למשל חשבון שנפרץ דרך סיסמה חלשה, סקריפט PHP פגיע, או עובד עם גישת SSH לגיטימית מקבל בפקודה הזו uid 0 בתוך namespace פרטי, יוצר שם datapath של OVS, ומשם ממשיך לשורש המערכת האמיתי.

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

מי חשוף? טבלת ההפצות

פגיע בתצורת ברירת מחדל

הפצה הערות
Debian 12 / 13 פגיע כפי שנבדק
Ubuntu 22.04 (Desktop + Server) פגיע כפי שנבדק
Ubuntu 24.04 ‏AppArmor חוסם unshare ישיר, אך קיימת דרך עקיפה מוכרת
AlmaLinux 9.7 / 9.8 / 10.1 / 10.2 פגיע כפי שנבדק
Rocky Linux 9 / 10 פגיע כפי שנבדק
CentOS Stream 9 / 10 פגיע כפי שנבדק
Fedora 42 / 43 / 44 פגיע כפי שנבדק
Amazon Linux 2023 מסלולי קרנל 6.1 / 6.12 / 6.18
Alpine, Arch, Kali 2026.1, Linux Mint 22.3, NixOS, openSUSE Tumbleweed, Pop!_OS פגיעים כפי שנבדקו

לא נמצא פגיע בבדיקות

הפצה הערות
Debian 11 סדרת 5.10 מעולם לא קיבלה את השינוי המאפשר
Ubuntu 18.04 / 20.04 סדרות 4.15 / 5.4 לא קיבלו את השינוי
Amazon Linux 2 שומר על המגבלה הישנה
Rocky Linux 8 קו הקרנל 4.18 לא קיבל את השינוי
openSUSE Leap 16.0 לא נושא את ה-backport הרלוונטי

גרסאות קרנל מתוקנות (upstream)

התיקון נכנס ל-stable ב-24 ביולי 2026 והופיע בגרסאות: 5.15.212, 6.1.178, 6.6.145, 6.12.97, 6.18.40, 7.1.5.

שימו לב לנקודה הבאה: סדרות 6.13, 6.14–6.17, 6.19 ו-7.0 הן EOL — ולא יקבלו תיקון upstream כלל. מי שיושב עליהן צריך לעבור סדרה, נקודה.

מה עושים עכשיו צ'קליסט מעשי

  1. לעדכן קרנל. אם יש גרסה מתוקנת להפצה שלכם זו התשובה הנכונה. תמיד.
  2. אם OVS לא נחוץ לכם — להוציא אותו מהמשחק. להוריד את המודול ולהוסיף אותו ל-blacklist. שימו לב: שורת blacklist רגילה לא תמיד מספיקה כשהטעינה מתבצעת דרך alias. 
    printf 'install openvswitch /bin/false\n' \
  | sudo tee /etc/modprobe.d/disable-ovs.conf
  3. לכבות unprivileged user namespaces אם אין לכם בהם צורך אמיתי. זה סוגר את המסלול של המשתמש הרגיל (אך לא את זה של קונטיינרים או תהליכים שכבר מחזיקים ב-CAP_NET_ADMIN).
  4. לבדוק מי בכלל יכול להגיע לשרת. זו פגיעות מקומית ההנחה שלה היא שכבר יש למישהו דריסת רגל. סקירת חשבונות, מפתחות SSH והרשאות היא חלק מהתגובה, לא נספח לה.
  5. לתעד. אם אתם ארגון שכפוף לתקנות הגנת הפרטיות, אירוע כזה ותהליך הטיפול בו הם בדיוק מה שצריך להיות מתועד בלוגים כפי שכתבנו בהרחבה כאן.
הבעיה עם הרשימה הזו: כל סעיף בה דורש חלון תחזוקה, ריסטארט, תיאום עם לקוחות, ובדיקה שהשרת קם כמו שצריך. על שרת אחד זה ערב עבודה. על מאות שרתים בהפצות שונות זה פרויקט של שבועות. ובינתיים, ה-PoC כבר ציבורי.

הפיל שבחדר: הקצב

בואו נשים את 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
28 ביולי 2026 OVSwrap (CVE-2026-64531) ‏Open vSwitch → root

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

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

מה עשינו ב-SPD ומה לקוחות Kernel Shield נדרשו לעשות

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

הנה מה שקרה אצלנו בפועל מרגע הפרסום:

  • שעות ראשונות ה-SOC שלנו קיבל את ההתראה, ותוך זמן קצר מיפינו את הצי: אילו שרתים רצים על קרנלים שנמצאים בטווח הפגיע, ואילו לא.
  • ה-livepatch ה-patchsets עבור משפחת EL9 (AlmaLinux 9, RHEL 9, Rocky Linux 9, Oracle Linux 9) שוחררו ב-30 ביולי; EL10 בדרך. ברגע שהם נכנסו לפיד, הם הוחלו על השרתים המכוסים ב-Kernel Shield בזמן ריצה, בלי ריסטארט אחד.
  • אימות בדיקת kcarectl --patch-info על כל שרת שקיבל את התיקון, כדי לוודא שהוא לא רק "אמור להיות" מוגן.

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

למה זה נקרא "פתרון כפול"

כשאנחנו מדברים על SPD Kernel Shield, אנחנו מדברים על שתי בעיות שונות לגמרי שנפתרות באותו כלי:

1. הבעיה הסייברית חלון החשיפה.

  • עדכוני אבטחה לליבת Linux מוחלים בזמן אמת, מיד עם פרסום ה-patch, בלי לחכות לחלון תחזוקה.
  • סוכן שרץ על כל שרת בודק את הפיד באופן שוטף ומחיל אוטומטית בלי התערבות ידנית, בלי "מישהו שכח".
  • אינטגרציה מלאה עם סורקי חולשות (Nessus, Qualys, Rapid7): הסורק רואה את מצב האבטחה האמיתי כולל patches שהוחלו בזיכרון, וכך אתם לא מקבלים False Positives בדוחות על חולשות שכבר טופלו.
  • תמיכה מלאה ב-UEFI Secure Boot ובסביבות FIPS-140 התיקון לא שובר את שרשרת האמון ולא נוגע ברכיבי ההצפנה שעברו ולידציה.

2. הבעיה התפעולית העלות האמיתית של "פשוט תעשו ריסטארט".

  • אפס Downtime. אין ניתוק משתמשים, אין השבתת שירות, אין פגיעה ברציפות עסקית.
  • אין חלונות תחזוקה. אין תיאום עם מחלקות, אין הודעות מראש ללקוחות עם SLA, אין עבודה בשתיים בלילה.
  • אין "reboot backlog". אותו צבר שרתים שממתין לתחזוקה כי אף פעם אין זמן טוב פשוט לא נוצר.
  • אין Restart Fatigue. כשקצב הפגיעויות הוא אחת לשבועיים, ההפרדה בין "דחוף" ל"מתוזמן" היא ההבדל בין צוות תפעול מתפקד לצוות שרוף.

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

עדיין מבצעים Restart בשביל Kernel Patches?

ה-OVSwrap הבא כבר בדרך כנראה בעוד שבועיים. השאלה היחידה היא אם תשמעו עליו מהחדשות, או שפשוט לא תצטרכו לעשות שום דבר.

➜ כל הפרטים על SPD Kernel Shield  |  SOC 24/7 של SPD  |  דברו איתנו  |  03-6221258

שאלות שכבר נשאלנו

יש ניצול בפועל בשטח?

נכון לכתיבת שורות אלה, לא אושר ניצול in-the-wild. אבל ה-PoC ציבורי, אמין ומגיע עם ערכים מוכנים לכ-800 בילדים של קרנל. ההנחה הסבירה היא שזה עניין של זמן קצר.

יש ציון CVSS?

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

ה-WAF שלנו עוצר את זה?

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

אנחנו על Debian 11 / Ubuntu 20.04, אז אנחנו בסדר?

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

שורה תחתונה

OVSwrap היא דוגמה מושלמת לאיפה שעולם אבטחת התשתיות נמצא ב-2026: באג בן 13 שנה שהפך לניתן לניצול בגלל שינוי לגיטימי לחלוטין, שנמצא בעזרת AI, שקיבל exploit דטרמיניסטי ואמין, ושפורסם ציבורית תוך ארבעה ימים מרגע שהתיקון נכנס ל-stable.

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

שרתים שמכוסים ב-SPD Kernel Shield קיבלו את התיקון בזמן ריצה, ללא ריסטארט וללא פעולה מצד הלקוח. אם אתם מנהלים שרתים בעצמכם זה הזמן להפסיק להתייחס ל-live kernel patching כאל "נחמד שיהיה", ולהתחיל להתייחס אליו כאל תשתית בסיסית. בדיוק כמו גיבוי.

מקורות ולקריאה נוספת

צוות SPD Hosting
support@spd.co.il

תוכן עניינים

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