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

נקודות מפתח:
  • התוקף פותח שקע AF_ALG ומבקש את אלגוריתם האימות.
  • התוקף משתמש בפונקציה splice() כדי להזין את ה-socket בדפים מהמטמון של קובץ היעד (למשל, /usr/bin/su). דפים אלה הופכים לאחר מכן לחלק מרשימת ה-hash של הפלט (ניתנים לכתיבה).
  • התוקף שולח הודעה (sendmsg) עם נתונים מאומתים משויכים (AAD) שתוכננו באופן זדוני, כאשר בתים 4-7 מכילים את הנתונים שברצונם לכתוב (למשל, קוד זדוני).
  • כאשר פענוח מופעל, authencesn לוקח את 4 הבייטים הללו מה-AAD וכותב אותם באופן זמני לסוף המאגר. עקב אופטימיזציה במקום, קצה זה של המאגר מצביע ישירות לדף מטמון הקבצים.
  • פעולת הקריפטוגרפיה נכשלת (הטקסט המוצפן אינו חוקי), אך הכתיבה של 4 בתים כבר התרחשה ולעולם לא תבוטל.
  • התוקף חוזר על התהליך כדי להזריק את הקוד שלו. כאשר /usr/bin/su מבוצע, הליבה טוענת את הגרסה המותאמת מהזיכרון, ומבצעת את הקוד שהוזרק עם הרשאות root.

כשל בהעתקה

אבטחת לינוקס ניצבת בפני אתגר נוסף בעקבות גילוי ה- פגיעות CVE-2026-31431, המכונה "כשל העתקה" על ידי החוקרים ב-Xint Code. רחוק מלהיות פגם תיאורטי, בעיית עיצוב זו זה מאפשר למשתמש מקומי ללא הרשאות להעלות את ההרשאות שלו ולקבל גישה מלאה. כמשתמש-על באופן צפוי ושקט.

החוקרים מזכירים כי פגיעות זו נוצלה בהצלחה בהפצות מובילות כמו אובונטו, אמזון לינוקס, RHEL ו-SUSE, מה שמאשר כי כל מערכת שמריצה ליבה מאוחרת יותר מגרסה 4.14 ו- שומר הפעלת תמיכה ב- AF_ALG sockets עלולה להיות פגיעה להתקפה הזו.

פעולות במקום וגלישה במטמון עמודים

בנוגע לפסיקה, צוין כי זה מתוארך לאופטימיזציה שהוצגה בשנת 2017 בתוך ה-API הקריפטוגרפי של הליבה (AF_ALG). השינוי הזה חיפשתי לחסל buffering מיותר. ביצוע פעולות הצפנה מאומתות (AEAD) ישירות באותו מרחב זיכרון, המכונה פעולות "in place".

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

אימות וכתיבה מחוץ לגבולות הזיכרון

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

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

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

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

תיקוני חירום ופתרונות להפחתת נזקים

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

תיקונים אלה כבר שולבו בליבות 6.18.22, 6.19.12 ו-7.0, והם מועברים חזרה לענפי התמיכה לטווח ארוך. עבור מנהלי מערכת שאינם יכולים להפעיל מחדש או לעדכן את השרתים שלהם באופן מיידי, מומלץ להשבית את מודול הליבה algif_aead אם הוא הוקמפל חיצונית, או להגביל באופן חמור את יצירת sockets AF_ALG באמצעות מדיניות אבטחה כגון SELinux, מגן ש, למשל, שמר על מכשירי אנדרואיד קיימים מפני איום זה.

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


הוסף כמקור מועדף בגוגל