Kerentanan carriage return dan RCE clone pada Git

 (dgl.cx)
1 poin oleh GN⁺ 2025-07-09 | Belum ada komentar. | Bagikan ke WhatsApp
  • Di sistem mirip Unix, mereplikasi repositori yang tidak tepercaya dengan git clone --recursive dapat memungkinkan eksekusi kode jarak jauh melalui CVE-2025-48384, sehingga Git dan perangkat lunak yang menyertakan Git perlu diperbarui
  • Penyebabnya adalah perbedaan cara menangani carriage return (\r) saat membaca dan menulis ulang konfigurasi Git, sehingga nilai yang divalidasi dan nilai yang benar-benar digunakan menjadi tidak selaras
  • Jika \r ditambahkan di akhir path submodule pada .gitmodules, jalur checkout dapat berubah menjadi jalur lain setelah validasi
  • Windows tidak rentan secara langsung karena tidak mengizinkan karakter kontrol pada nama file, tetapi macOS rentan terhadap CVE-2024-32002 maupun CVE-2025-48384
  • Patch mengubah nilai konfigurasi yang berisi \r agar diapit tanda kutip, sehingga menutup jalur serangan seperti penulisan file di dalam .git dan pembuatan hook Git

Ringkasan kerentanan dan tindakan segera

  • CVE-2025-48384 adalah kerentanan Git yang pada platform mirip Unix dapat berujung pada eksekusi kode jarak jauh ketika mereplikasi repositori yang tidak tepercaya dengan git clone --recursive
  • Perbarui ke versi Git yang telah diperbaiki, dan perbarui juga perangkat lunak yang menyertakan Git, termasuk GitHub Desktop
  • Jika hanya menjalankan git clone dari command line, submodule tidak otomatis direplikasi
    • Sebagai mitigasi, Anda dapat menjalankan git clone terlebih dahulu tanpa --recursive, memeriksa apakah .gitmodules aman, lalu menginisialisasi submodule
  • GitHub Desktop secara default melakukan clone dengan opsi rekursif, sehingga perilaku tersebut dapat terdampak

Carriage return dan file konfigurasi Git

  • Carriage return adalah Carriage Return, karakter ASCII nomor 13, dan dalam string C direpresentasikan sebagai \r
  • Unix dimaksudkan hanya memakai LF, yaitu \n, sebagai pemisah baris, tetapi Windows dan banyak protokol internet menggunakan CR+LF, yaitu \r\n
  • Format konfigurasi bergaya .ini milik Git digunakan bukan hanya untuk file konfigurasi pengguna, tetapi juga untuk file .gitmodules yang disertakan dalam repositori
  • Parser konfigurasi Git, untuk mendukung akhir baris DOS, berperilaku seperti berikut saat membaca karakter
    • Jika karakter saat ini adalah \r, parser memeriksa karakter berikutnya
    • Jika karakter berikutnya adalah \n, \r dibuang dan diperlakukan sebagai baris baru
    • Jika karakter berikutnya bukan \n, karakter berikutnya dikembalikan, dan \r itu sendiri dikembalikan
  • Pemrosesan ini diterapkan per baris, sehingga jika suatu baris berakhir dengan CR, CR tersebut dapat dihapus terlepas dari format keseluruhan file

Ketidaksesuaian antara pembacaan dan penulisan

  • Git tidak hanya membaca file konfigurasi, tetapi juga mencatat pasangan key = value dalam format yang sama saat menulis nilai konfigurasi, seperti pada git config
  • Kode lama hanya mengapit nilai dengan tanda kutip ganda saat menulis ulang nilai konfigurasi dalam kasus berikut
    • Nilai diawali spasi
    • Nilai mengandung ; atau #
    • Nilai diakhiri spasi
  • Sebaliknya, kode pembaca konfigurasi mendukung string bertanda kutip ganda, sehingga saat nilai yang ditulis oleh write_pair dibaca kembali kemudian, \r terakhir dapat terlepas
  • Misalnya, jika file konfigurasi berisi key = "foo^M", setelah ditulis ulang bentuknya dapat menjadi key = foo^M
    • Di sini ^M adalah karakter CR literal
  • Jika perilaku ini digabungkan dengan nilai .gitmodules yang tidak tepercaya, pemrosesan jalur submodule menjadi terganggu

