בפשטות אינטל המשיכה להיות היעד לפגיעות שונות שמובילים לדליפת נתונים ודיברנו עליהם הרבה כאן בבלוג ובזה החדש הזה, אינטל עדיין לא יוצאת מהכלל.
וזה צוות חוקרים מאוניברסיטת אמסטרדם החופשית ha זיהה פגיעות חדשה (CVE-2020-0543) במבני מיקרו-ארכיטקטורה של מעבדי אינטל, וזה בולט לעובדה ש מאפשר לך לשחזר את התוצאות של כמה הוראות לרוץ על ליבת מעבד אחרת.
זוהי הפגיעות הראשונה של המנגנון של ביצוע ספקולטיבי של הוראות, המאפשר דליפת נתונים בין ליבות מעבד נפרדות (בעבר, דליפות הוגבלו לשרשורים שונים של גרעין).
החוקרים הם קראו לבעיה CROSSTalk, אך מסמכי אינטל מתייחסים לפגיעות כ- SRBDS (Sample Special Register Buffer Data).
אודות CROSSTalk
הפגיעות שייכת למעמד של בעיות MDS, שהוצגה לפני שנה, ו מבוסס על יישום שיטות ניתוח של צד שלישי לנתונים במבני מיקרו-ארכיטקטורה.
עקרון CROSSTalk קרוב לפגיעות RIDL, אך שונה במקור הדליפה. הפגיעות החדשה מתפעל דליפת חיץ ביניים לא תועדו בעבר המשותף בין כל ליבות המעבד.
תמצית הבעיה היא שכמה הוראות מיקרו-מעבד, כולל RDRAND, RDSEED ו- SGX EGETKEY, מיושמות באמצעות פעולת המיקרו-ארכיטקטורה הפנימית SRR (Special Register Reads).
במעבדים פגיעים, הנתונים המוחזרים עבור SRR מוכנסים למאגר ביניים המשותף לכל ליבות המעבד, ולאחר מכן הוא מועבר למאגר האוכלוסייה המשויך לליבה הפיזית הספציפית של המעבד עליו מתחיל ההפעלה. ואז, ממאגר הריפוד, הערך מועתק לרשמים הגלויים ליישומים.
גודל המאגר המשותף הביניים תואם את שורת המטמוןכי גדול בדרך כלל מגודל הנתונים הנקראים ופעולות קריאה שונות משפיעות על קיזוזים שונים במאגר.
מאחר שהמאגר המשותף מועתק לכל מאגר המילוי, לא רק החלק הנדרש לפעולה הנוכחית מועבר, אלא גם הנתונים הנותרים מפעולות אחרות, כולל אלה שבוצעו על ליבות מעבד אחרות.
אם ההתקפה מאורגנת בהצלחה, משתמש מקומי מאומת במערכת יכול לקבוע את התוצאה ביצוע ההוראות RDRAND, RDSEED ו- EGETKEY בתהליך מוזר או בתוך המובלעת של Intel SGX, ללא קשר לליבת המעבד שהקוד פועל עליו.
החוקרים שגילה את הבעיה פרסם אב-טיפוס לנצל שהדגים את האפשרות לדלוף מידע על ערכים אקראיים המתקבלים באמצעות הוראות RDRAND ו- RDSEED לשחזור המפתח הפרטי ECDSA שעובד במובלעת Intel SGX לאחר ביצוע פעולה אחת בלבד בחתימה דיגיטלית במערכת.
זה הוכיח כי מגוון רחב של מעבדי Intel שולחניים, ניידים ושרתים, כולל Core i3, i5, i7, i9, m3, Celeron, Atom, Xeon, Scalable Xeon וכו ', הם פגיעים.
ראוי לציין זאת אינטל קיבלה הודעה על הפגיעות בספטמבר 2018 וביולי 2019 סופק ניצול אב-טיפוס שהראה דליפת נתונים בין ליבות המעבד, אך פיתוח הפיתרון התעכב בגלל מורכבות יישומו.
בעדכון המיקרו-קוד המוצע היום, הבעיה נחסמת על ידי שינוי התנהגות ההוראות RDRAND, RDSEED ו- EGETKEY כדי להחליף את הנתונים במאגר המשותף כדי למנוע מידע שיורי להתיישב בו.
בנוסף, השעיית גישה למאגר חלה עד להשלמת פעולות הקריאה והכתיבה.
תופעת לוואי של הגנה זו הוא גידול בעיכובים כאשר RDRAND, RDSEED ו- EGETKEY מבוצעות, והפחתה בביצועים כשמנסים לבצע הוראות אלה בו זמנית על מעבדים לוגיים שונים. תכונות אלה יכולות להשפיע לרעה על הביצועים של יישומים מסוימים.
מקור: https://www.vusec.net
הכותרת אינה מובנת, כאשר יש שלוש נקודות, פסיק אמור לעבור, וכן, כי ל"כן "יש סימן מבטא.