תוקף בלי שם משתמש וסיסמה יכול להשתיק שרת 389 Directory Server לגמרי, והוא לא צריך לשם כך להציף אותו בתעבורה. מספיק לו מספר חיבורים קטן, פרופורציונלי למספר חוטי העבודה שהשרת מגדיר, ובתצורת ברירת המחדל זה מספר קטן. הציון הוא 7.5 מתוך 10, והפגיעה היא כולה בזמינות.

מה החולשה?

שרת LDAP הוא המקום שבו ארגון מחזיק את ספר המשתמשים שלו: מי עובד כאן, לאיזו קבוצה הוא שייך, ומה הסיסמה שלו. 389-ds-base הוא הבסיס של 389 Directory Server, מימוש פתוח של שרת כזה. כשהוא מפסיק לענות, הכניסה לכל המערכות שמסתמכות עליו מפסיקה לעבוד.

השרת מטפל בבקשות בעזרת מאגר של חוטי עבודה, worker threads: מספר קבוע של עובדים שלוקחים בקשה, מטפלים בה, וממשיכים לבאה. המספר הזה מוגדר מראש, וזה המשאב שהחולשה תוקפת.

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

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

לסוג הבאג הזה קוראים דלדול משאבים. אין כאן גניבת מידע ואין הרצת קוד, וגם הדירוג אומר את זה: אפס פגיעה בסודיות, אפס בשלמות, פגיעה גבוהה בזמינות.

מי מושפע?

הרשומה אינה נוקבת בגרסאות ומפנה למעקב של Red Hat אחרי החולשה. 389-ds-base הוא הבסיס של שרת הספריות שמופץ בעולם Red Hat ובהפצות שנגזרות ממנו, ומי שמריץ אותו הוא ארגון שמנהל את המשתמשים שלו בעצמו ולא דרך שירות ענן.

כאן שווה להיות מדויקים לגבי מה המשמעות. שרת ספריות שנופל אינו דליפת מידע, הוא שיתוק: אנשים לא מצליחים להתחבר לתחנות, שירותים לא מצליחים לאמת מול הספרייה, ומערכות שנשענות על הכניסה המרכזית מפסיקות לקבל משתמשים. בארגון שבו הספרייה היא הכניסה לכל השאר, זה משבית יותר מחולשות שהציון שלהן גבוה בהרבה.

בישראל זה רלוונטי לארגונים שמנהלים מערכות מידע משלהם, לאקדמיה, ולגופים שמריצים תשתית Linux בבית. למשתמש פרטי אין כאן כלום.

האם מנוצלת בפועל?

אין דיווח על ניצול, והחולשה אינה בקטלוג ה-KEV של CISA, סוכנות הסייבר האמריקאית, שמתעדת חולשות שידוע על שימוש בהן בידי תוקפים.

חולשות השבתה בכלל מדווחות פחות מחולשות שחושפות מידע, ולא מפני שמנצלים אותן פחות. שרת שלא עונה נראה מתוך הארגון כמו תקלה ולא כמו מתקפה, ולכן חלק מהמקרים נסגרים כתקלת תשתית בלי שמישהו שואל מי פתח את החיבורים.

מה עושים?

1. עקבו אחרי התיקון. הרשומה לא נוקבת בגרסה מתוקנת, ודף החולשה של Red Hat הוא המקום שבו מתפרסם המצב לכל גרסה נתמכת, כולל אם וכאשר יוצא עדכון.

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

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

4. הגבילו מי יכול בכלל לפתוח חיבור לשרת. הניצול אינו דורש הזדהות, ולכן השאלה המעשית היא מי מגיע לשרת ברשת. שרת ספריות שנחוץ לרשת הפנימית לא צריך להיות נגיש מחוצה לה, וזאת ההגנה הממשית ביותר עד שיש עדכון.

5. ובזמן שאתם שם, הגדירו התראה למצב שבו מאגר העובדים מתמלא. חולשה שנראית כמו תקלה מזוהה רק אם מישהו מודד את הדבר הנכון.