לקוח LDAP שניגש לשרת הזהויות בלי להזדהות מקבל שם ריק. לא "אורח", לא "anonymous", פשוט מחרוזת ריקה. זה נשמע כמו פרט הטמעה חסר חשיבות, ובדיוק הפרט הזה הוא שאיפשר לתוקף מרוחק לרשום לעצמו חשבון בשרת FreeIPA ולהגיע ממנו להרשאות מנהל, בלי סיסמה, בלי חשבון קיים ובלי שאף אחד בארגון ילחץ על משהו.

אתמול פרסמה Red Hat את CVE-2026-76578 בציון CVSS 9.8, שעדיין מסומן אצלה כטיוטה, אחרי דיווח של Gia Bui (yabeow) מחברת המחקר Calif. בעמוד החולשה יש משפט שלא רואים הרבה מצד יצרן: Red Hat שחזרה בעצמה את הניצול מול התקנת FreeIPA ברירת מחדל, בלי שינויי הגדרות, וכתבה שהוא לא מצריך פרטי אימות, אינטראקציה של משתמש או גישה מוקדמת, אלא "רק נגישות רשתית לשירות ה-LDAP".

FreeIPA הוא שרת הזהויות הפתוח של עולם הלינוקס, המקבילה הקרובה ביותר ל-Active Directory: הוא מחזיק את המשתמשים, הקבוצות והמכונות של הארגון, מנפיק להם כרטיסי קרברוס ותעודות, ומתחתיו רץ מסד הנתונים 389 Directory Server. Red Hat מוכרת אותו בתוך RHEL בשם Identity Management. מי שמשיג עליו הרשאות מנהל לא השיג שרת אחד, הוא השיג את היכולת לייצר זהויות לכל מה שמאחוריו.

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

למה שרת שדוחה אנונימיים בכלל מקשיב להם

בעולם ה-LDAP ההרשאות נכתבות ככללים שנצמדים לרשומות: מי רשאי לקרוא, מי רשאי לכתוב, ובאיזה תנאי. אחד התנאים הנפוצים אומר משהו פשוט מאוד, שמותר לכם לערוך רשומה אם הרשומה מצביעה עליכם כבעלים שלה. השרת לוקח את השם שאיתו הלקוח התחבר, משווה אותו לשדה הבעלות ברשומה, ואם השניים זהים הפעולה מאושרת. לכלל מהסוג הזה קוראים SELFDN, והוא נכתב בתוך ACI, כלל ההרשאות של LDAP.

וכאן הבאג, CVE-2026-76560 בציון 7.5: ההשוואה טקסטואלית, והיא לא מוודאת קודם שמישהו באמת התחבר. לקוח שביצע anonymous bind (או SASL ANONYMOUS) מגיע עם DN ריק. רשומה שבה שדה הבעלות הושאר ריק במפורש מחזיקה ערך ריק. ריק שווה לריק, והבדיקה עוברת.

היא עוברת בדיוק מפני שאף אחד לא נמצא שם.

Red Hat מדגישה שהחולשה הזאת לבדה לא בהכרח מסוכנת: Red Hat Directory Server לא מגיע עם כלל SELFDN כזה מהקופסה, וההשפעה בפועל תלויה בשאלה אם פריסה מסוימת או אפליקציה שרצה מעליה הגדירה כלל בצורה הזאת. FreeIPA, מסתבר, הגדירה.

ה-token שכל אחד רשאי לנהל בעצמו

כדי שמשתמש יוכל לרשום לעצמו token של OTP, אותו קוד חד-פעמי שמשמש כשלב שני באימות, בלי לפנות למנהל המערכת, FreeIPA שולחת בהתקנה כלל הרשאות ייעודי בקובץ install/share/default-aci.ldif. לכלל הזה היו שתי תכונות: הוא לא דרש מהלקוח להיות מאומת, והוא לא הגביל אילו שדות נוספים מותר לכתוב יחד עם רשומת ה-token.

חברו את שתי החתיכות ותקבלו את המתקפה כולה. לקוח אנונימי יוצר רשומת token, משאיר את שדות ipaTokenOwner ו-managedBy ריקים, עובר את בדיקת הבעלות מפני שהוא אף אחד, ובאותה פעולת כתיבה עצמה מזריק לרשומה principal של קרברוס שעדיין לא קיים במסד, עם סיסמה שהוא בוחר. מאותו רגע יש לתוקף חשבון אמיתי בספריית הזהויות של הארגון, עם פרטי אימות שהוא כתב בעצמו, והוא יכול להתחבר איתם שוב ושוב.

אז למה התיקון מאוגוסט לא הספיק?

