Checkpoint הציעה את טכניקת הגנת Safe-Linking, מה שהקשה על ניצול נקודות התורפה

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

תיקונים המטמיעים קישור בטוח הוכנו עבור Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) ו-Google TCMalloc, ומוצעים גם לשדרוג ההגנה ב-Chromium (ב
מאז 2012, Chromium כבר בנתה את טכניקת ההגנה של MaskPtr שמטרתה לפתור את אותה בעיה, אך הפתרון של Checkpoint מפגין ביצועים גבוהים יותר).
תיקונים מוצעים כבר אושרו למסירה במהדורה של אוגוסט גליבק 3.32 ו-Safe-Linking יהיה זמין כברירת מחדל. uClibc-NG תומך ב-Safe-Linking נכנס כלול במהדורה 1.0.33 ומופעל כברירת מחדל. שינויים ב-gperftools (tcmalloc הישן) מְקוּבָּל, אך יוצע כאופציה במהדורה עתידית.

מפתחים TCMalloc (חדש tcmalloc) סירב לקבל לשנות, תוך ציון ירידה חמורה בביצועים והצורך להוסיף בדיקות מקיפות כדי לבדוק באופן קבוע שהכל עובד כמצופה. בדיקות של מהנדסי Checkpoint הראו ששיטת Safe-Linking אינה מביאה לצריכת זיכרון נוספת, והביצועים בעת ביצוע פעולות ערימה מופחתים בממוצע ב-0.02% בלבד, ובמקרה הגרוע ביותר ב-1.5% (לשם השוואה, התקורה ב- השיטה המשמשת ב-Chromium מוערכת כ"פחות מ-2%"). הַכלָלָה
קישור בטוח מביא לביצוע 2-3 הוראות הרכבה נוספות בכל פעם ש-free() נקרא, ו-3-4 הוראות בכל פעם שנקרא malloc(). אין צורך להפעיל את שלבי האתחול ויצירת ערכים אקראי.

ניתן להשתמש ב-Safe-Linking לא רק כדי לשפר את האבטחה של יישומי ערימה שונים, אלא גם כדי להוסיף בקרות שלמות לכל מבני נתונים המשתמשים ברשימות מקושרות בודדות של מצביעים הממוקמים ליד המאגרים עצמם. השיטה פשוטה מאוד ליישום ודורשת רק הוספת מאקרו אחד והחלתו על מצביעים לבלוק הבא בקוד (לדוגמה, עבור Glibc משתנה רק כמה שורות קוד). השיטה מסתכמת בשינויים הבאים:

+#define PROTECT_PTR(pos, ptr) \
+ ((__typeof (ptr)) (((((size_t) pos) >> 12) ^ ((size_t) ptr)))

+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)

- nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd);
...

המהות של השיטה היא להשתמש בנתונים אקראיים ממנגנון האקראיות של כתובות ASLR (mmap_base) כדי להגן על רשימות מקושרות בודדות כגון Fast-Bins ו-TCache. לפני החלת הערך על מצביע לרכיב הבא ברשימה, הוא מבצע המרת מסיכה ובודק יישור עמוד. המצביע מוחלף בתוצאה של הפעולה "(L >> PAGE_SHIFT) XOR (P)", כאשר P הוא הערך של המצביע ו-L הוא מיקום הזיכרון בו מאוחסן המצביע.

בעת שימוש במערכת ASLR (Rendomization Space Layout Address) חלק מהסיביות L עם כתובת בסיס הערימה מכיל ערכים אקראיים המשמשים כמפתח לקידוד P (חולץ על ידי פעולת העברה של 12 סיביות עבור דפים של 4096 בתים). מניפולציה זו מפחיתה את הסיכון לחטיפת מצביע בעת ניצול, מכיוון שהמצביע אינו מאוחסן בצורתו המקורית והחלפתו דורשת ידע על הקצאת הערימה. בנוסף, קוד התיקון מכיל גם בדיקה נוספת ליישור בלוק, שלא מאפשר לתוקף להחליף מצביע בערך לא מיושר ודורש ידע על מספר הביטים שמיושרים, מה שבמערכות 64 סיביות מאפשר בנוסף חסימה 15 מתוך 16 ניסיונות תקיפה שאינם לוקחים בחשבון יישור.

השיטה יעילה להגנה מפני התקפות המשתמשות בשכתוב מצביע חלקי (שינוי בתים נמוכים), שכתוב מצביע מלא (הפניה מחדש לקוד התוקף) ושינוי מיקום הרשימה בכתובת לא מיושרת. כדוגמה, הוכח שהשימוש ב-Safe-Linking ב-malloc יאפשר חסימת ניצול לאחרונה מזוהה על ידי אותם חוקרי פגיעות CVE-2020-6007 באור החכם של Philips Hue Bridge, הנגרם על ידי הצפת חוצץ ומאפשר לך להשיג שליטה על המכשיר.

מקור: OpenNet.ru