לפני כמה ימים פורסמה הידיעה כי בספריות תקן C uClibc ו-uClibc-ng, בשימוש בהתקנים משובצים וניידים רבים, זוהתה פגיעות (עם CVE שעדיין לא הוקצה), מה שמאפשר החלפה של נתוני דמה ב-DNS cache, שניתן להשתמש בהם כדי לזייף את כתובת ה-IP של דומיין שרירותי במטמון ולהפנות בקשות לדומיין לשרת של התוקף.
לגבי הבעיה מוזכר שזה משפיע על קושחת לינוקס שונות עבור נתבים, נקודות גישה והתקני IoT, כמו גם הפצות לינוקס משובצות כמו OpenWRT ו- Embedded Gentoo.
על פגיעות
פגיעות נובע מהשימוש במזהי עסקאות צפויים בקוד לשליחת שאילתות של 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.
"חשוב לציין שפגיעות המשפיעה על ספריית C סטנדרטית יכולה להיות מורכבת למדי", כתב הצוות בפוסט בבלוג השבוע.
"לא רק שיהיו מאות או אלפי קריאות לפונקציה הפגיעה במספר נקודות בתוכנית אחת, אלא שהפגיעות תשפיע על מספר בלתי מוגבל של תוכניות מרובות ספקים אחרות המוגדרות להשתמש בספרייה זו."
בספטמבר 2021 נשלח מידע על הפגיעות ל-CERT/CC להכנת מערך מתואמת. בינואר 2022, הבעיה שותפה עם יותר מ-200 יצרנים משויך ל-CERT/CC.
במרץ, היה ניסיון ליצור קשר בנפרד עם המתחזק של פרויקט uClibc-ng, אך הוא ענה שהוא לא יכול לתקן את הפגיעות בעצמו והמליץ על חשיפה פומבית של מידע על הבעיה, בתקווה לקבל עזרה בפיתוח תיקון. הקהילה. מהיצרנים, NETGEAR הודיעה על שחרור עדכון עם הסרת הפגיעות.
חשוב לציין שפגיעות המשפיעה על ספריית C סטנדרטית יכולה להיות מורכבת למדי. לא רק שיהיו מאות או אלפי קריאות לפונקציה הפגיעה במספר נקודות בתוכנית אחת, אלא שהפגיעות תשפיע על מספר בלתי מוגבל של תוכניות אחרות ממספר ספקים המוגדרים להשתמש בספרייה זו.
יצוין כי הפגיעות מתבטאת במכשירים מיצרנים רבים (לדוגמה, uClibc משמש בקושחה מ-Linksys, Netgear ו-Axis), אך מכיוון שהפגיעות נותרה ללא תיקונים ב-uClibc וב-uClibc-ng, מידע מפורט על מכשירים וספציפיים יצרנים שקיימת בעיה במוצרים שלהם, עד לחשיפתם.
בסופו של דבר אם אתה מעוניין לדעת יותר על כך, אתה יכול לבדוק את הפרטים בקישור הבא.