אלף דרכים פחות להשגת הרשאות root

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

קל יותר ויותר להרחיב את היקף גילוי החולשות, אך תעדוף ואימות עדיין מהווים צווארי בקבוק תפעוליים. בנינו אבטיפוס לחיפוש חולשות אבטחה בליבת Linux בסביבת מחקר מבוקרת. האבטיפוס שלנו זיהה וניתח 2,308 ממצאים ראשוניים בליבת Linux, שחזר באופן דינמי 1,724 חולשות והפיק 948 קודי ניצול להעלאת הרשאות מקומית (LPE), שיכלו לאפשר למשתמש מקומי ללא הרשאות מיוחדות להשיג גישת root.

השתמשנו בראיות האלה כדי לתעדף חולשות לדיווח, ופיתחנו תיקונים מוצעים לבחינת המתחזקים. בהתאם להנחיות קהילת ליבת Linux, התחלנו בחולשות קריטיות, ואנו עובדים עם שותפי Patch the Planet על דיווחים ותיקונים נוספים.

ביוני, במסגרת יוזמת Patch the Planet שלנו, שיתפנו כי GPT‑5.5 Cyber זיהה חולשות בליבת Linux ופיתח 24 קודי ניצול להעלאת הרשאות מקומית כדי לאמת אותן ולדווח עליהן. הרחבנו את העבודה הזאת לתהליך המופעל באמצעות מודל סייבר עתידי, וכולל גילוי חולשות, אימות דינמי, הערכת אפשרות הניצול ויצירת תיקונים. עם סיומו, חוקרים אנושיים בחנו את התוצרים ודיווחו על החולשות שנמצאו בצירוף תיקונים.

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

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

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

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

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

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

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

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

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

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

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

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

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

בשלב זה זוהו 5,034 יעדי בדיקה, הכוללים כ-2.8 מיליון שורות קוד — כ-7% מכלל בסיס הקוד של ליבת Linux. כך צומצמה משמעותית עלות בדיקת האבטחה בהשוואה לניתוח של בסיס הקוד כולו. עלות שלב זה הייתה 3,426 דולר בקרדיטים ל-API.

לאחר מכן, סוכני הניתוח ניתחו כל יעד בדיקה והפיקו ממצאים ראשוניים בתהליך עבודה דומה לזה של תוסף Codex Security⁠(נפתח בחלון חדש). בקווים כלליים, סוכני הניתוח קוראים את הקוד של יעד הבדיקה שהוקצה להם כדי להבין כיצד הוא פועל, לזהות את מודל האיומים שלו ולחפש בו חולשות.

בתוך 12 שעות הפיקו סוכני הניתוח 2,308 ממצאים ראשוניים, לאחר הסרת כפילויות. עלות שלב זה הייתה 316,549 דולר בקרדיטים ל-API.

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

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

עבור כל ממצא ראשוני, סוכן מיון יצר הוכחת היתכנות והריץ אותה במכונה וירטואלית מבודדת שהריצה ליבת Linux עם Kernel Address Sanitizer ‏(KASAN). הסוכן בחן את פלט התוכנית ואת מסוף המערכת, ושיפר את הוכחת ההיתכנות בסבבים חוזרים עד ששחזר את ההתנהגות שדווחה או מיצה את הדרכים האפשריות לעורר אותה.

בתוך 30 שעות שחזרה המערכת שלנו 1,724 חולשות, כ-74.7% מתוך 2,308 הממצאים הראשוניים. סקירת קוד סטטית בלבד עלולה להוביל לזיהויי שווא, ולכן התרשמנו מהדיוק של סוכני הניתוח ומהיעילות של סוכני המיון ביצירה אוטונומית של הוכחות היתכנות פעילות עבור כמעט שלושה רבעים מהממצאים הראשוניים.

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

העלות הכוללת של שלב האימות הייתה 73,330 דולר בקרדיטים ל-API. בתהליך האימות שלנו נדרשה יצירת הוכחת היתכנות כדי לקבוע אם ממצא ראשוני הוא חולשה אמיתית. ראינו שתהליך זה היה יקר יותר ממתן המלצה המבוססת על ניתוח סטטי בלבד, ושעלויות הניסיון לאמת ממצא אמיתי וזיהוי שווא היו דומות. לכן, סינון זיהויי שווא בשלב מוקדם יותר משפר משמעותית את יעילות התהליך מבחינת עלות.

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

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

לאחר מכן בדקו סוכני פיתוח קודי ניצול (ExploitDev) את הממצאים האלה במכונות וירטואליות מבודדות שהוגדרו עם ההגנות המופעלות בהפצת Linux סטנדרטית, ובהן מניעת הרצה במצב מפקח (SMEP), מניעת גישה במצב מפקח (SMAP), אקראיות בפריסת מרחב הכתובות של הליבה (KASLR) ו-HARDENED_USERCOPY. כך נמנעו הערכות לא מציאותיות שהתבססו על השבתת הגנות.

