Kerentanan Git pada carriage return dan RCE saat clone

 (dgl.cx)
1 poin oleh GN⁺ 2025-07-09 | 1 komentar | Bagikan ke WhatsApp
  • Memperkenalkan teknik serangan yang memanfaatkan karakter carriage return di dalam repositori Git
  • Kerentanan ini menimbulkan kemungkinan eksekusi kode jarak jauh (RCE)
  • Perintah berbahaya dapat dijalankan selama proses git clone tertentu
  • Dampaknya telah dikonfirmasi pada lingkungan Linux dan Windows
  • Menyoroti risiko pengelolaan repositori Git yang rentan terhadap keamanan

Karakter carriage return dan kerentanan Git

  • Di dalam repositori Git, dimungkinkan untuk membuat nama file yang mengandung karakter carriage return (\r)
  • Jika repositori yang berisi nama file seperti ini disalin dengan git clone, maka pada proses penafsiran perintah dapat terjadi eksekusi perintah yang tidak diinginkan

Skenario eksekusi kode jarak jauh (RCE)

  • Penyerang menambahkan file yang disisipi karakter carriage return lalu meng-commit-nya ke repositori
  • Ketika pengguna melakukan git clone pada repositori ini, kesalahan penafsiran oleh sistem file dan perintah Git dapat memicu risiko eksekusi kode yang tidak diinginkan
  • Secara khusus, penyerang dapat mendorong agar skrip hook (misalnya kode di folder .git/hooks) dijalankan secara otomatis

Lingkungan terdampak dan mitigasi

  • Dapat terjadi pada Git di berbagai sistem operasi seperti Linux dan Windows
  • Ini merupakan ancaman keamanan serius bagi pengembang dan perusahaan yang mengelola repositori Git atau sering melakukan clone repositori eksternal

Rekomendasi keamanan

  • Saat melakukan clone repositori Git eksternal yang tidak tepercaya, perlu menggunakan versi terbaru dan memeriksa status keamanannya
  • Perlu mendeteksi nama file dengan karakter tidak lazim di dalam repositori, terutama yang mengandung carriage return, lalu meninjaunya sebelum melakukan clone

Bacaan terkait

