CVE-2025-62164 PoC: באג במישור הנתונים של vLLM Completions שהופך את ההטמעות למשטח תקיפה

תקציר מנהלים

עם התבגרות התשתית של מודל השפה הגדול (LLM), משטח התקיפה עובר מממשקי ניהול מסורתיים ("מישור הבקרה") לזרימת נתוני ההסקת המסקנות בפועל ("מישור הנתונים").

CVE-2025-62164 מייצג פגיעות המשנה את הפרדיגמה ב vLLM, המנוע הסטנדרטי בתעשייה לשירות LLM בעל תפוקה גבוהה. פגם זה מאפשר לתוקפים להפוך את /v1/השלמות נקודת קצה על ידי הזרקת תוכנה זדונית הטמעות מיידית. על ידי ניצול מנגנוני דה-סריאליזציה לא מאובטחים בתוך לוגיקת הטעינה של PyTorch, תוקף יכול לגרום לשחיתות זיכרון, מה שמוביל למניעת שירות (DoS) ולביצוע קוד מרחוק (RCE) פוטנציאלי — והכל ללא צורך במפתחות API תקפים (בהתאם לתצורת הפריסה).

ניתוח זה מפרט את הגורם הטכני הבסיסי, מספק הוכחת היתכנות (PoC) קונספטואלית, ומפרט את הצעדים המיידיים לתיקון עבור מהנדסי פלטפורמות AI.

וקטור התקיפה: מדוע הטמעות הן מסוכנות

באינטראקציות LLM סטנדרטיות, המשתמשים שולחים טקסט. עם זאת, מנועי הסקה מתקדמים כמו vLLM תומכים הטמעת קלטות (נתוני טנסור) ישירות דרך ה-API. זה נועד לייעול ביצועים ולזרימות עבודה רב-מודאליות, אך הוא פותח דלת מסוכנת: ביטול סידור ישיר של אובייקטים.

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

נתיב הקוד הפגיע

הפגם הקריטי קיים בתוך vllm/entrypoints/renderer.py בתוך _טען_ואמת_הטמעה פונקציה.

פייתון

# ייצוג מפושט של הלוגיקה הפגיעה import torch import io import pybase64 def _load_and_validate_embed(embed: bytes): # סכנה: ביטול סידור של זרמי בינארי לא מהימנים tensor = torch.load( io.BytesIO(pybase64.b64decode(embed, validate=True)), weights_only=True, # תחושת הביטחון המוטעית map_location=torch.device("cpu"), ) return tensor

בעוד משקלים בלבד=נכון נועד למנוע ביצוע של קוד Python שרירותי (פגיעות נפוצה ב-Pickle), הוא לא מספיק כדי למנוע פגיעה בזיכרון בעת טיפול בסוגי טנזורים ספציפיים של PyTorch.

ניתוח טכני מעמיק: ניצול טנזורים דלילים

הליבה של CVE-2025-62164 מנצלת את הפער בין דגלי הבטיחות של PyTorch לבין הטיפול שלה ב- טנזורים דלילים.

1. השינוי ב-PyTorch 2.8+: בגרסאות החדשות יותר של PyTorch, ברירת המחדל היא לדלג על בדיקות תקינות יקרות עבור טנזורים דלילים כדי לשפר את הביצועים.
2. המעקף: תוקף יכול לבנות טנזור "Sparse COO" (פורמט קואורדינטות) פגום. אפילו עם משקלים בלבד=נכון, torch.load יפרק את המבנה הזה.
3. פגיעה בזיכרון: מכיוון שמדדי הטנזור הדליל אינם מאומתים מול הגודל המוצהר במהלך הטעינה, פעולות עוקבות (כגון המרת הטנזור לפורמט צפוף או העברתו לזיכרון ה-GPU) גורמות ל- כתיבה מחוץ לגבולות (OOB).

כתיבה OOB זו גורמת לקריסת מתורגמן Python באופן מיידי (DoS). באמצעות ריסוס ערימה מתוחכם ומניפולציה של פריסת הזיכרון, ניתן להגביר את הפרימיטיב הזה כדי להשיג שליטה על מצביע ההוראות, ולהשיג RCE.

ניתוח הוכחת היתכנות (PoC)

הצהרת אחריות: הוכחת היתכנות זו מיועדת למטרות חינוכיות והגנתיות בלבד.

1. בניית המטען

התוקף יוצר טנזור PyTorch סדרתי המפר את אילוצים של עקביות פנימית.

פייתון

import torch import io import base64 def generate_exploit_payload(): buffer = io.BytesIO()
    
    # צור טנזור דליל שנועד להפעיל כתיבה OOB בעת גישה # המדדים הספציפיים יוכנו כך שיצביעו מחוץ לזיכרון שהוקצה # malformed_tensor = torch.sparse_coo_tensor(indices=..., values=..., size=...)
    
    # לצורך הדגמה, אנו מדמים את הסידור הסדרתי # בהתקפה אמיתית, מאגר זה מכיל את זרם ה-pickle הבינארי torch.save(malformed_tensor, buffer) # קידוד להעברת JSON return base64.b64encode(buffer.getvalue()).decode('utf-8')

2. בקשת הניצול

התוקף שולח מטען זה לנקודת הקצה הסטנדרטית להשלמה.

POST http://target-vllm-instance:8000/v1/completions

JSON

{ "model": "meta-llama/Llama-2-7b-hf", "prompt": { "embedding": "" }, "max_tokens": 10 }

3. התוצאה

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

הערכת השפעה

• זמינות (גבוהה): זהו DoS פשוט לביצוע. בקשה אחת יכולה להפיל צומת הסקה. בסביבות מקובצות, תוקף יכול לחזור על הפעולה בכל הצמתים כדי לפגוע בכל הקבוצה.
• סודיות ויושרה (קריטי): אם RCE מושג, התוקף מקבל גישה למשתני הסביבה (הכוללים לעתים קרובות אסימוני Hugging Face, מפתחות S3 או מפתחות WandB) ולמשקלי המודל הקנייניים הטעונים בזיכרון.

תיקון וצמצום נזקים

1. שדרג מיד

הפגיעות תוקנה ב vLLM v0.11.1.

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

2. טיהור קלט (רמת WAF/שער)

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

• פעולה: הגדר את שער ה-API שלך (Nginx, Kong, Traefik) כדי לבדוק גופי JSON נכנסים.
• כלל: חסום כל בקשה ל /v1/השלמות שם מזמין השדה מכיל אובייקט עם הטמעה מפתח.

3. פילוח רשתות

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

סיכום

CVE-2025-62164 משמשת כקריאת השכמה לאבטחת AI. אנחנו כבר לא יכולים להתייחס ל"מודלים" ו"הטמעות" כאל נתונים אינרטיים. בעידן ה-AI, נתונים הם קוד, והפיכתו למצב לא סדרתי דורשת אותה רמת בדיקה כמו ביצוע קובץ בינארי.

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

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