הסוכנים הפיקו 291 הוכחות היתכנות לדליפות מידע ו-1,169 קודי ניצול פעילים להעלאת הרשאות מקומית, שיכלו להעניק גישת root למשתמשים מקומיים ללא הרשאות מיוחדות.

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

עלות סוכן הסינון הראשוני של החולשות הייתה 44,194 דולר בקרדיטים ל-API. העלות הכוללת של שלב הניצול הייתה 775,929 דולר בקרדיטים ל-API: ‏84,929 דולר לעיבוד ממצאים מועמדים לדליפת מידע ו-691,000 דולר לממצאים מועמדים להעלאת הרשאות מקומית.

בממוצע, עיבוד ממצא מועמד להעלאת הרשאות מקומית (558 דולר) היה יקר בערך פי שניים מעיבוד ממצא מועמד לדליפת מידע (271 דולר). זאת משום שהוכחות ההיתכנות לדליפת מידע הועברו משלב האימות, ונדרשו בהן פחות שינויים כדי שיהיה אפשר להשתמש בהן בקוד ניצול. לעומת זאת, פיתוח קוד ניצול מממצא מועמד ל-LPE דרש שלבים נוספים רבים, כמו תכנון אסטרטגיית ניצול, זיהוי אובייקטים פגיעים לשימוש, עקיפת מנגנוני הגנה ועוד. שמנו לב גם שניסיונות ניצול שלא הצליחו (3,922 דולר עבור 69 מקרים) עלו הרבה יותר מניסיונות מוצלחים (360 דולר עבור 1,169 מקרים). הדבר נבע מכמה חולשות קשות לניצול, למשל תנאי מרוץ. הגדרת תנאי עצירה סביר, כמו הפסקת הניסיון לאחר שעה ללא התקדמות, הייתה מפחיתה משמעותית את עלות ExploitDev.

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

בהתאם להצעת קהילת ליבת Linux, כבר שלחנו מאות דיווחים ותיקונים לחולשות קריטיות, ואנו עובדים עם שותפי Patch the Planet כדי לשלוח בהדרגה תיקונים לשאר החולשות. עבודה זו היא חלק מהמחויבות הרחבה שלנו לתמיכה בפרויקטי קוד פתוח במסגרת Daybreak.

בחלק זה נשתף לקחים, תובנות וניתוחים נוספים מהמחקר.

במהלך המחקר ראינו את מתחזקי Linux פועלים במהירות לתיקון חולשות ולהגנה על המשתמשים. הסריקה בוצעה על הגרסה העדכנית ביותר של ליבת Linux באמצע אוקטובר 2026. כשהסריקה האוטונומית והניתוח הידני הסתיימו כעבור 10 ימים, 61 חולשות LPE כבר תוקנו בפרויקט המקור, עבור 43 הוכנו תיקונים לשילוב, ו-299 היו בתהליכי דיווח ודיון פומביים.

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

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

במהלך פיתוח התהליך, בסוף יולי 2026, מצא GPT‑5.6 Sol וניצל 166 חולשות LPE ייחודיות, בעלות כוללת של 513,690 דולר בקרדיטים ל-API.

בסריקה השנייה, באמצע אוקטובר 2026, מודל הסייבר החדש יותר מצא וניצל 948 חולשות LPE ייחודיות, בעלות כוללת של 1,213,430 דולר בקרדיטים ל-API. בשני סבבי המחקר סרקנו את ענף master של ליבת Linux, בגרסתו העדכנית ביותר באותה עת.

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

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

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

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

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

המכונות הווירטואליות ששימשו כיעד בניסוי שלנו הריצו מערכת הפעלה סטנדרטית למחשבים שולחניים, ולא יעד שהוחלש במכוון, לפי אותו מודל איומים המשמש בתחרויות אבטחת סייבר (למשל Pwn2Own⁠(נפתח בחלון חדש), TyphoonPWN⁠(נפתח בחלון חדש)). בעבר, Pwn2Own ו-TyphoonPWN הציעו תגמולים של 20,000 ו-70,000 דולר, בהתאמה, על קודי ניצול להעלאת הרשאות מקומית בליבת Linux. החלת סכומי התגמול האלה מהעבר על 948 קודי הניצול מניבה שווי היפותטי של 18.9–66.3 מיליון דולר, בערך פי 16 עד 55 מעלות התהליך שלנו.