1 komentar

 
GN⁺ 2025-07-09
Komentar Hacker News

  • Semua ini menghasilkan situasi saat melakukan clone submodule: pembacaan dilakukan dalam bentuk path = ..., tetapi saat menulis justru tercatat ke path lain yang tidak diakhiri ^M

    • Muncul pertanyaan bagaimana tepatnya "remote code execution" yang disebut di artikel bisa terjadi di sini, dan seberapa serius dampaknya dari sisi keamanan

    • PoC memang belum dirilis, tetapi disebut bahwa isinya hampir merupakan modifikasi langsung dari exploit CVE-2024-32002, dan tes pada commit perbaikannya juga memberi petunjuk besar

    • Mengutip penjelasan CVE-2024-32002: dengan memanipulasi repository yang berisi submodule secara jahat dan memanfaatkan bug Git, penyerang dapat menulis file ke direktori .git/ alih-alih ke worktree submodule. Karena itu, hook yang langsung dijalankan selama proses clone bisa ditulis, sehingga pengguna bahkan tidak sempat memeriksa kode yang benar-benar akan dieksekusi

    • Ringkasnya, hook git berbahaya bisa disisipkan ke repository; biasanya hook git tidak terpasang saat git clone, tetapi serangan kali ini memungkinkan hal itu sehingga hook bisa berjalan selama proses clone

    • Informasi lebih lanjut tentang CVE baru ini bisa dilihat di sini

      • Saat membaca nilai konfigurasi, Git menghapus karakter CR dan LF, tetapi saat menulis tidak melakukan quoting untuk CR sehingga nilainya hilang ketika dibaca kembali
      • Jika akhir path submodule mengandung karakter CR, path yang sudah terhapus itu akan dipakai sehingga submodule bisa di-checkout ke lokasi yang salah
      • Jika sudah ada symlink antara path yang terhapus tersebut dan direktori hook submodule, penyerang bisa mengeksekusi kode arbitrer melalui hook post-checkout
      • Selain CVE ini, masih banyak kerentanan Git lain yang juga layak dilihat bersama

    • Disebutkan kebenaran sederhana namun tidak nyaman bahwa jika penulisan file arbitrer dimungkinkan, biasanya itu bisa berkembang menjadi RCE

  • Disebutkan bahaya menulis file konfigurasi dengan DSL ad-hoc

    • Sering kali tidak ada spesifikasi formal untuk sintaksnya, dan standar sebenarnya untuk parsing tersebar di implementasi serialisasi/deserialisasi buatan sendiri

    • Jika keduanya tidak sinkron—misalnya parser sudah mendukung sintaks baru tetapi writer belum—perbedaan parser bisa menjadi bom waktu

    • Pelajarannya: perlu ada satu source of truth, lalu bagian yang bergantung padanya sebaiknya dihasilkan otomatis berdasarkan itu

    • Ditunjukkan bahwa bug ini terpisah dari masalah source of truth

      • Ini murni kesalahan logika; jika Unix punya library sistem standar seperti itu, masalah yang sama bisa muncul di sana juga
      • Kalau bug ini ada di library standar semacam itu, dampaknya akan jauh lebih serius; sekarang kerusakannya relatif terbatas karena terutama mengenai para developer

    • DSL yang dipakai di sini (format file ini) memang ad-hoc, tetapi sangat umum, familier, dan cukup rapi sehingga secara praktis biasanya sudah memadai sebagai spesifikasi

      • Hakikat bug ini bukan pada formatnya, melainkan pada parser (atau lexer) buatan tangan yang disisipkan di tengah, dan menurut pendapat ini praktik seperti itu seharusnya dihentikan
      • Memang masih ada sedikit tempat yang memerlukan hand-coding cerdas seperti itu, tetapi sama sekali tidak cocok untuk format pertukaran data; kalau butuh ini, pakai TOML, kalau tidak cocok pakai JSON, bahkan YAML pun oke, kalau benar-benar mencari penderitaan pakai XML, dan kalau bersikeras butuh format biner maka gunakan protobufs
      • Kesimpulannya, kecuali Anda penulis bahasa pemrograman, jangan menulis parser sendiri; wajib manfaatkan library

  • Setelah mereproduksi masalahnya sendiri, seseorang mengunggahnya ke repository ini

    • Langsung mencoba memperbarui ke Git versi terbaru, tetapi di Arch pembaruannya belum tersedia

    • Sampai patch baru keluar, ia berencana menahan diri untuk tidak melakukan pull; ada kekhawatiran repository populer dengan auto-pull bisa bermasalah sehingga upgrade akan memakan waktu lama

    • Muncul pertanyaan apakah kerentanan ini dipublikasikan sebelum patch tersedia

      • Dulu kebanyakan tulisan yang menjelaskan seberapa jauh sebuah kerentanan bisa dieksploitasi muncul beberapa bulan setelah patch terbit; sekarang ada harapan agar setiap posting dengan jelas dan singkat membedakan antara "ini benar-benar berbahaya saat ini" dan "ini sudah ditambal jadi aman"

  • Melihat pernyataan bahwa exploit lama "hanya dimodifikasi sedikit", muncul pertanyaan mengapa Git tidak memakai Landlock (fitur keamanan sandbox khusus Linux)

    • Untuk operasi git clone, diusulkan model yang hanya memberi akses baca ke direktori config, akses baca/tulis ke direktori target clone, dan melarang pemanggilan subprocess

    • Ada sindiran tentang betapa setiap exploit selalu menampilkan kalkulator

    • Namun jika pemanggilan subprocess dilarang, semua hook git seperti post-checkout juga akan rusak

      • Jika itu tidak diperlukan, Git bisa dijalankan di lingkungan container seperti seccomp, tetapi banyak fiturnya akan terbatasi

    • Selain itu, tanpa subprocess, penggunaan git lewat SSH juga tidak akan bisa

  • Ditanyakan apakah Homebrew sendiri terdampak masalah ini, yakni apakah ia melakukan recursive clone

    • Kemungkinan itu ditemukan pada kode ini

    • Ada pendapat bahwa tujuan Homebrew sendiri memang menjalankan kode dari repository, jadi justru aneh jika tidak melakukan recursive clone

      • RCE hanya benar-benar bermakna ketika data hasil clone seharusnya tidak dieksekusi, dan kasus seperti itu disebut jarang

  • Melihat kutipan terkenal Jon Postel soal CR+LF memunculkan nostalgia

    • Dibagikan tautan ke tulisan ini, beserta penilaian bahwa dibanding 2003, nasihat itu mungkin tidak lagi tepat sekarang
    • Dijelaskan, seperti yang pernah diterangkan Mark Crispin saat itu, bahwa orang-orang salah paham; ini juga dikaitkan dengan contoh dari akhir 1990-an ketika Daniel J. Bernstein menunjukkan masalah yang muncul dalam proses konversi manusia-mesin (parsing/quoting)
    • Diamati bahwa bahkan setelah 25 tahun, masalah pada kode quoter yang tidak melakukan escape untuk CR masih terus berulang, dan bahkan setelah diperbaiki pun belum semua whitespace diperiksa
    • Hasil git blame menunjukkan bahwa kode bermasalah itu ditulis 19 tahun lalu, bertepatan dengan refleksi 10 tahun Bernstein
    • Dibagikan juga commit terkait, makalah qmail, dan materi tambahan lainnya
    • Intinya, kenyataan pahitnya adalah pelajaran yang susah payah dipelajari pada abad ke-20 harus terus dipelajari lagi di abad ke-21

  • Sepertinya masih harus menunggu karena pembaruan Git 2.50.1 belum tersedia di Homebrew

    • Disarankan mencoba memperbarui lewat issue ini atau brew install git --HEAD

  • Dibagikan fakta bahwa Homebrew dan Debian Bookworm sama-sama masih menyediakan versi yang rentan

    • Diberi kabar bahwa sekarang Homebrew juga sudah menyediakan versi 2.50.1

  • Muncul pemikiran apakah system call yang memuat daftar direktori seharusnya menolak keberadaan file jika nama filenya mengandung karakter kontrol ASCII (bytes), menganggapnya sebagai kerusakan disk, atau menanganinya dengan cara lain

    • Disebutkan bahwa dalam locale saat ini byte-byte itu bisa saja punya makna lain; tidak seperti Windows yang mengasumsikan semua nama file sebagai UTF-16, jadi situasi tak terduga bisa muncul

    • Ditunjukkan secara singkat bahwa pada sistem keluarga Unix, nama file (dan string lainnya) pada dasarnya hanyalah array byte, dan dari situlah masalah ini muncul