Kees Cook של גוגל קרא למודרניזציה של תהליך העבודה על באגים בליבת לינוקס

קיס קוק, לשעבר מנהל המערכת הראשי של kernel.org ומנהיג צוות האבטחה של אובונטו שעובד כעת בגוגל לאבטחת אנדרואיד ו-ChromeOS, הביע דאגה לגבי התהליך הנוכחי של תיקון באגים בענפים היציבים של הליבה. מדי שבוע נכללים בסניפים היציבים כמאה תיקונים, ולאחר סגירת החלון לקבלת שינויים במהדורה הבאה הוא מתקרב לאלף (המתחזקים מחזיקים את התיקונים עד סגירת החלון ולאחר היווצרות " -rc1” הם מפרסמים את המצטברים בבת אחת), וזה יותר מדי ודורש הרבה עבודה עבור מוצרי תחזוקה המבוססים על ליבת לינוקס.

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

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

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

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

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

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

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

מקור: OpenNet.ru