הקדמה
אני מניח שחלקכם כבר נתקלו בכותרת "פרצה חדשה בקרנל של לינוקס" ופשוט גיללתם הלאה — בצדק, כי הן מתפרסמות בקצב מסחרר. אבל הפעם כדאי לעצור רגע. הפרצה שזכתה לכינוי DirtyClone (מספר רשמי CVE-2026-43503) היא דוגמה יפהפייה — ומסוכנת — לאיך באג קטן ושקט בקוד הרשת של הקרנל הופך משתמש מקומי חסר-הרשאות לבעל שליטה מלאה (root) על השרת.
היא גם לא לבד: זוהי הפרצה הרביעית באותה משפחה (DirtyFrag) שמתגלה בחודשים האחרונים, וכל אחת מהן סגרה מסלול אחד והשאירה אחרים פתוחים. בואו נבין מה קורה כאן בלי לטבוע במונחים.
אז מה בעצם התגלה?
כדי לעבוד מהר, הקרנל של לינוקס משתמש בטכניקה שנקראת zero-copy networking: במקום להעתיק נתונים שוב ושוב בזיכרון, הוא לפעמים נותן ל-packet (חבילת רשת) להצביע ישירות על אותו אזור זיכרון שבו יושב קובץ שכבר נטען מהדיסק (ה-Page Cache). זה חוסך עבודה — אבל מחייב סימון ברור: "תיזהר, הזיכרון הזה משותף עם קובץ אמיתי, אסור לכתוב עליו במקום".
הסימון הזה הוא דגל בודד בשם SKBFL_SHARED_FRAG. וכאן נמצא כל הסיפור: שתי פונקציות שמעבירות "שברים" (fragments) של packets מצד אחד לשני — __pskb_copy_fclone() ו-skb_shift() — פשוט שכחו להעביר איתן את הדגל. התוצאה: עותק של packet שעדיין מצביע על זיכרון של קובץ, אבל מדווח על עצמו כאילו הוא "פרטי" ובטוח לכתיבה.
איך תוקף מנצל את זה בפועל
התרחיש המעשי, כפי שהודגם פומבית על-ידי חוקרי JFrog, מתואר בצורה כמעט אלגנטית:
- התוקף טוען לזיכרון קובץ הרצה מורשה — למשל
/usr/bin/su. - הוא "מחבר" את דפי הזיכרון של אותו קובץ לתוך packet, ומכריח את הקרנל לשכפל אותו (clone).
- ה-packet המשוכפל עובר דרך מנהרת IPsec מקומית שהתוקף שולט בה, ושלב הפענוח (ESP) כותב בתים שהתוקף בחר — ישירות אל תוך עותק הזיכרון של
su, ועוקף את בדיקות הסיסמה. - בפעם הבאה שמישהו מריץ
su— הוא מקבל הרשאות root. וזהו.
הצד המפחיד באמת? הקובץ על הדיסק לא משתנה כלל. השינוי חי רק בעותק הזיכרון של הקרנל, ולכן כלים לבדיקת שלמות קבצים (File Integrity) פשוט לא רואים אותו, אין שובל בלוגים, ואתחול השרת מחזיר את הקובץ המקורי — אבל עד אז התוקף כבר מזמן root.
מי באמת בסיכון?
ניצול הפרצה דורש את ההרשאה CAP_NET_ADMIN כדי להגדיר את מנהרת ה-IPsec על ה-loopback. זה נשמע כמו מחסום — אבל ב-Debian וב-Fedora, מרחבי שמות לא-מורשים (unprivileged user namespaces) מופעלים כברירת מחדל, כך שמשתמש מקומי יכול להשיג את ההרשאה הזו בתוך namespace חדש שהוא יוצר בעצמו.
הסביבות הכי חשופות הן בדיוק אלה שבהן רצים משתמשים לא-מהימנים זה לצד זה, או שבהן ה-namespaces פתוחים כברירת מחדל:
- שרתים מרובי-דיירים (Multi-tenant) וסביבות Shared Hosting / Cloud.
- מכונות CI/CD ו-Build Runners שמריצות קוד לא-מהימן.
- מארחי Containers וקלאסטרים של Kubernetes שבהם מותר ליצור namespaces.
- Debian ו-Fedora — מערכות שבהן unprivileged user namespaces פתוחים כברירת מחדל, כך שמשתמש מקומי משיג
CAP_NET_ADMINבקלות. - Ubuntu 22.04 (Jammy) ומטה, RHEL / CentOS / AlmaLinux / Rocky / Oracle Linux ו-Amazon Linux — בכל מקום שבו רצים שירותים על Kernel לא-מעודכן וקיימת גישה מקומית (למשל עובדים, לקוחות VPS, או תהליכים שנפרצו ורצים כמשתמש לא-מורשה).
- שרתי VPS ו-Dedicated שמנוהלים ידנית ולא עברו עדכון קרנל מאז מאי 2026.
נקודה אחת חשובה לטובה: ב-Ubuntu 24.04 ואילך, יצירת namespaces מוגבלת דרך AppArmor — מה שחוסם את מסלול הניצול שבברירת מחדל. זה לא "חיסון", אבל זה מעלה משמעותית את הרף.
⚠️ מה לעשות עכשיו — Workarounds זמניים
הפתרון האמיתי הוא עדכון הקרנל (ראו בהמשך). אבל אם אתם לא יכולים לעדכן ולאתחל היום, יש שני צעדים שמצמצמים את משטח התקיפה:
- הגבלת user namespaces לא-מורשים. ב-Debian/Ubuntu אפשר להגדיר:
sysctl -w kernel.unprivileged_userns_clone=0
(להפצות אחרות יש מנגנונים שונים.) זה חוסם את הדרך הנפוצה שבה משתמש רגיל משיג
CAP_NET_ADMIN. - חסימת מודולי הקרנל הרלוונטיים —
esp4,esp6ו-rxrpc:echo "blacklist esp4" >> /etc/modprobe.d/dirtyclone.conf echo "blacklist esp6" >> /etc/modprobe.d/dirtyclone.conf echo "blacklist rxrpc" >> /etc/modprobe.d/dirtyclone.conf
חשוב לדעת: זה שובר IPsec ו-AFS, ועובד רק אם הרכיבים הללו טעונים כמודולים ולא מקומפלים ישירות לתוך הקרנל.
שורה תחתונה: שני אלה הם בקרות זמניות בלבד, לא תחליף לתיקון.
התיקון — וההמלצה
התיקון נכנס ל-Mainline ב-21 במאי 2026 (commit 48f6a5356a33), שולב ב-Linux v7.1-rc5, ועבר Backport לענפי ה-Stable וה-LTS. ההמלצה פשוטה: התקינו את עדכון הקרנל של ההפצה שלכם — ואתחלו.
התיקון זמין בכל ההפצות המרכזיות דרך עדכוני הקרנל הרגילים — Ubuntu, Debian, SUSE / openSUSE (כולל Live Patch), Red Hat (RHEL) והנגזרות שלה (AlmaLinux, Rocky Linux, Oracle Linux), וכן Fedora ו-Amazon Linux. עדכנו את הקרנל בכלי הסטנדרטי של ההפצה (apt / dnf / zypper), ואתחלו את השרת כדי שייכנס לתוקף.
שימו לב לנקודה עקרונית: התיקון הזה לא "מסיים" את הסיפור. השורש כאן הוא תבניתי — בכל פעם שהקרנל מזיז fragments של packets ממקום למקום, מישהו צריך לזכור לגרור איתם את דגל ה-shared-frag, וכל מסלול חדש שמפספס את זה הוא CVE פוטנציאלי הבא. החוקרים מעריכים שמשפחת DirtyFrag עוד לא מיצתה את עצמה, וצפויות גרסאות נוספות. כלומר: ניהול עדכוני קרנל מהיר ושיטתי הוא לא מותרות — הוא הקו האדום בין שרת מוגן לשרת פרוץ.
וכאן בדיוק נכנסת SPD
הבעיה הקלאסית עם פרצות קרנל היא הפער שבין רגע פרסום ה-CVE לבין חלון התחזוקה הבא שבו אפשר לאתחל את השרת. בעידן ה-AI סריקות עוינות מתחילות לעיתים תוך דקות מפרסום החולשה — הרבה לפני שהספקתם לתזמן Restart.
SPD Kernel Shield מאפשר להחיל Kernel Patches קריטיים בזמן אמת, בזיכרון, ללא אתחול וללא Downtime — וכך לסגור את חלון החשיפה מיד עם פרסום הפרצה, בדיוק בתרחיש כמו DirtyClone. הפתרון תומך במגוון רחב של הפצות (Ubuntu, RHEL/CentOS/Alma/Rocky/Oracle, Debian, Amazon Linux) ובסביבות וירטואליזציה, משתלב עם סורקי חולשות מובילים (Nessus, Qualys, Rapid7) כדי למנוע False Positives, ותומך ב-FIPS-140 וב-UEFI Secure Boot.
עדיין מבצעים Restart בשביל Kernel Patches? בואו נדבר.
The Hacker News – New DirtyClone Linux Kernel Flaw: קישור
Ubuntu Security – CVE-2026-43503: קישור
Ubuntu Security Notice – USN-8373-1: קישור
JFrog Security Research – ניתוח וניצול DirtyClone: קישור
Debian Security Tracker – CVE-2026-43503: קישור
SUSE – CVE-2026-43503: קישור
Red Hat Bugzilla – Tracking entry: קישור
Linux Kernel mailing list – multi-site patch: קישור
