ה-sandbox עבד. גבול ההרשאות של Mistral לא.

אפשר לבודד תהליך בתוך sandbox ובכל זאת לתת לו מפתח למערכת חשובה.

זה הלקח הלא נעים מ-מחקר חדש שפרסמה Vero Security. לפי Vero, החוקרים שלה מצאו פרטי גישה ל-proxy בתוך סביבת סוכן קוד בענן של Mistral. הם טוענים שהטוקן הגיע למערך מודלים פנימי, לשער כלים ולמדדים תפעוליים שלא היו נגישים ישירות מהאינטרנט.

המאמר הזה מבוסס על הבדיקה והדיווח של Vero. לא מצאתי advisory מקביל של Mistral שמתאר באופן עצמאי את הארכיטקטורה שנפגעה או את התיקון. לפי ציר הזמן של Vero, ‏Mistral אישרה את קבלת הדיווח ב-31 באוגוסט, אפשרה בדיקות נוספות והעלתה תיקון ב-10 בספטמבר.

ההבחנה הזאת חשובה. הפרטים הטכניים בהמשך הם מה ש-Vero אומרת שמצאה, לא שחזור עצמאי.

הכול התחיל בפעולה רגילה של סוכן קוד

Vero בדקה את סביבת הקוד שזמינה דרך Le Chat של Mistral. החוקרים ביקשו תחילה מהסוכן להדפיס את משתני הסביבה. המודל סירב בטענה שהם עשויים להכיל מידע רגיש.

ה-guardrail עצר את הבקשה הישירה, אבל לא הוציא את הערך הרגיש מהסביבה.

החוקרים חיברו repository שכלל קובץ בינארי מוכן בשם local_server והוראות שהציגו אותו כחלק מהפרויקט. אחר כך הם ביקשו מהסוכן להפעיל את השרת המקומי. הסוכן הריץ את הקובץ בתוך סביבת ה-Linux שלו.

הקובץ הדפיס והחזיר את משתני הסביבה. לפי Vero, ביניהם הופיע ערך בצורה הזאת:

SANDBOX_PROXY_GITHUB_PROXY=http://sandbox-proxy:<JWT>@sandbox-proxy-prod-swe.mistralai.com:80

החלק החשוב לא היה שם המשתנה, אלא ה-JWT שאפשר היה להשתמש בו מחדש.

Vero מדווחת שה-proxy עצמו היה נגיש מהאינטרנט. בעזרת הטוקן החוקרים הצליחו להעביר דרכו בקשות לכתובות פנימיות של Mistral שלא היו נגישות ישירות.

לא נדרשה בריחה מה-container. הקוד רץ בדיוק במקום שבו המוצר אפשר לו לרוץ.

לאן הטוקן הגיע לפי Vero

אחרי הדיווח הראשוני, Vero אומרת ש-Mistral נתנה לצוות רשות להמשיך לבדוק.

החוקרים מתארים גישה לשלושה אזורים:

1. מערך מודלים פנימי. לפי Vero, endpoint של רשימת מודלים חשף מודלים שפורסמו, checkpoints שעדיין לא פורסמו, גרסאות פנימיות ומודלים של חברות אחרות שהתארחו בתשתית. הצוות אומר שבקשות inference עבדו בלי מגבלה למשתמש שהוא הצליח לזהות.
2. שער כלים. מסמך OpenAPI חשף לפי הדיווח נתיבי OCR וכלים לסוכנים, כולל web fetch ומחברי MCP. ‏Vero אומרת ששליטה בכתובת, ב-query וב-headers הפכה את כלי הרשת ליכולת לבצע בקשות מצד השרת.
3. מדדים תפעוליים. לפי Vero, ‏endpoint לא מאומת של Prometheus חשף היקפי שימוש לפי מודל, מונים של תתי-מערכות ושמות של פרויקטים פנימיים.

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

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

למה ה-sandbox לא הספיק

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

אבל sandbox עונה על שאלה אחת:

לאילו משאבים במחשב המארח התהליך יכול להגיע?

הוא לא עונה אוטומטית על שאלה אחרת:

אילו הרשאות ונתיבי רשת הכנסנו בכוונה אל תוך התהליך?

אם credential נמצא במשתנה סביבה, בקובץ קריא, בארגומנט של פקודה או בשירות metadata מקומי, קוד בתוך ה-sandbox עשוי להעתיק אותו. אם יש גם גישה החוצה לרשת, הקוד עשוי לשלוח אותו למקום אחר.

