FlawOpen

flawopen.com/AI Security/berriai-litellm-ghsa-7hp6-salt-key-session-token-privilege-escalation

● FlawOpen मैपिंग: CWE-345 · CVSS 9.9 · अति गंभीर
सुरक्षा अनुसंधान · FlawOpen

LiteLLM: salt key के पुनः उपयोग से विशेषाधिकार वृद्धि (GHSA-7hp6)

LiteLLM, संग्रहीत secrets और UI/CLI session tokens के लिए एक ही encryption path का उपयोग करता था। प्रमाणित internal_user अपने नियंत्रण वाले identity data को इस path से गुजारकर proxy_admin तक पहुंच सकता था; इस role से MCP stdio के जरिए command execution उपलब्ध था। सुधार अलग prefix और authenticated AES-GCM context से token के उद्देश्य को बांधता है। कोई CVE या वास्तविक हमलों में पुष्टि की गई exploitation रिपोर्ट नहीं है।[1], [2]

💡 आसान भाषा में (ELI5)

एक इमारत storage envelope को बंद करने और administrator badge जारी करने के लिए एक ही मुहर इस्तेमाल करती है। आगंतुक envelope की सामग्री प्रभावित कर सकता है, और guard बाद में उसे असली badge समझ लेता है। LiteLLM का सुधार session badge को अलग पहचान देता है और उस पहचान को cryptographically मुहर से जोड़ता है।[1], [2]

इस पेज के मुख्य शब्द

Salt key
LiteLLM में सेट किया गया key material, जिसका encryption helpers उपयोग करते हैं। इस दोष में अलग उद्देश्यों के लिए यही path इस्तेमाल हुआ, पर ciphertext को उसके उद्देश्य से नहीं बांधा गया।[1], [2]
Authenticated Additional Data (AAD)
Token prefix जैसे data, जिसे AES-GCM ciphertext के साथ authenticate करता है। इसे बदलने या छोड़ने पर authentication विफल होता है।[2]
internal_user और proxy_admin
LiteLLM roles। Advisory के अनुसार प्रमाणित internal_user, administrative proxy_admin role तक बढ़ सकता था।[1]
MCP stdio
Model Context Protocol transport जो local process शुरू करता है और standard input/output से संदेश भेजता है। Advisory के अनुसार proxy_admin इस endpoint से commands चला सकता था।[1]
CWE-345
Data authenticity का अपर्याप्त सत्यापन। यह FlawOpen की चुनी हुई मुख्य संपादकीय श्रेणी है; advisory CWE-269 और CWE-441 भी सूचीबद्ध करती है।[1], [5], [6], [7]

फ्रेमवर्क मैपिंग

  • MITRE CWE के लिए FlawOpen की वैचारिक मैपिंग; किसी विक्रेता या CVE रिकॉर्ड ने इस शोध प्रदर्शन को यह कमजोरी ID नहीं दी है। CWE-345

हमले का चरण-दर-चरण प्रवाह

चरण 1

कम विशेषाधिकार वाला खाता key management तक पहुंचता है

Advisory की शुरुआती शर्त प्रमाणित internal_user है। Anonymous access जरूरी नहीं, लेकिन actor के पास यह role पहले से होना चाहिए।[1]

चरण 2

Metadata साझा path से ciphertext बनाती है

Advisory कहती है कि key metadata में नियंत्रित identity data encrypt होकर लौट सकता था। दोष यह था कि बाद में वही ciphertext दूसरे प्रकार के token के रूप में स्वीकार हुआ।[1], [2]

चरण 3

Session parser दूसरे उद्देश्य का ciphertext स्वीकारता है

Fix से पहले value encryption और session verification एक helper और key path साझा करते थे, बिना token purpose को authenticate किए। Identity को proxy_admin माना जा सकता था।[1], [2]

चरण 4

Administrative access MCP stdio तक पहुंचता है

Advisory के अनुसार proxy_admin MCP stdio endpoint से commands चला सकता था। यह host पर process capability है, model द्वारा स्वयं command चलाना नहीं।[1]

चरण 5

Purpose binding पुनः उपयोग अस्वीकार करती है

