פגיעות ב-uClibc וב-uClibc-ng המאפשרת לזייף נתונים ב-DNS cache

בספריות C הסטנדרטיות uClibc ו-uClibc-ng, המשמשות במכשירים משובצים וניידים רבים, זוהתה פגיעות (CVE לא מוקצית) המאפשרת הכנסת נתונים פיקטיביים למטמון ה-DNS, אשר ניתן להשתמש בהם כדי להחליף את כתובת ה-IP של דומיין שרירותי במטמון ובקשות להפנות לדומיין בשרת של התוקף.

הבעיה משפיעה על קושחות לינוקס שונות עבור נתבים, נקודות גישה והתקני Internet of Things, כמו גם הפצות לינוקס משובצות כגון OpenWRT ו- Embedded Gentoo. יצוין כי הפגיעות מופיעה במכשירים מיצרנים רבים (לדוגמה, uClibc נמצא בשימוש בקושחה של Linksys, Netgear ו-Axis), אך מכיוון שהפגיעות נותרה לא מתוקנת ב-uClibc ו-uClibc-ng, מידע מפורט על מכשירים ויצרנים ספציפיים שהמוצרים שלהם האם הבעיה זמינה. טרם נחשפו.

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

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

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

הבעיה אושרה בכל המהדורות הנוכחיות של uClibc ו-uClibc-ng, כולל הגרסאות העדכניות ביותר של uClibc 0.9.33.2 ו-uClibc-ng 1.0.40. בספטמבר 2021, מידע על הפגיעות נשלח ל-CERT/CC לצורך הכנה מתואמת של תיקונים. בינואר 2022, נתונים על הבעיה שותפו עם יותר מ-200 יצרנים המשתפים פעולה עם CERT/CC. במרץ, היה ניסיון ליצור קשר בנפרד עם המתחזק של פרויקט uClibc-ng, אך הוא השיב שהוא לא הצליח לתקן את הפגיעות בעצמו והמליץ ​​לחשוף בפומבי מידע על הבעיה, בתקווה לקבל עזרה בפיתוח לתקן מהקהילה. בין היצרנים, NETGEAR הכריזה על שחרור עדכון שמבטל את הפגיעות.

מקור: OpenNet.ru