הטכניקה המקורית שהוצגה בדיווח הייתה גסה יותר: לא ליצור חשבון חדש אלא להתחזות ישירות לחשבון admin. שם של principal בקרברוס אפשר לכתוב ביותר מדרך אחת, ואילוץ הייחודיות ב-389-ds לא לקח בחשבון שכמה צורות כתיבה שונות מתארות את אותו שם עצמו. תוקף עם הרשאות כתיבה יכול היה לרשום principal שמתנגש בקיים ולקבל את הכרטיסים שלו. זו CVE-2026-13097, שפורסמה ב-20 באוגוסט בציון 8.7 ודווחה על ידי Vladislav Plyatsok. התיקון שלה חסם השתלטות על חשבונות קיימים.

הבעיה היא שהתיקון טיפל בהתנגשות, לא בכתיבה הלא-מאומתת שאיפשרה אותה מלכתחילה. "המתקפה עדיין מצליחה", כתבה Red Hat בהודעתה על החולשה החדשה, "כשה-principal שנוצר אנונימית מתווסף לקבוצת המנהלים תחת שם שהתוקף בוחר, ומגיע לאותה תוצאה מעשית". במילים אחרות, כשסגרו לתוקף את הדרך לגנוב את החשבון של admin, הוא פשוט הביא חשבון משלו והכניס אותו לאותה קבוצה.

החולשה השלישית: eval() שרץ לפני בדיקת ההרשאות

באותה סקירה שהדיווח גרר עלתה חולשה שלישית, CVE-2026-79678 בציון 8.1, שדווחה על ידי Calif בשיתוף Anthropic. ל-FreeIPA יש פונקציית עזר בשם template_str שממלאת תבניות טקסט, ואם המחרוזת שנוצרה מכילה קריאת eval היא מוסרת אותה למנוע ה-eval של פייתון. הפקודה idp-add, שרושמת ספק זהות חיצוני כמו Okta, Keycloak או Microsoft, מעבירה לשם את הערכים שהמשתמש נתן בדגלים organization-- ו-base-url--, בלי שום ולידציה. והחלק שהופך את זה לחולשה: המסגרת שמריצה את הפקודה מבצעת את השלב הזה בתוך pre_callback, לפני שנבדק בכלל אם המשתמש שייך לקבוצת ההרשאות External IdP server Administrators, שרק לה אמורה להיות גישה ל-idp-add.

כלומר כל חשבון מאומת בדומיין, גם החלש ביותר, מגיע ל-eval.

Red Hat מקפידה להסביר מה זה לא. זו לא הרצת קוד: ביטוי רגולרי חוסם סוגריים בתוך הביטוי שמוערך, ובלי סוגריים אי אפשר לקרוא לשום פונקציה. מה שכן נשאר הוא קריאה של משתני הסביבה של תהליך השרת והתשה של הזיכרון שלו עד כדי מניעת שירות. בהתקנת RPM רגילה של IdM משתני הסביבה מכילים קבועי נתיבים מתועדים בלבד, ולכן ההשפעה שם מוגבלת. בהתקנות שמבוססות על ה-container הרשמי של FreeIPA, שבהן נהוג להזין את סיסמאות ה-Directory Manager והמנהל דרך משתנה סביבה באתחול הראשון, Red Hat כותבת שהסיסמאות האלה עלולות להיחשף אם הן נשארו בסביבת התהליך אחרי שההתקנה הסתיימה.

מה תוקן, ומה עוד לא

התיקון ב-FreeIPA 4.13.4 הוא שורה אחת ששווה לקרוא. כלל הבעלות החשוף, userdn = "ldap:///self", הוחלף ב-(userdn = "ldap:///self" and userdn = "ldap:///all"). התוספת מתאימה לכל משתמש מאומת, וה-DN הריק של חיבור אנונימי לא יכול להתאים לה. אותו תנאי "זו הרשומה שלך" דורש עכשיו גם שיהיה שם מישהו.

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

החלק הפחות נעים נמצא במעקב של Red Hat עצמה. נכון לשעת כתיבת השורות האלה, החבילה ipa מסומנת שם כ-Affected ב-RHEL 7, 8, 9 ו-10, וגם 389-ds-base מסומנת כך ב-RHEL וב-Red Hat Directory Server 11 ו-12, בלי גרסה מתוקנת ברשימה. הקוד במעלה הזרם תוקן, החבילות שרוב הארגונים מריצים בפועל עוד לא.

מה זה אומר בפועל

אם אתם מריצים FreeIPA או IdM, השאלה הראשונה היא לא איזו גרסה מותקנת אלא מי בכלל מסוגל להגיע לפורטים 389 ו-636. ההנחיה של Red Hat עד שתצא חבילה מתוקנת היא להגביל את הגישה לשירות ה-LDAP למארחים מהימנים בלבד, דרך חוקי firewall או הפרדת רשתות, ולכבות binds אנונימיים אחרי שווידאתם ששום דבר בפריסה שלכם לא נשען עליהם. מי שמריץ את FreeIPA מהמקור יכול לעבור ל-4.13.4 כבר עכשיו. ומי שהקים את השרת מתוך ה-container הרשמי, כדאי שיבדוק בנפרד אם הסיסמאות שהוזנו בהתקנה עדיין יושבות במשתני הסביבה של התהליך.