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

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

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

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

מעניין שבעבר, מנהיג הקבוצה שערכה את הניסויים היה מעורב בתיקון לגיטימי של נקודות תורפה, למשל, זיהוי דליפות מידע בערימת ה-USB (CVE-2016-4482) ובתת-מערכת הרשת (CVE-2016-4485) . במחקר על הפצת פגיעות התגנבות, צוות מאוניברסיטת מינסוטה מביא את הדוגמה של CVE-2019-12819, פגיעות הנגרמת על ידי תיקון ליבה ששוחרר ב-2014. התיקון הוסיף קריאה ל-put_device לבלוק הטיפול בשגיאות ב-mdio_bus, אך חמש שנים לאחר מכן התברר כי מניפולציה כזו מובילה לגישה לבלוק הזיכרון לאחר שחרורו ("use-after-free").

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

תוספת 1: אם לשפוט על פי פעילותו של מחבר התיקון שנמתח עליו ביקורת, הוא שולח תיקונים לתתי מערכות ליבה שונות מזה זמן רב. לדוגמה, מנהלי ההתקן של radeon ו-nouveau אימצו לאחרונה שינויים עם קריאה ל-pm_runtime_put_autosuspend(dev->dev) בבלוק שגיאה, מה שגרם אולי לשימוש במאגר לאחר שחרור הזיכרון המשויך אליו.

נספח 2: גרג החזיר 190 התחייבויות הקשורות ל-"@umn.edu" ויזם בדיקה מחדש שלהם. הבעיה היא שחברים עם כתובות "@umn.edu" לא רק התנסו בדחיפת תיקונים מפוקפקים, אלא גם תיקנו נקודות תורפה אמיתיות, והחזרת שינויים עלולה לגרום לחזרת בעיות אבטחה שתוקנו בעבר. חלק מהמתחזקים כבר בדקו מחדש את השינויים שהוחזרו ולא מצאו בעיות, אבל אחד מהמתחזקים ציין שבאחד מהתיקונים שנשלחו אליו היו שגיאות.

מקור: OpenNet.ru