בדקנו את התהליך שלנו גם מול תוכנית התגמול על גילוי חולשות kernelCTF⁠(נפתח בחלון חדש) של Google, שבה היעד הוא ליבת Linux מוקשחת עם משטחי תקיפה מצומצמים. הרצנו את התהליך על הגרסה העדכנית ביותר של ליבת Linux בסביבת kernelCTF. גרסה זו אינה תואמת למנגנון ההגנה SLAB_VIRTUAL שב-kernelCTF, ולכן הסרנו אותו מהתצורה. הפקנו 25 הוכחות היתכנות לדליפת מידע ו-21 קודי ניצול להעלאת הרשאות מקומית. לשם השוואה, נכון למועד הכתיבה, התקבלו ב-kernelCTF במהלך 2026 סך הכול 26 קודי ניצול מאומתים לחולשות LPE מסוג יום אפס. סבב המחקר כולו נמשך 112 שעות ועלה כ-32,936 דולר בקרדיטים ל-API, כשגילוי החולשות היווה 83.7% מעלות ה-API. אילו 21 החולשות היו מתקבלות לתוכנית, הן היו מניבות תגמול של כ-1.5 מיליון דולר, בערך פי 45 מהעלות.

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

במהלך הערכת אפשרות הניצול, סוכני ExploitDev קיבלו דוח חולשה והתבקשו ליצור קוד ניצול פעיל במלואו. התהליך שלנו סימן חולשה כמנוצלת אם הושגה בהצלחה מעטפת פקודות בהרשאות root. בהרצה מוקדמת, שלב הניצול דיווח על 200 קודי ניצול מוצלחים להעלאת הרשאות מקומית. אולם לאחר בדיקה אנושית, גילינו ש-20 מהם השיגו הרשאות root באמצעות חולשת יום אפס אחרת מזו שהוקצתה להם. הדבר מצביע על כך שגם ניצול מוצלח בידי סוכנים מצריך אימות ראוי.

בעקבות זאת הידקנו את מגבלות המשימה והוספנו בדיקה עצמאית שמוודאת שכל קוד ניצול סופי משתמש בחולשה שהוקצתה לו.

מסקנה: במחקר אבטחה אוטונומי, יש לאמת את הדרך שהובילה לתוצאה ולא רק את התוצאה עצמה; בידוד, ניטור ובדיקות עצמאיות הם אמצעי בקרה הכרחיים.

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

בניסוי השווינו בין GPT‑5.5 Cyber ל-GPT‑5.6 Cyber. לפי התצפיות שלנו, GPT‑5.5 Cyber לא זיהה באופן עקבי מתי וכיצד ליישם טכניקות קיימות לניצול חולשות בליבת Linux. לאחר מכן ריכזנו 103 טכניקות בפורמט נוח למודל, העמדנו אותן לרשות הסוכן בסביבה שלו והנחינו אותו להשתמש בהן. בבדיקה של 63 ממצאים מועמדים לניצול, הדבר העלה את שיעור ההצלחה מ-76.2% ל-88.9%.

כשחזרנו על כך עם GPT‑5.6 Cyber, המודל הצליח טוב יותר למצוא, לבחור וליישם טכניקות רלוונטיות בכוחות עצמו. הסרנו את תזמור הטכניקות והמיומנויות, ותהליך העבודה של GPT‑5.6 Cyber עם התזמור המצומצם השיג תוצאות טובות יותר מתהליך העבודה של GPT‑5.5 Cyber עם מעטפת התמיכה הנרחבת יותר. החזרת שכבת הטכניקות הנוספת ל-GPT‑5.6 Cyber סיפקה שיפור שולי בלבד של 1.5 נקודות אחוז.

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

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

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

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

בהרצת kernelCTF שלנו, לצד 21 קודי הניצול לחולשות יום אפס בליבת Linux, אבטיפוס המחקר שלנו גם מצא וניצל חולשה ב-QEMU TCG. סוכן הניתוח קיבל משימה לנתח את קוד הכניסה לקריאות מערכת. בזמן שכתב תוכניות לניסוי במעברים בין רמות הרשאה, הוא נתקל בקריסת ליבה בלתי צפויה. הוא ביצע אבחון ראשוני של הקריסה, איתר את מקור הבעיה ב-QEMU TCG ללא גישה לקוד המקור של QEMU, וכלל את החולשה בדוח. בהמשך הצליח סוכן ExploitDev לפתח קוד ניצול להעלאת הרשאות מקומית עבור חולשה זו. גילינו את החולשה הזאת ב-QEMU בעת ניתוח ידני של קודי הניצול, ואישרנו שהיא כבר תוקנה בפרויקט המקור של QEMU, אך לא בגרסת ההפצה ששימשה בניסוי.

מסקנה: מודלי חזית בעלי יכולות סייבר יכולים למצוא חולשות בתשתית הבדיקות. אנו ממליצים לבדוק כל חלק בתשתית לפני ביצוע מחקר חולשות התקפי. בדקנו את התשתית שלנו באופן יזום, וחשפנו ותיקנו חולשות רבות ב-Kata, ב-Moby/Docker, ב-gVisor ובפרויקטים נוספים.

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

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

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