כדי להשתלט על מחשב דרך כרטיס מסך RTX A6000, ההתקפה הקודמת של אותה קבוצת מחקר עצמה הייתה צריכה 21.9 שעות של דפיקות רצופות על הזיכרון. הגרסה החדשה מסיימת את אותה עבודה ב-1.1 דקות. את הקפיצה הזאת פרסמו השבוע ארבעה חוקרים מאוניברסיטת טורונטו, Chris S. Lin, Joyce Qu, Aditya Rajeev ו-Gururaj Saileshwar, במאמר שיוצג בכנס CCS בנובמבר. הם קוראים להתקפה GPUThor.

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

מאיפה זה מגיע

תא זיכרון ב-DRAM שומר ביט בתור מטען חשמלי קטן בתוך קבל זעיר. כשניגשים שוב ושוב, מהר מאוד, לשורת תאים אחת, חלק מהמטען דולף לשורות השכנות, ואם עושים את זה מספיק פעמים לפני שהזיכרון מספיק לרענן את עצמו, ביטים בשורות השכנות פשוט מתהפכים מ-1 ל-0 או להפך. לתופעה הזאת קוראים Rowhammer, והיא מוכרת כבר יותר מעשור בזיכרון DDR של מעבדים, שם השתמשו בה כדי לצאת מ-sandbox ולהסלים הרשאות.

על כרטיסי מסך זה סיפור חדש יחסית. בשנה האחרונה כמה עבודות הראו את התופעה גם בזיכרון GDDR6 של NVIDIA: GPUHammer, של אותה קבוצה מטורונטו, היה הראשון שמצא היפוכי ביטים על A6000 והשתמש בהם כדי לקלקל משקלים של מודלים ולהוריד את הדיוק שלהם, ועבודות שאחריו כבר הראו הסלמת הרשאות למערכת כולה. אבל כולן סבלו מאותה בעיה: כמות ההיפוכים הייתה זעירה. GPUHammer הגיע ל-16 היפוכים לג'יגה-בייט, GDDRHammer, הטוב שבהם, ל-758. לשם השוואה, התקפה מקבילה על מעבדים בשם Blacksmith מגיעה ל-550 אלף היפוכים לג'יגה-בייט ב-DDR4.

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

שתי התנהגויות לא מתועדות

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

הראשון נוגע לאופן שבו ה-GPU מטפל בבקשות זיכרון. שרשורים בכרטיס רצים בקבוצות של 32 שנקראות warp, וכולם מוציאים פקודות זיכרון בצעד אחיד. כשאותה קבוצה מבקשת שוב ושוב את אותו אזור, החומרה מאחדת את הבקשות לגישה פיזית אחת כדי לחסוך זמן. התוצאה מבחינת התוקף היא הרסנית: תבנית שנועדה להכות בשורה אחת בעוצמה גבוהה מתמוטטת בחזרה לגישה אחידה ורגילה. הפתרון שלהם היה לפזר את הגישות החוזרות בין warp-ים שונים, כל אחת על שורת cache אחרת בתוך אותה שורת זיכרון, כך שהן לא מתאחדות. זה לבדו שיפר את העוצמה פי 2 עד 3.

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

המספרים שיצאו מזה: 377,552 היפוכי ביטים לג'יגה-בייט על RTX A5000, 114,488 על A6000, 75,024 על A4500 ו-72,768 על A4000. זה פי 23,597 מ-GPUHammer על אותו כרטיס. כרטיס מסך נכנס סוף סוף לאותו מגרש של מעבדים.

אז למה ECC לא עצר את זה?

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

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

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

לכל אחד משני הסוגים יש שימוש אחר. שגיאה כפולה מפילה את הכרטיס: הארכיטקטורה של הכרטיסים האלה לא יודעת לבודד תקלה לתהליך אחד, ולכן כל התהליכים שרצים על ה-GPU נהרגים ונדרש איפוס מלא. על A6000 עם ECC מופעל הצליחו החוקרים לייצר 11 שגיאות כאלה על בנק זיכרון אחד ביממה, בערך אחת לשעתיים, והם מעריכים שעל A5000 מדובר באחת ל-20 דקות. בענן, כשזמן ההתאוששות הממוצע של צומת הוא 0.3 שעות, זה מוריד 13 אחוז מהזמינות היומית. יש גם תופעת לוואי מסחרית: לכל בנק יש שמונה שורות מילואים, ומהשגיאה התשיעית נדלק דגל כשל שגלוי דרך nvidia-smi ומסמן את הכרטיס כזכאי להחלפה במסגרת אחריות. על ה-A6000 שלהם זה קרה תוך 18 שעות.

מהביט שהתהפך אל ה-root

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

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

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

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

מה לא נשבר, ומה NVIDIA אומרת

החוקרים בדקו גם סוגי זיכרון אחרים, ולא ראו שם ולו היפוך אחד: לא ב-HBM, לא ב-GDDR6X ולא בדור חדש יותר של GDDR6. ההסבר שלהם הוא שהמימוש של TRR שם שונה, ושחלק משבבי GDDR6X מפעילים מנגנון ניהול רענון נוסף. זה לא אומר שהם חסינים, אלא שהתבניות הספציפיות של GPUThor לא עובדות עליהם. בכרטיסי השרתים מדור A100 והלאה יש בידוד תקלות שמונע את השבתת הכרטיס כולו, כך שמתקפת ההשבתה נחלשת, אבל תיקון השגיאות שם עדיין ברמת SECDED, ולכן מסלול ההסלמה דרך תיקון שגוי עדיין רלוונטי. גם RAS Repair שנוסף בחלק מכרטיסי Blackwell, לפי החוקרים, מאריך את ההתקפה ולא מונע אותה.

הגילוי דווח ל-NVIDIA ב-29 באפריל 2026 ובמקביל גם ל-Google, מיקרוסופט ו-AWS, ו-NVIDIA ביקשה שקט עד ה-25 באוגוסט. לפי הדיווח של BleepingComputer, החברה פרסמה ב-21 באוגוסט הנחיה שממליצה להפעיל גם ECC ברמת המערכת וגם בידוד IOMMU, לנטר טלמטריית שגיאות ולהגביל הרצה של עומסים לא מהימנים, ומדגישה שהסיכון משתנה לפי סוג הזיכרון והתצורה. קוד ההוכחה עצמו אמור להתפרסם רק ב-15 בנובמבר, ביום הראשון של הכנס.

מה זה אומר בפועל

מי שמפעיל תחנות עבודה או מכונות ענן עם RTX A4000 עד A6000, ובעיקר מי שמשתף כרטיס פיזי אחד בין משתמשים או לקוחות שלא סומכים זה על זה, צריך להתייחס לזה עכשיו: השיתוף הזה הוא ההנחה שכל ההתקפה נשענת עליה. להשאיר את ה-ECC דלוק ואת בידוד ה-IOMMU פעיל עדיין מעלה משמעותית את הרף, גם אם זה כבר לא חוסם. שווה גם לעקוב אחרי מוני השגיאות ב-nvidia-smi ואחרי דגל כשל מיפוי השורות, בזהירות: החוקרים עצמם מציינים שהמונה של שגיאות ברות תיקון הופך ללא אמין אחרי כמה אלפי שגיאות, ושמנגנון מיפוי השורות בכלל לא מגיב לתיקונים השגויים והשקטים. מי שמריץ GeForce ביתי לא נמצא בקבוצת היעד של המחקר הזה.