Fix litellm_login_ को AES-GCM AAD और dedicated decoder के रूप में उपयोग करता है। Fixed release पर upgrade करें; EXPERIMENTAL_UI_LOGIN बंद करना प्रभाव वाला अस्थायी उपाय है।[1], [2], [3], [4]

मूल कारण विश्लेषण (Root Cause)

BerriAI की GHSA-7hp6-4w63-5g45 advisory दो अलग उद्देश्यों के authentication को मिलाने की समस्या बताती है। LiteLLM stored secrets और UI/CLI session tokens दोनों के लिए generic value-encryption helper उपयोग करता था; session authentication भी उसी key path से values decrypt करती थी। प्रमाणित internal_user अपने नियंत्रण वाले serialized identity data को key metadata में रखकर API key मांग सकता था; management path उस value को encrypt करके लौटाता था। यदि ciphertext bearer token के रूप में दिया जाता, session path उसे decrypt कर forged proxy_admin identity के रूप में समझ सकता था। इससे MCP stdio command execution तक पहुंच संभव थी। Upstream fix f7cd90f token minting और verification बदलता है: litellm_login_ prefix, उससे जुड़ा AES-GCM AAD, और dedicated decoder। Salt key अभी भी key material है; सत्यापित सुरक्षा सीमा token का authenticated purpose और matching decoder है। इसलिए stored-value ciphertext session token के रूप में validate नहीं होता। Advisory CVSS 3.1 9.9 Critical बताती है; 1.91.0 के बाद के versions default रूप से प्रभावित हैं और 1.87.0–1.90.x केवल EXPERIMENTAL_UI_LOGIN=true होने पर। शाखाओं के लिए सूचीबद्ध fixed versions 1.100.4, 1.101.3, 1.102.2, 1.103.1 और 1.104.0rc2 हैं। अस्थायी उपाय EXPERIMENTAL_UI_LOGIN=false vulnerable login path बंद करता है, पर CLI SSO और Claude Code gateway login भी तोड़ता है। Advisory कोई CVE नहीं देती और वास्तविक exploitation की पुष्टि नहीं करती। Code pair upstream authentication boundary का बदलाव दिखाता है; यह exploit या पूर्ण authentication implementation नहीं है।[1], [2], [3], [4]

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

Upstream fix session token बनाते और authenticate करते समय generic value helpers को बदलता है। encrypt_bearer_token prefix को AES-GCM AAD के रूप में authenticate करता है; decrypt_bearer_token वही prefix और AAD मांगता है। इसलिए storage ciphertext को login token की तरह उपयोग नहीं किया जा सकता। यह cited commit का छोटा excerpt है, standalone authentication code नहीं। साझा salt key अपने-आप यह साबित नहीं करती कि हर उद्देश्य के लिए अलग key है; यहाँ प्रमाणित अलगाव authenticated token type और उससे मेल खाने वाले decoder से आता है।[2], [3]

सोर्स अंश: litellm/proxy/auth/auth_checks.py और litellm/proxy/common_utils/encrypt_decrypt_utils.py — upstream commit f7cd90f के संक्षिप्त अंश

कमज़ोर कार्यान्वयन
# fix से पहले: stored value का ciphertext session token के रूप में भी जारी होता था।
return encrypt_value_helper(valid_token.model_dump_json(exclude_none=True))

# session authentication generic value helper से decrypt करता था।
decrypted_token = decrypt_value_helper(hashed_token, key="ui_hash_key")
सुरक्षित और सुदृढ़ फ़िक्स
# fix के बाद: session tokens का अपना type और AAD है।
LITELLM_SESSION_TOKEN_PREFIX = "litellm_login_"
return encrypt_bearer_token(
    valid_token.model_dump_json(exclude_none=True),
    prefix=LITELLM_SESSION_TOKEN_PREFIX,
)

# authentication उसी उद्देश्य के अनुरूप decoder इस्तेमाल करता है।
decrypted_token = decrypt_bearer_token(
    hashed_token, prefix=LITELLM_SESSION_TOKEN_PREFIX
)

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

स्रोत

← AI Security Directory →