הרשומה מתארת חולשה ב-Argo CD, הכלי שמסנכרן את מה שכתוב במאגר Git אל אשכול Kubernetes, שמאפשרת להריץ קוד בתוך רכיב ה-repo-server שלו. הציון הוא 9.9 מתוך 10, הטווח המושפע מתחיל בגרסה 2.1.0, והתיקון נכנס בגרסאות 3.3.15, 3.4.10, 3.5.4 ו-3.6.0-rc2. סייג אחד מצמצם את התמונה מאוד, והוא מופיע בהמשך.

מה החולשה?

Argo CD עובד לפי רעיון פשוט: מה שכתוב במאגר Git הוא מה שאמור לרוץ באשכול. רכיב בשם repo-server מוריד את המאגר, מריץ את כלי התבניות שבונים ממנו את קובצי התצורה הסופיים, ומחזיר אותם. שני הכלים שבהם מדובר כאן הם Kustomize ו-Helm, ו-Argo CD קורא להם בשם המשתמש.

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

והחלק שהופך את זה להרצת קוד: לפי התיאור, Helm טוען תוספת הורדה מתוך התיקייה .data/plugins שמתחת לאותו configHome בלי שלב התקנה נפרד, ומריץ את התוכנית שלה כשכתובת המאגר של helmCharts משתמשת בפרוטוקול שהתוספת מצהירה עליו. כלומר אין צורך לשכנע אף אחד להתקין משהו. די להניח קובץ בתיקייה הנכונה ולבקש כתובת שמפנה אליו.

הקוד רץ בהרשאות המשתמש של repo-server, ומשם, לפי הרשומה, הוא יכול לקרוא את פרטי האימות של המאגרים ונתונים אחרים שנגישים לתהליך. אלה המפתחות שבהם Argo CD עצמו נכנס למאגרי הקוד של הארגון. הסיווג הוא CWE-829, הכללה של רכיב ממקור שאינו מהימן.

לרשומה שני מסלולים שבהם הקבצים מגיעים לשם. הראשון מובן מאליו: מי שיכול לכתוב למאגר Git שאפליקציה ב-Argo CD בונה ממנו מכניס אותם לשם. השני דורש פחות בהרבה. דרך POST לכתובת /api/v1/applications/manifestsWithFiles אפשר להעלות את אותם קבצים, ואותו מסלול נחשף גם דרך הפקודה argocd app diff עם הדגלים --local ו--server-side-generate. הרשומה מדגישה מה נדרש כדי להשתמש בו: הרשאת get על אפליקציה קיימת, וזה הכול. לא הרשאת עדכון, לא הרשאת סינכרון, ולא הרשאת כתיבה לשום מאגר.

הרשאת צפייה שמספיקה להרצת קוד אינה מה שמנהל מצפה לו כשהוא מחלק הרשאות קריאה.

מי מושפע?

הטווח מתחיל בגרסה 2.1.0 ונמשך עד הגרסאות שמתקנות אותו: 3.3.15, 3.4.10, 3.5.4 ו-3.6.0-rc2. כל גרסה שקודמת לאחת מאלה בקו שלה נחשבת מושפעת.

אבל התנאי שקובע כאן אינו הגרסה. הרשומה אומרת במפורש ששני המסלולים דורשים שהמפעיל הדליק מראש את הדגל --enable-helm עבור kustomize build, ושהתקנות שלא הדליקו אותו אינן מושפעות. זאת הבדיקה הראשונה שכדאי לעשות, ובחלק מההתקנות היא תסגור את העניין בשתי דקות.

הרשומה מוסיפה פרט על השורש של הבעיה: Kustomize בגרסה 4.1.0 היא זו שהתחילה להעביר את helmGlobals.configHome אל Helm.

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

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

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

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

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

מה עושים?

1. בדקו קודם כול אם הדגל --enable-helm דלוק אצלכם עבור kustomize build בהגדרות ה-repo-server. אם הוא כבוי, הרשומה אומרת שההתקנה אינה מושפעת, וזה סוף הבדיקה.
2. עדכנו לגרסת התיקון של הקו שאתם נמצאים בו: 3.3.15, 3.4.10, 3.5.4 או 3.6.0-rc2.
3. אם אינכם יכולים לעדכן עכשיו והדגל דלוק, בדקו אם אתם בכלל צריכים אותו. כיבוי שלו מוציא אתכם מטווח החולשה לפי מה שהרשומה עצמה קובעת, וזה פתרון ביניים מלא ולא חלקי.
4. עברו על מי שיש לו הרשאת get על אפליקציות. מסלול ההעלאה דורש רק אותה, ולכן רשימת מי שיכול לצפות היא כאן גם רשימת מי שיכול היה להריץ.
5. ואם הרצתם גרסה מושפעת עם הדגל דלוק, החליפו את פרטי האימות של המאגרים ואת המפתחות שה-repo-server מחזיק. התיאור אומר שקוד שרץ שם יכול לקרוא אותם, ולכן עדכון לבדו אינו מחזיר אותם להיות סוד.