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

● Pemetaan FlawOpen: CWE-345 · CVSS 9.9 · Kritis

Riset Keamanan · FlawOpen

LiteLLM: eskalasi hak akses akibat penggunaan ulang salt key (GHSA-7hp6)

LiteLLM memakai jalur enkripsi yang sama untuk rahasia tersimpan dan token sesi UI/CLI. internal_user yang sudah terautentikasi dapat memasukkan data identitas yang dikendalikannya ke jalur itu untuk memperoleh proxy_admin; peran tersebut dapat menjangkau eksekusi perintah melalui MCP stdio. Perbaikan mengikat token ke prefix khusus dan konteks AES-GCM terautentikasi. Tidak ada CVE atau eksploitasi di dunia nyata yang terkonfirmasi.^{[1], [2]}

💡 Penjelasan Sederhana (ELI5)

Sebuah gedung memakai cap yang sama untuk menyegel amplop penyimpanan dan menerbitkan kartu akses administrator. Pengunjung dapat memengaruhi isi amplop, lalu penjaga mengiranya sebagai kartu asli. Perbaikan LiteLLM memberi kartu sesi tanda khusus dan mengikat tanda itu secara kriptografis ke segelnya.^{[1], [2]}

Konsep Kunci & Istilah

Salt key: Bahan kunci yang dikonfigurasi di LiteLLM dan dipakai helper enkripsi. Masalah ini memakai ulang jalur kunci tanpa mengikat ciphertext pada tujuan penggunaannya.^{[1], [2]}
Authenticated additional data (AAD): Data seperti prefix jenis token yang diautentikasi AES-GCM bersama ciphertext. Jika diubah atau dihilangkan, autentikasi gagal.^[2]
internal_user dan proxy_admin: Peran LiteLLM. Advisory menyebut internal_user terautentikasi dapat naik menjadi proxy_admin, peran administratif.^[1]
MCP stdio: Transport Model Context Protocol yang memulai proses lokal dan bertukar pesan melalui standard input/output. Advisory menyebut proxy_admin dapat mencapai eksekusi perintah melalui endpoint ini.^[1]
CWE-345: Verifikasi keaslian data yang tidak memadai. Ini klasifikasi editorial utama pilihan FlawOpen; advisory juga mencantumkan CWE-269 dan CWE-441.^{[1], [5], [6], [7]}

Pemetaan kerangka kerja

Pemetaan konseptual FlawOpen ke MITRE CWE; tidak ada vendor atau catatan CVE yang menetapkan ID kelemahan ini untuk demonstrasi riset tersebut. CWE-345

Alur Serangan Langkah demi Langkah

Langkah 1

Akun berhak rendah mencapai pengelolaan key

Kondisi awal dalam advisory adalah internal_user terautentikasi. Akses anonim tidak diperlukan, tetapi pelaku harus sudah memiliki peran ini.^[1]

Langkah 2

Metadata menghasilkan ciphertext melalui jalur bersama

Advisory menyebut data identitas terkendali dalam metadata key dapat dienkripsi dan dikembalikan. Cacatnya adalah ciphertext itu kemudian diterima sebagai jenis token lain.^{[1], [2]}

Langkah 3

Parser sesi menerima ciphertext dari tujuan berbeda

Sebelum diperbaiki, enkripsi nilai dan verifikasi sesi berbagi helper serta jalur key tanpa pengikatan tujuan token yang terautentikasi. Identitas dapat ditafsirkan sebagai proxy_admin.^{[1], [2]}

Langkah 4

Akses administratif mencapai MCP stdio

Menurut advisory, proxy_admin dapat menjalankan perintah melalui endpoint MCP stdio. Ini kemampuan proses pada host, bukan perintah yang dijalankan model itu sendiri.^[1]

Langkah 5

Pengikatan tujuan menolak penggunaan ulang

Perbaikan memakai litellm_login_ sebagai AAD AES-GCM dan decoder khusus. Upgrade ke versi yang diperbaiki; menonaktifkan EXPERIMENTAL_UI_LOGIN adalah mitigasi sementara dengan dampak fungsi.^{[1], [2], [3], [4]}

Analisis Akar Masalah (Root Cause)

