ב-Incus, מערכת לניהול מכולות ומכונות וירטואליות על שרת, אפשר להגביל משתמש לפרויקט אחד כדי שלא יראה את מה ששייך לאחרים. לפי הרשומה, השמטה של שדה אחד מהבקשה מדלגת על ההגבלה הזאת ומאפשרת למשתמש כזה להעתיק אל עצמו נפחי אחסון של פרויקטים שלא הוקצו לו. הציון הוא 8.3 מתוך 10 בסולם CVSS 4.0, והתיקון כבר יצא.

מה החולשה?

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

לפי הרשומה, זה מה שקורה כאן סביב השדה source.type. בקשת POST אל ה-endpoint של נפחי האחסון המותאמים שמשמיטה את השדה הזה אינה עוברת את הבדיקה שאמורה לכפות את גבול הפרויקט. בתוך אותה בקשה המבקש מציין ב-source.project את הפרויקט שממנו הוא רוצה את הנפח, ובוחר פרויקט שאינו שלו. ההעתקה מתבצעת.

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

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

מי מושפע?

הרשומה מגדירה שני טווחים: מגרסה 7.0.1 לפני 7.0.2, ומגרסה 7.2.0 לפני 7.5.0. שימו לב שההתחלה כאן אינה 7.0.0 ואינה 7.1.0, אלא 7.0.1 ו-7.2.0, כך שהטווח צר מזה של הודעות אחרות שפורסמו באותו מועד. שווה להשוות מול הגרסה שרצה אצלכם ולא להסיק מהודעה אחרת בסדרה.

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

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

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

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

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

מה עושים?

1. בדקו את הגרסה המותקנת והשוו לשני הטווחים. בענף 7.0 עדכנו ל-7.0.2 ומעלה, ובענף 7.2 ואילך ל-7.5.0 ומעלה.
2. עד לעדכון, התייחסו להגבלת הפרויקט כאל גבול שאינו מחזיק בכיוון הקריאה. אם אתם מפרידים בין לקוחות או בין צוותים בדרך הזאת, ההנחה לעבוד לפיה היא שמשתמש מוגבל יכול היה להגיע לנפחים של האחרים.
3. אם יש משתמשים מוגבלים שאינם זקוקים כרגע להרשאה ליצור ולהעתיק נפחי אחסון מותאמים, הורידו להם אותה בינתיים. זאת קריאה של התיאור ולא מעקף שהמפתחים פרסמו.
4. עברו על פעולות ההעתקה של נפחי אחסון מותאמים ביומני השרת וחפשו בקשה שבה הפרויקט שצוין כמקור אינו הפרויקט שהמבקש מוגבל אליו. זה הסימן המדויק של מה שהרשומה מתארת.
5. אחרי העדכון, אם ההתקנה שירתה משתמשים מוגבלים בזמן שהיתה בטווח, התייחסו לתוכן הנפחים של אותם פרויקטים כאל מידע שאפשר שנקרא. אם יושבים שם פרטי אימות או מפתחות, החליפו אותם. הודעת האבטחה של Incus מרכזת את הפרטים.