Backdoor xz yang Terdeteksi oleh NixOS dan Build yang Dapat Direproduksi

• Pada Maret 2024, sebuah backdoor ditemukan pada perangkat lunak xz yang digunakan untuk mengekstrak source tarball di distribusi Linux.
• Backdoor ini disisipkan secara diam-diam selama 3 tahun oleh maintainer jahat Jia Tan.
• Insiden ini berdampak besar karena memungkinkan eksekusi kode jarak jauh dan sangat sulit dideteksi.
• Backdoor ini ditemukan secara kebetulan oleh Andres Freund, pengembang Postgres di Microsoft, saat menyelidiki penurunan performa, sehingga bencana besar berhasil dihindari.

Cara kerja serangan

• Backdoor membajak program ssh untuk memungkinkan eksekusi kode jarak jauh.
• Dengan memodifikasi fungsi RSA_public_decrypt, penyerang dapat menjalankan perintah sewenang-wenang saat login menggunakan kunci RSA tertentu.
• Serangan ini terdiri dari dua komponen utama:
  1. Skrip yang memasang file objek berbahaya sebagai bagian dari proses build xz.
  2. Prosedur yang melakukan hook pada fungsi RSA_public_decrypt.

1. Skrip pemasangan file objek berbahaya

• File objek berbahaya disembunyikan di dalam file pengujian pada repositori git xz.
• Backdoor hanya aktif pada release tarball yang disediakan oleh maintainer.

2. Prosedur hook fungsi RSA_public_decrypt

• Menggunakan fitur ifunc milik glibc untuk memaksa eksekusi kode yang berjalan saat waktu dynamic loading.
• Saat ssh dijalankan, libsystemd dan liblzma dimuat, dan dalam proses ini backdoor mengeksekusi kode sewenang-wenang.

Cara menghindari bencana xz

• Untuk meningkatkan keandalan perangkat lunak open source, kita harus menangani baik masalah sosial maupun masalah teknis.
• Proses keamanan rantai pasok perangkat lunak harus diperbaiki.

Membangun perangkat lunak dari sumber tepercaya

• Serangan ini efektif karena banyak distribusi membangun xz menggunakan tarball yang disediakan maintainer.
• Jika memungkinkan, perangkat lunak harus dibangun dari sumber yang paling tepercaya.

Saat situasi memungkinkan...

• NixOS adalah distribusi berbasis model manajemen paket fungsional, dan setiap paket direpresentasikan dalam bahasa pemrograman fungsional bernama Nix.
• NixOS memiliki budaya menggunakan source archive yang dibuat otomatis dari GitHub.

Membangun kepercayaan pada release tarball yang tidak tepercaya

• NixOS tetap harus menggunakan tarball yang disediakan maintainer pada tahap bootstrap.
• Untuk memperkuat keamanan rantai pasok perangkat lunak, langkah-langkah perlindungan tertentu perlu disiapkan.

1. Membandingkan sumber

• Penting untuk memeriksa apakah source tarball yang digunakan distribusi sama dengan yang ada di GitHub.
• Namun, release tarball sering kali berbeda dari source, dan itu bukan masalah.

2. Memanfaatkan reproduksibilitas bit-per-bit

• Build yang dapat direproduksi adalah sifat proyek perangkat lunak yang menghasilkan artefak yang sama saat dibangun dua kali dalam kondisi yang sama.
• Reproduksibilitas bit-per-bit dapat digunakan untuk membangun kepercayaan terhadap tarball dari maintainer yang tidak tepercaya.

Kesimpulan

• Insiden backdoor xz menjadi pengingat pentingnya keamanan rantai pasok perangkat lunak open source.
• Sistem seperti NixOS dapat memperkuat keamanan melalui build yang dapat direproduksi.

[GN⁺]

Komentar Hacker News

