נחשפו פרטים על התיקונים שהגישה אוניברסיטת מינסוטה

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

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

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

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

בסך הכל, באוגוסט 2020 נשלחו חמישה תיקונים מהכתובות האנונימיות acostag.ubuntu@gmail.com ו- jameslouisebond@gmail.com (מכתב מאת ג'יימס בונד): שניים נכונים ושלוש כולל שגיאות נסתרות, שיצרו תנאים להופעתם של פגיעויות.

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

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

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

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

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

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

התיקון השני הכיל גם תנאים לבעיית הבלאי שלאחר השחרור. התיקון שצוין לא התקבל על ידי המתחזק, שדחה את התיקון בגלל בעיה אחרת עם list_add_tail, אך לא שם לב שניתן לשחרר את מצביע "chdev" בפונקציה put_device, המשמשת בהמשך בשיחה ל- dev_err (& chdev -> dev ..). עם זאת, התיקון לא התקבל, אם כי מסיבות שאינן קשורות לפגיעות.

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

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

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

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

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


תוכן המאמר עומד בעקרונותינו של אתיקה עריכתית. כדי לדווח על שגיאה לחץ כאן.

היה הראשון להגיב

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

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

*

*

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