Glibc כולל תיקון לפגיעות memcpy שהוכנה על ידי מפתחי Aurora OS

מפתחי מערכת ההפעלה הסלולרית Aurora (מזלג של מערכת ההפעלה Sailfish שפותחה על ידי חברת Open Mobile Platform) שיתפו סיפור חושפני על חיסול פגיעות קריטית (CVE-2020-6096) ב-Glibc, המופיע רק בפלטפורמת ARMv7. מידע על הפגיעות נחשף עוד בחודש מאי, אך עד הימים האחרונים לא היו תיקונים זמינים, למרות העובדה שהחולשות שהוקצה רמה גבוהה של סכנה ויש אב טיפוס עובד של ניצול המאפשר לך לארגן ביצוע קוד בעת עיבוד נתונים המעוצבים בצורה מסוימת בפונקציות memcpy() ו- memmove(). תיקוני חבילה עבור דביאן и אובונטו טרם פורסמו והפגיעות נותרה ללא תיקון במשך כמעט חודשיים מרגע החשיפה לציבור וחמישה חודשים מרגע ההודעה למפתחי Glibc.

הפגיעות התבטאה ביישום memcpy() ו- memmove() בשפת assembly עבור ARMv7 ונגרמה מעיבוד שגוי של ערכים שליליים של הפרמטר שקובע את גודל האזור המועתק. בעיות בפיתוח תיקונים החלו כאשר חברות SUSE и רד האט הודיעו כי הפלטפורמות שלהם אינן מושפעות מהבעיה, מכיוון שהן אינן בונות למערכות ARMv32 של 7 סיביות, ולא השתתפו ביצירת תיקון. נראה שהמפתחים של הפצות משובצות רבות הסתמכו על צוות Glibc, וגם לא היו מעורבים באופן פעיל בהכנת התיקון.

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

מכיוון של-Aurora OS יש מבנה של 32 סיביות עבור ARM, המפתחים שלה החליטו לסגור את הפגיעות בעצמם ולהציע פתרון לקהילה. הקושי היה שהיה צורך לכתוב מימוש שפת assembly יעיל של הפונקציה ולקחת בחשבון אפשרויות שונות לארגומנטים קלט. היישום נכתב מחדש באמצעות הוראות לא חתומות. תיקון התברר שהוא קטן, אבל הבעיה העיקרית הייתה שמירה על מהירות ביצוע והימנעות מירידה בביצועים של פונקציות memcpy ו- memmove, תוך שמירה על תאימות לכל שילובי ערכי הקלט.

בתחילת יוני הוכנו שתי גרסאות של התיקון, שעברו את מסגרת הבדיקה של מנהלי ה-Glibc ואת חבילת הבדיקות הפנימית של Aurora. ב-3 ביוני נבחרה אחת האפשרויות ו נשלח לרשימת התפוצה של Glibc. שבוע מאוחר יותר
היה מוּצָע עוד תיקון דומה בגישה, שתיקן בעיה ביישום multiarch, ש-Huawei ניסתה בעבר לתקן. הבדיקה ארכה חודש ו רישום משפטי בשל חשיבות התיקון.
תיקוני 8 ביולי התקבלו לסניף הראשי של המהדורה הקרובה של glibc 2.32. היישום כולל שני תיקונים - первый עבור יישום multiarch של memcpy עבור ARMv7, ו שני למימוש שפת ההרכבה הכללית של memcpy() ו- memmove() עבור ARM.

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

מקור: OpenNet.ru