Kekacauan jalur submodule dan cakupan dampak

  • Pada sistem berbasis Unix, karakter kontrol dapat dimasukkan ke nama file, sehingga nilai yang mengandung CR dapat dimasukkan ke path dalam .gitmodules
  • Contohnya berbentuk seperti berikut
[submodule "foo"]
  path = "foo^M"
  • Jika nilai ini dicatat ke .git/modules/foo/config oleh kode konfigurasi Git, bentuknya dapat menjadi seperti berikut
[core]
  workdir = ../../../foo^M
  • Validasi atas jalur tidak tepercaya yang dibaca dari .gitmodules sudah selesai pada tahap ini
  • Setelah itu, saat konfigurasi dibaca ulang dan \r terakhir dihapus, Git akan menggunakan jalur yang berbeda dari jalur yang telah divalidasi
  • Akibatnya, selama clone submodule, lokasi yang dibaca dari path = ... dan lokasi yang benar-benar ditulis serta digunakan dapat berbeda
  • Prinsip ini mirip dengan CVE-2024-32002
    • CVE-2024-32002 membingungkan Git dengan memanfaatkan apakah submodule peka huruf besar-kecil atau tidak
    • CVE-2025-48384 membutuhkan sistem file yang mengizinkan karakter kontrol dalam nama file
  • Windows tidak mengizinkan karakter kontrol dalam nama file, sehingga tidak rentan secara langsung terhadap bug spesifik ini
  • macOS rentan terhadap CVE-2024-32002 maupun CVE-2025-48384

Patch dan kemungkinan serangan

  • Patch mengubah write_pair agar mengapit string dengan tanda kutip jika nilai mengandung \r
  • Perubahannya sederhana, yaitu menambahkan '\r' ke kondisi yang sebelumnya hanya memeriksa ; atau #
 	for (i = 0; value[i]; i++)
-		if (value[i] == ';' || value[i] == '#')
+		if (value[i] == ';' || value[i] == '#' || value[i] == '\r')
 			quote = "\"";
  • Dengan kekacauan jalur, file berbahaya dari submodule dapat ditempatkan di lokasi yang hampir arbitrer pada sistem file, dan karena validasi telah dilewati, symbolic link di luar repositori juga dapat diikuti
  • Cara eksploitasi paling langsung adalah menulis file di dalam direktori .git dan membuat script hook Git, sehingga kode yang dikendalikan penyerang dijalankan saat Git menjalankan hook
  • Kemungkinan lain adalah menimpa .git/config
  • PoC belum dipublikasikan, tetapi disebutkan bahwa exploit CVE-2024-32002 hanya perlu dimodifikasi nyaris sepele
  • Pengujian pada commit perbaikan dapat memberi petunjuk besar tentang metode serangannya

Masalah CR yang berulang dan pelajarannya

  • Ini bukan pertama kalinya carriage return menimbulkan masalah pada Git
  • Pada Januari, RyotaK menemukan masalah protokol credential helper yang dapat ditipu dengan carriage return
  • Pada 2023, André Baptista dan Vítor Pinho menemukan CVE-2023-29007, yaitu kesalahan logika dalam parsing konfigurasi
  • Kerentanan ini bukan masalah bahasa C itu sendiri, melainkan lebih dekat ke kesalahan logika yang dapat terjadi di hampir semua bahasa
  • Kesamaannya adalah masalah terjadi dalam komunikasi antarproses di antara komponen internal Git, atau antara Git dan proses eksternal
  • Struktur serupa juga terlihat pada CRLF injection, request smuggling, dan SMTP smuggling di HTTP
  • Internet masa lalu bergantung pada prinsip ketangguhan Postel, “bersikap konservatif saat mengirim, dan toleran saat menerima”, tetapi kini itu mungkin bukan saran yang paling masuk akal
  • Topik ini dibahas lebih rinci dalam RFC 9413

Ucapan terima kasih dan perbaikan terkait

Bacaan terkait

Belum ada komentar.

Belum ada komentar.