פגיעות קריטית ביישום פונקציית memcpy עבור ARMv7 מ-Glibc

חוקרי אבטחה של סיסקו חָשׂוּף את הפרטים פגיעות (CVE-2020-6096) ביישום הפונקציה memcpy() שסופקה על ידי Glibc עבור פלטפורמת ARMv32 של 7 סיביות. הבעיה נגרמת מטיפול שגוי בערכים שליליים של הפרמטר שקובע את גודל השטח המועתק, עקב שימוש באופטימיזציות assembly שמתפעלות מספרים שלמים של 32 סיביות חתומים. קריאת memcpy() במערכות ARMv7 עם גודל שלילי מביאה להשוואה שגויה של ערכים וכתיבה באזור מחוץ לגבולות המאגר שצוין.

ניתן לנצל את הפגיעות לביצוע קוד במצב שבו התוקף יכול לארגן את היווצרות ערך שלילי של המשתנה שדרכו מועבר גודל הנתונים המועתקים (לדוגמה, הוא יהפוך לשלילי בעת העברת יותר מ-2 GB של נתונים, אבל במהלך ההתקפה, כדי לחרוג ממגבלות המאגר, עליך להעביר לפחות 4GB). הפונקציה memcpy() נמצאת בשימוש נרחב ביישומים, ומעבדי ARMv7 נפוצים במערכות רכב, ניידים, תעשייה, צרכנים, תקשורת והתקנים משובצים, שעלולים להיות נתונים להתקפות באמצעות Bluetooth, HD Radio/DAB, USB, CAN bus, Wi-Fi Fi ומקורות נתונים חיצוניים אחרים (לדוגמה, ניתן לתקוף שירותים ויישומים הנגישים דרך הרשת המקבלים נתוני קלט ללא הגבלות גודל).

דוגמה לכך היא יצירת ניצול פועל לתקוף שרת HTTP המובנה במערכות מידע לרכב, הנגיש דרך רשת ה-Wi-Fi של הרכב. תוקף חיצוני יכול לנצל פגיעות memcpy בשרת זה על ידי שליחת בקשת GET גדולה מאוד ולקבל גישת שורש למערכת.

במערכות 32 סיביות x86, הבעיה לא מופיעה, מכיוון שהיישום memcpy עבור ארכיטקטורה זו מפרש נכון את משתנה הגודל כערך מספר שלם ללא סימן מסוג size_t (בשפת assembly יישום עבור ARMv7 הוא מטופל כמספר שלם בסימן במקום size_t). התיקון זמין כרגע בשם תיקון, שייכלל בעדכון אוגוסט Glibc 2.32.
התיקון מסתכם בהחלפת השימוש בהוראות הרכבה הפועלות על אופרנדים חתומים (bge ו-blt) עם עמיתים לא חתומים (blo ו-bhs).

הבעיה עדיין לא נפתרה דביאן 9 ו-10 (לא נראה בדביאן 8), פדורה, אובונטו, OpenEmbedded, Tizen (בשימוש על ידי glibc). רהל и SUSE הבעיה אינה מושפעת מכיוון שהם אינם תומכים במערכות ARMv32 של 7 סיביות. אנדרואיד לא מושפע מהפגיעות מכיוון שהיא משתמשת ביישום libc (Bionic) משלה. IN OpenWRT כברירת מחדל, רוב הבניינים משתמשים ב-Musl, אך glibc זמין גם במאגר.

מקור: OpenNet.ru