• NixOS dan build yang dapat direproduksi tidak berhasil mendeteksi backdoor xz. NixOS memang mendistribusikan build xz berbahaya, tetapi karena itu tidak menargetkan NixOS, tidak ada masalah

  • Pengembang NixOS terkejut ketika backdoor itu terungkap dan mereka mengetahui bahwa versi xz berbahaya telah didistribusikan kepada pengguna
  • Teori dan realitas itu berbeda, dan alasan xz bisa terjadi adalah masalah 'dunia nyata', bukan kelemahan teknis. Sulit untuk menerima bahwa dunia nyata tidak bisa ditambal dengan perangkat lunak

• Penulis tampaknya terlalu fokus pada insiden ini saja. Kasus Jiatan adalah satu contoh tunggal, dan dalam skenario lain pertahanan juga bisa gagal

  • Sebagai pengguna NixOS, saya pikir sangat mungkin NixOS memang tidak akan menangkap ini. Tanpa bukti, mempercayai NixOS adalah tindakan yang bodoh

• NixOS tidak relevan karena backdoor xz menargetkan RedHat dan Debian. Ironisnya, backdoor itu ditemukan oleh seorang karyawan Microsoft

• Artikel itu menyebut bahwa distro seharusnya mengambil source code langsung dari VCS (misalnya Github), bukan dari tarball instalasi tradisional

  • Namun, maintainer yang berniat jahat bisa langsung menambahkan binary blob ke repositori source code
  • Penulis terkesan menyarankan bahwa Github cukup tepercaya seolah-olah memverifikasi kode, padahal Github sebenarnya tidak memverifikasi kode

• Jika ingin fokus pada insiden yang seharusnya bisa dicegah oleh NixOS, seharusnya fokus pada insiden CrowdStrike. Jika bisa boot dengan konfigurasi kemarin, sebagian besar masalah bisa diredam

• NixOS mengompilasi semuanya dari source, memverifikasi secara kriptografis bahwa source yang digunakan tidak diutak-atik, dan memiliki ketergantungan versi antar paket. Debian juga punya build yang dapat direproduksi

  • Masalahnya adalah sistem build tidak menghapus object file yang telah dikompilasi sebelumnya sebelum melakukan build dari source. Jika tidak ada yang memeriksa source code, backdoor bisa ditambahkan, dan NixOS maupun distro lain tidak bisa mencegahnya

• "Bisa saja" berarti itu belum dibuktikan, dan faktanya mereka memang mendistribusikannya

• Analisis penjelas yang sangat bagus. Judulnya salah dan menyesatkan, mungkin "secara teknis akurat", tetapi hanya dalam arti "memiliki backdoor"

  • Ini menekankan perlunya alat manajer build dan penggunaannya, serta perlunya membangun graf pelacakan kausal yang eksplisit tentang bagaimana file memengaruhi file lain selama proses build, lalu menegakkan graf itu atau melaporkan penyimpangan dari graf pelacakan sebelumnya

• Jika PR Jia Tan disetujui, artefak berbahaya bisa dengan mudah masuk ke Github release seperti halnya ke tarball. Sulit memahami mengapa Github release dianggap sebagai mitigasi keamanan

• Soal tarball rilis yang berbeda dari source

  • Jika tarball yang disediakan maintainer dihasilkan secara jujur dari source code asli, sulit memahami bagaimana perbedaan versi dan semacamnya menjadi masalah
  • Tarball yang dihasilkan harus bisa dibuat dari source code itu sendiri, tanpa mengecualikan apa pun, dan harus git add & commit. Bahkan dalam kasus ini pun riwayat commit tetap harus diperiksa, dan karena secara kasatmata tampak tidak berbahaya, muncul pertanyaan bagaimana itu bisa diverifikasi
  • Menjadi masalah jika tarball yang dikelola dihasilkan dari source code milik pemilik dan tidak ada di Github

• Ada masalah yang lebih besar daripada sekadar mendorong file uji beracun, tetapi sulit memahami bagaimana Nix bisa mencegahnya

  • Jika sebuah proyek terkenal mengganti pemimpinnya, commit harus diperhatikan dengan saksama dan perlu dicek siapa pemimpinnya

• Bertanya-tanya apakah saya salah memahami artikelnya, atau ada sesuatu yang saya lewatkan