Advisory BerriAI GHSA-7hp6-4w63-5g45 menjelaskan kegagalan pemisahan tujuan autentikasi. LiteLLM memakai helper enkripsi nilai yang sama untuk rahasia tersimpan dan token sesi UI/CLI; autentikasi sesi juga mendekripsi nilai melalui jalur kunci yang sama. internal_user terautentikasi dapat meminta API key dengan data identitas terserialisasi yang dikendalikannya di metadata; jalur pengelolaan mengenkripsi dan mengembalikan nilai itu. Saat ciphertext diberikan sebagai bearer token, jalur sesi dapat mendekripsinya dan menafsirkannya sebagai identitas proxy_admin palsu. Peran itu dapat menjangkau eksekusi perintah MCP stdio. Perbaikan upstream f7cd90f mengubah penerbitan dan verifikasi token dengan prefix litellm_login_, AAD AES-GCM yang terikat pada prefix tersebut, dan decoder khusus. Salt key tetap menjadi bahan kunci; batas yang diverifikasi adalah tujuan token yang terautentikasi dan decoder pasangannya. Karena itu ciphertext untuk nilai tersimpan tidak lolos sebagai token sesi. Advisory memberi nilai CVSS 3.1 9.9 Critical; versi setelah 1.91.0 terdampak secara default, sedangkan 1.87.0–1.90.x hanya jika EXPERIMENTAL_UI_LOGIN=true. Versi perbaikan yang tercantum untuk tiap cabang ialah 1.100.4, 1.101.3, 1.102.2, 1.103.1, dan 1.104.0rc2. Mitigasi sementara EXPERIMENTAL_UI_LOGIN=false menonaktifkan jalur login rentan, tetapi juga memutus CLI SSO dan login Claude Code gateway. Advisory tidak menyebut CVE dan tidak mengonfirmasi eksploitasi di dunia nyata. Pasangan kode menunjukkan perubahan batas autentikasi upstream, bukan exploit atau implementasi autentikasi lengkap.^{[1], [2], [3], [4]}

Kode Sumber: Rentan vs Aman

Perbaikan upstream mengganti helper nilai generik saat token sesi dibuat dan diautentikasi. encrypt_bearer_token mengautentikasi prefix sebagai AAD AES-GCM; decrypt_bearer_token mewajibkan prefix dan AAD yang sama. Jadi ciphertext penyimpanan tidak dapat digunakan sebagai token login. Ini cuplikan ringkas dari commit yang dirujuk, bukan implementasi autentikasi mandiri. Kunci salt bersama tidak dengan sendirinya membuktikan adanya kunci khusus untuk setiap tujuan; pemisahan yang terverifikasi di sini berasal dari tipe token yang diautentikasi dan decoder yang sesuai.^{[2], [3]}

Cuplikan sumber: litellm/proxy/auth/auth_checks.py dan litellm/proxy/common_utils/encrypt_decrypt_utils.py — cuplikan ringkas dari upstream commit f7cd90f

IMPLEMENTASI RENTAN

# Sebelum patch: ciphertext nilai tersimpan juga diterbitkan sebagai token sesi.
return encrypt_value_helper(valid_token.model_dump_json(exclude_none=True))

# Autentikasi sesi mendekripsinya melalui helper nilai generik.
decrypted_token = decrypt_value_helper(hashed_token, key="ui_hash_key")

PERBAIKAN AMAN & KUAT

# Setelah patch: token sesi memiliki tipe dan AAD khusus.
LITELLM_SESSION_TOKEN_PREFIX = "litellm_login_"
return encrypt_bearer_token(
    valid_token.model_dump_json(exclude_none=True),
    prefix=LITELLM_SESSION_TOKEN_PREFIX,
)

# Autentikasi menggunakan decoder yang sesuai dengan tujuannya.
decrypted_token = decrypt_bearer_token(
    hashed_token, prefix=LITELLM_SESSION_TOKEN_PREFIX
)

Daftar Periksa Penguatan Sistem Rekayasa

✓Perbarui tiap deployment LiteLLM ke versi perbaikan pada cabangnya dan pastikan package/image yang benar-benar terpasang, bukan hanya tag yang dapat berubah.^{[1], [3], [4]}
✓Untuk 1.87.0–1.90.x, periksa apakah EXPERIMENTAL_UI_LOGIN diaktifkan; advisory menyebut hanya konfigurasi itu yang terdampak.^[1]
✓Jika belum dapat segera upgrade, sementara set EXPERIMENTAL_UI_LOGIN=false dan rencanakan dampak pada CLI SSO serta login Claude Code gateway.^[1]
✓Tambahkan regression test yang memastikan decoder sesi menolak ciphertext nilai tersimpan, tetapi tetap menerima token sesi valid yang belum kedaluwarsa.^[2]
✓Ikat ciphertext pada tujuannya: autentikasi prefix sebagai AAD AES-GCM saat penerbitan dan verifikasi; jangan menerima hasil decrypt generik sebagai token identitas.^[2]
✓Batasi pengelolaan key dan konfigurasi MCP stdio pada role yang membutuhkan; jalankan proxy dengan hak OS minimum.^[1]
✓Analisis FlawOpen: Instrumentasikan audit autentikasi deployment untuk mencatat principal, peran hasil resolusi, jenis token, waktu, dan ID permintaan tanpa menyimpan bearer token atau ciphertext; uji skema peristiwanya. Tambahkan uji peringatan saat proses proxy LiteLLM memulai proses anak MCP stdio, lalu korelasikan peristiwa autentikasi dan proses saat investigasi. Ini rekomendasi deteksi di sisi deployment, bukan sinyal log yang dikonfirmasi vendor.
✓Catat GHSA-7hp6-4w63-5g45: advisory tidak mencantumkan CVE dan sumber yang ditinjau tidak mengonfirmasi eksploitasi nyata.^[1]

Sumber

← AI Security Directory →