APIC/EPIC! שבבי אינטל מדליפים סודות שאפילו הליבה לא אמורה לראות...

הנה ה-BWAIN של השבוע, המונח המצחיק שלנו עבור א באג עם שם מרשים.

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

זה מדובב דליפת ÆPIC, משחק מילים על המילים APIC ו אפוס.

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

האות Æ לא הייתה בשימוש באנגלית כתובה מאז ימי הסקסון. שמו הוא æsc, מבוטא אפר (כמו בעץ), והוא די מייצג את הצליל של ה-A במילה המודרנית ASH. אבל אנחנו מניחים שאתה אמור לבטא את המילה ÆPIC כאן בתור "APIC-slash-EPIC", או בתור "ah!-eh?-PIC".

במה מדובר?

כל זה מעלה חמש שאלות מרתקות:

• מהו APIC, ולמה אני צריך את זה?
• איך אתה יכול לקבל נתונים כאלה אפילו הגרעין לא יכול להציץ?
• מה גורם לכישלון האפי הזה ב-APIC?
• האם דליפת ÆPIC להשפיע עליי?
• מה לעשות בנוגע לזה?

מה זה APIC?

בואו נחזור אחורה לשנת 1981, אז הופיע לראשונה המחשב האישי של IBM.

המחשב כלל שבב בשם Intel 8259A בקר פסיקה לתכנות, או PIC. (בדגמים מאוחרים יותר, מה-PC AT ואילך, היו שני PICs, שרשורו יחד, כדי לתמוך באירועי פסיקה נוספים.)

מטרת ה-PIC הייתה, פשוטו כמשמעו, להפריע לתוכנית הפועלת על המעבד המרכזי (CPU) של המחשב האישי בכל פעם שהתרחש משהו קריטי בזמן שזקוק לתשומת לב מיד.

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

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

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

בימים אלה, APICs מספקים הרבה יותר מסתם משוב מהמקלדת, היציאה הטורית וטיימר המערכת.

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

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

כאן, xAPIC היא הדרך ה"מורשת" לחילוץ נתונים מבקר הפסיקות, ו x2APIC היא הדרך המודרנית יותר.

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

במצב MMIO, אתה יכול לגלות מה הפעיל אירוע APIC על ידי קריאה מאזור ספציפי של זיכרון (RAM), אשר משקף את אוגרי הקלט/פלט של שבב ה-APIC עצמו.

נתוני xAPIC אלה ממופים לבלוק זיכרון של 4096 בתים אי שם ב-RAM הפיזי של המחשב.

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

לעומת זאת, x2APIC דורש ממך קרא את נתוני ה-API ישירות מהשבב עצמו, תוך שימוש במה שמכונה רישומים ספציפיים לדגם (MSRs).

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

יש לציין שחילוץ נתוני ה-APIC ישירות מאוגרים על-שבב פירושו שהכמות הכוללת של הנתונים הנתמכים, והמספר המרבי של ליבות CPU שניתן לנהל בו-זמנית, אינם מוגבלים ל-4096 בתים הזמינים במצב MMIO.

איך אפשר לקבל נתונים שאפילו הקרנל לא יכול להציץ בהם?

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

...ולכן שאיזושהי "דליפת נתונים" לאזור ה-MMIO הזה היא לב הבעיה הזו.

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

...מדוע שנתונים של אנשים אחרים יופיעו בטעות באזור הנתונים של APIC MMIO מייצגים אפוס דְלִיפָה?

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

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

---

למידע נוסף על SGX

---

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

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

ברגע ש"נעילת" ה-SGX של המובלעת מוגדרת, רק קוד תוכנית הפועל בתוך אזור הזיכרון הסגור יכול לקרוא ולכתוב את התוכן של אותו RAM.

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

כולל הגרעין עצמו.

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

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

כפי שאתה יכול לדמיין, אם נתונים שאמורים להיות אטומים בתוך מובלעת SGX צריכים אי פעם להשתכפל בטעות ל-MMIO RAM המשמש ל"שיקוף" את נתוני ה-APIC כאשר אתה משתמש במצב "מפוי זיכרון" של xAPIC...

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

מה גורם לכשל האפי הזה ב- APIC?

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

...הם יכולים להערים על המעבד למלא את שטח ה-APIC MMIO לא רק בנתונים שהתקבלו לאחרונה מה-APIC עצמו, אלא גם בנתונים שבמקרה השתמשו במעבד לאחרונה למטרה אחרת.

התנהגות זו היא תופעת לוואי של העובדה שלמרות שעמוד הזיכרון APIC MMIO הוא בגודל של 4096 בתים, שבב ה-APIC במצב xAPIC לא באמת מייצר נתונים בשווי 4096 בתים, וה-CPU לא תמיד מנטרל נכון החלקים הלא בשימוש של אזור MMIO על ידי מילויו באפסים תחילה.

במקום זאת, נתונים ישנים שנותרו במטמון ה-CPU נכתבו יחד עם הנתונים החדשים שהתקבלו מהשבב APIC עצמו.

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

האם דליפת ÆPIC משפיעה עליי?

לרשימה מלאה של השבבים המושפעים, ראה ייעוץ משלה של אינטל.

ככל שאנו יכולים לדעת, אם יש לך מעבד אינטל דור 10 או 11, כנראה שאתה מושפע מכך.

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

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

כמובן, אפילו על שבב שעלול להיות פגיע, אם אינך מסתמך על תוכנה כלשהי שמשתמשת ב-SGX, אז גם הבאג לא חל.

והבאג, מדובב CVE-2022-21233, יכול להיות מנוצל רק על ידי תוקף שכבר יש לו גישה מקומית, ברמת אדמין (שורש) למחשב שלך.

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

אז, מכונות וירטואליות אורחות (VMs) הפועלים תחת שליטה של ​​מערכת הפעלה מארח ב-Hypervisor כגון HyperV, VMWare או VirtualBox, כמעט בוודאות אינם יכולים להשתמש בטריק הזה כדי לשדוד סודות מאורחים אחרים או מהמארח עצמו.

הסיבה לכך היא שמכשירי VM אורחים בדרך כלל אינם מקבלים גישה למעגלי APIC האמיתיים במעבד המארח; במקום זאת, כל אורח מקבל APIC מדומה משלו שייחודי לאותו VM.

מה לעשות?

אל תיבהל.

במחשב נייד או שולחני, ייתכן שאינך בסיכון כלל, או בגלל שיש לך מחשב ישן יותר (או, למזלכם, חדש לגמרי!), או בגלל שאתה ממילא לא מסתמך על SGX.

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

אם יש לך שרתים פגיעים ואתה מסתמך על SGX כחלק מהאבטחה התפעולית שלך, בדוק את ייעוץ האבטחה של אינטל INTEL-SA-00657 למידע על הגנה והפחתה.

לפי החוקרים שכתבו את זה, "אינטל [הוציאה] עדכוני מיקרוקוד ו-SGX Software Development Kit כדי לתקן את הבעיה."

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

---