נמצאה פגיעות בתת-מערכת ה-tty של ליבת לינוקס

חוקרים מצוות Google Project Zero שוחררו לאחרונה דרך פוסט בבלוג שיטה חדשה לניצול נקודות תורפה (CVE-2020-29661) ביישום של מטפל ioctl TIOCSPGRP של מערכת המשנה של ליבת לינוקס tty, כמו גם מנגנוני הגנה מפורטים שעלולים לחסום את הפגיעויות הללו.

זה מוזכר בפוסט ש הבעיה נגרמת על ידי שגיאה בהגדרות הנעילה, המוביל למצב גזע בקוד של /tty/tty_jobctrl.c, ששימש ליצירת תנאים לגישה לזיכרון לאחר ההשקה (שימוש-אחרי-חופשי), מנוצל על ידי מרחב המשתמש באמצעות מניפולציה עם ioct- על ידי קריאת TIOCSPGRP.

בנוסף למידע שפורסם, גם בוצעה הדגמת ניצול פונקציונלי להסלמה של הרשאות פנימה דביאן 10 עם ליבה 4.19.0-13-amd64 וזה גם לא שולל שזה עלול להשפיע על הפצות שונות, ביניהן כמובן כאלה המבוססות על דביאן ונגזרות ממנה.

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

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

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

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

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

בכל פעם שנפתח / dev / ptmx (קיצור של "מכפיל פסאודו-טרמינל"), מתאר הקובץ המתקבל מייצג את צד ההתקן (המכונה בתיעוד ובמקורות הליבה כ"הפסאודו-טרמינל הראשי") של התקן. פסאודו חדש -מָסוֹף.

 התקן הטרמינל המתאים (שאליו מתחברת מעטפת בדרך כלל) נוצר באופן אוטומטי על ידי הליבה תחת / dev / pts / .

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

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

כמו כן, מוזכרת פגיעות דומה (CVE-2020-29660) שנמצאה בו-זמנית ביישום קריאת TIOCGSID ioctl, אך גם הוסרה בכל מקום.

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


השאירו את התגובה שלכם

כתובת הדוא"ל שלך לא תפורסם. שדות חובה מסומנים *

*

*

  1. אחראי על הנתונים: AB Internet Networks 2008 SL
  2. מטרת הנתונים: בקרת ספאם, ניהול תגובות.
  3. לגיטימציה: הסכמתך
  4. מסירת הנתונים: הנתונים לא יועברו לצדדים שלישיים אלא בהתחייבות חוקית.
  5. אחסון נתונים: מסד נתונים המתארח על ידי Occentus Networks (EU)
  6. זכויות: בכל עת תוכל להגביל, לשחזר ולמחוק את המידע שלך.