לכן ה-guardrail בפרומפט היה המקום החלש ביותר לשמור על הסוד. המודל סירב להדפיס את הסביבה, אבל יכול היה להריץ קוד שקרא את אותה סביבה.

Repository זדוני יכול לעשות את זה בזמן התקנה. README מורעל יכול לשכנע את הסוכן להפעיל כלי עזר. Prompt injection בתוך issue, עמוד רשת או תשובה מכלי יכול לבקש אותה פעולה בלי להזכיר credentials בכלל.

בידוד credentials צריך להיות שכבה נפרדת

העיצוב החזק ביותר הוא לא להכניס credential לשימוש חוזר אל ה-sandbox מלכתחילה.

עבור קריאה ל-API חיצוני, אפשר להשתמש ב-broker אמין שנמצא מחוץ לסביבת הסוכן:

agent sandbox -> policy broker -> approved destination
                         |
                         +-> inject short-lived credential

ה-sandbox שולח בקשה ל-broker צר. ה-broker בודק יעד, שיטה, tenant, ‏repository, מודל ופעולה. רק אז הוא מצרף credential שה-sandbox עצמו לעולם לא רואה.

אם חייבים להכניס טוקן לסביבה, צריך להוריד את הערך שלו:

• להנפיק אותו למשימה אחת או לסשן אחד
• לתת לו לפוג תוך דקות, לא ימים
• להגביל אותו לשירות אחד ולקבוצה קטנה של נתיבים
• לקשור אותו לזהות של ה-sandbox או לנתיב הרשת שלו
• להפעיל quotas ומגבלות מקביליות
• לוודא שאי אפשר להשתמש בו מהאינטרנט הציבורי

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

Least privilege כולל גם את הרשת

צוותים מדברים בדרך כלל על least privilege כבעיה של IAM. סוכנים צריכים גם הרשאות רשת מינימליות.

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

בקרות שימושיות כוללות:

• חסימת egress כברירת מחדל ורשימת יעדים מאושרים
• בדיקת DNS והפניות ב-proxy שאוכף את המדיניות
• מקטעי רשת נפרדים לסביבות סוכנים ולמערכות בקרה פנימיות
• אימות בכל שירות פנימי, גם אם הוא נמצא מאחורי firewall
• זהות נפרדת ולוגים לכל sandbox
• התראות כשסשן אחד סורק מודלים, קורא metrics או מחפש hosts פנימיים

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

מה ידוע ומה עדיין לא ברור

Vero פרסמה מסלול שחזור מפורט, דוגמה למשתנה הסביבה, סוגי endpoints, ניתוח השפעה וציר זמן של disclosure. הדוח שלה אומר ש-Mistral שיתפה פעולה ותיקנה את הבעיה לפני הפרסום.

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

זה לא הופך את המחקר לחסר חשיבות. זה אומר שצריך לקרוא אותו כממצא מסוים שעבר תהליך disclosure אחראי, ולא כ-postmortem מלא של הספק.

רשימת בדיקות מעשית

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

1. האם קוד שרץ ב-sandbox יכול להציג את כל משתני הסביבה?
2. האם הוא יכול לקרוא credentials מחוברים, היסטוריית shell, קובצי הגדרות או metadata מקומי?
3. האם אפשר להשתמש ב-credential מחוץ ל-sandbox?
4. האם הוא מגיע ליותר שירותים ממה שהמשימה דורשת?
5. האם ה-sandbox יכול לפנות לשרתים פנימיים שאינם מאמתים כל בקשה?
6. האם סשן אחד יכול לצרוך inference או כלי עבודה בלי הגבלה?
7. האם תזהו סריקת טוקנים, חיפוש ברשת הפנימית או קריאות חריגות לכלים?
8. האם אפשר לבטל זהות של sandbox אחד בלי לפגוע בכל הסשנים האחרים?

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

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

מקורות

• Vero Security Research: ה-sandbox של הסוכן שלכם אינו פרטי
• Mistral Docs: סביבת sandbox
• Mistral Docs: אבטחה
• Mistral Docs: הרשאות ל-GitHub repositories

צילום ראשי: Datacenter Server Racks, צילום של Carl Lender מ-4 בנובמבר 2015. רישיון Creative Commons Attribution 2.0. הוקטן מ-6000 x 4000 ל-1920 x 1280 פיקסלים ונדחס כ-JPEG; ללא עריכות נוספות. זהו צילום להמחשה של תשתית מרכז נתונים. הוא אינו מציג מערכות של Mistral, את סביבת הבדיקה של Vero או את השירותים שעליהם דווח. אין בו הבעת תמיכה.