Xz: Satu Karakter yang Menonaktifkan Landlock Linux

 (git.tukaani.org)
1 poin oleh GN⁺ 2024-03-31 | 1 komentar | Bagikan ke WhatsApp
  • Perubahan CMakeLists.txt di xz.git terjadi saat deteksi sandbox Landlock diubah dari pemeriksaan keberadaan header menjadi uji kompilasi nyata, dan dalam proses itu ada kasus masuknya karakter tunggal . di dalam kode uji
  • Pemeriksaan baru ditambahkan untuk menyaring sistem yang meski memiliki linux/landlock.h, mungkin tidak memiliki definisi syscall yang diperlukan
  • Uji kompilasi menyertakan <linux/landlock.h>, <sys/syscall.h>, <sys/prctl.h> dan mereferensikan prctl, SYS_landlock_create_ruleset, SYS_landlock_restrict_self, LANDLOCK_CREATE_RULESET_VERSION
  • Kriteria lama HAVE_LINUX_LANDLOCK_H diubah menjadi HAVE_LINUX_LANDLOCK, dan pengaturan SANDBOX_COMPILE_DEFINITION serta SANDBOX_FOUND juga mengikuti hasil ini
  • Commit ini memperbaiki Linux Landlock feature test pada build Autotools dan CMake, dan diff yang disediakan menampilkan perubahan di sisi CMake

Perubahan metode deteksi Landlock di CMake

  • File yang menjadi sasaran adalah CMakeLists.txt di xz.git, dan lokasi perubahan ada pada blok # Sandboxing: Landlock
  • Logika CMake sebelumnya hanya memeriksa keberadaan header dengan check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H) ketika ENABLE_SANDBOX bernilai ON atau landlock dan SANDBOX_FOUND belum aktif
  • Setelah diubah, check_c_source_compiles digunakan untuk benar-benar mengompilasi kode C kecil guna memastikan apakah Landlock dapat digunakan
    • Pada sebagian sistem, linux/landlock.h mungkin ada tetapi definisi syscall yang dibutuhkan Linux Landlock tidak tersedia
    • Kode uji menyertakan <linux/landlock.h>, <sys/syscall.h>, <sys/prctl.h>
    • Di dalam my_sandbox(), kode tersebut mereferensikan prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), SYS_landlock_create_ruleset, SYS_landlock_restrict_self, LANDLOCK_CREATE_RULESET_VERSION

Karakter tunggal dan perubahan nama variabel

  • Tepat setelah blok include pada kode uji kompilasi yang disisipkan, ada satu baris . saja
  • Variabel hasil diubah dari HAVE_LINUX_LANDLOCK_H menjadi HAVE_LINUX_LANDLOCK
  • Kondisi juga berubah dari if(HAVE_LINUX_LANDLOCK_H) menjadi if(HAVE_LINUX_LANDLOCK)
  • Nilai SANDBOX_COMPILE_DEFINITION menggunakan "HAVE_LINUX_LANDLOCK" alih-alih "HAVE_LINUX_LANDLOCK_H"
  • Setelah itu, pengaturan SANDBOX_FOUND ON tetap dipertahankan

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-31
Komentar Hacker News

  • Jawaban: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...
    Kalau belum terlalu paham sistem kontrol akses Landlock di Linux, penjelasannya ada di sini: https://docs.kernel.org/userspace-api/landlock.html
    Halaman respons insiden resmi xz (mungkin...): https://tukaani.org/xz-backdoor/

    • Jadi fungsi itu memeriksa apakah kode C berikutnya bisa dikompilasi, dan hanya jika bisa, Landlock diaktifkan?
      Tapi karena satu tanda titik kecil yang menempel dekat tepi kiri diff dan sulit dilihat, kode C itu selalu menjadi tidak valid, sehingga Landlock selalu dimatikan?
      Sangat mengesankan dalam kebusukannya, dan sangat busuk dalam kepiawaiannya. Saat pertama membaca, aku juga tidak melihatnya
    • Ini punya plausible deniability
      Kalau ingin menyembunyikannya, ada cara yang lebih baik dengan mengganti karakter mirip Unicode. Beberapa terlihat identik sampai ke pikselnya, tergantung font
      Mungkin aku melewatkan alurnya, tapi apakah niat jahat di sini sudah dipastikan?
    • Ini begitu jahat sampai kalau ketahuan langsung saat PR pun masih bisa lolos dengan bilang, “Oh, auto-format IDE saya yang membuatnya begitu”
    • Lasse Collin muncul kembali, dan sepertinya sedang marah
    • Rasanya sistem version control-ku menyorot karakter yang berubah lebih baik daripada blok string hijau/merah utuh seperti ini

  • Saat memeriksa dengan hati-hati, aku melihat tanda titik di posisi yang jelas-jelas tidak semestinya, lalu berpikir “ternyata tidak sesulit itu”
    Aku mengetuk layar sedikit, dan tanda titik itu bergerak
    Sialan, ternyata debu monitor

  • Sulit dipercaya keamanan sistem bergantung pada rantai kebenaran yang serapuh ini. Ada begitu banyak titik yang bisa mencegahnya
    + # A compile check is done here because some systems have
    + # linux/landlock.h, but do not have the syscalls defined
    + # in order to actually use Linux Landlock.
    Header pada sistem seperti itu seharusnya diperbaiki agar dikecualikan secara eksplisit. Apa gunanya header kalau tidak mendeklarasikan fungsinya sendiri?
    Dan aku juga tidak mengerti kenapa setelah binary blob dibuat (meski dikompilasi dari open source), tidak ada satu pun tes untuk memastikan keamanannya tetap utuh
    Bahkan fitur pembayaran situs web pun tidak akan dideploy tanpa end-to-end test untuk fungsi inti. Tampaknya ada ketidaksinkronan prioritas di mana penambahan fitur lebih diutamakan daripada stabilitas
    Semoga perbaikannya bukan sekadar menghapus .. Aku baru saja melihat tulisan lain di HN yang menunjukkan penghapusan .

    • Dia memperkenalkan framework pengujian yang benar-benar baru, lalu perlahan menanam backdoor selama 2 tahun
    • Yang kamu kutip itu adalah kata-kata Jia Tan [1]. Itu komentar yang ditulis pelaku jahat tersebut saat sengaja merusak pemeriksaan sejak awal
      Memperbaiki header atau menambahkan tes tidak akan mencegahnya. Karena sejak awal tidak ada tanda bahwa header-nya rusak, dan tes tambahan pun bisa dirusak dengan cara lain atau diabaikan di release tarball
      [1] https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da8a2bbb8...
    • Sedikit menyimpang, tetapi GCC 9.4.0 pernah mendistribusikan header arm_acle.h yang rusak [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985] — kode yang menyertakan header itu selalu gagal dikompilasi
      Karena pengguna mungkin mencoba mengompilasi dengan GCC 9.4.0, dan fitur yang bergantung pada header itu tidak esensial bagi aplikasi, jika build mendeteksi header rusak, build cukup mematikan fitur tersebut dan mengeluarkan peringatan
      Kembali ke xz, jika keamanan bukan prioritas tertinggi, mengabaikan kegagalan fitur opsional dan tetap melanjutkan terlihat cukup masuk akal. Tentu setelah kejadian mudah untuk menyalahkan, tetapi jika konteks itu tidak diabaikan, keputusan tersebut tidak sepenuhnya tidak masuk akal
    • Sebagai pengguna open source, aku tidak cukup paham untuk memberi usulan seperti ini, jadi kalau kamu mengembangkannya sendiri dan berkontribusi, sepertinya akan sangat diapresiasi
    • Apakah kamu tahu bahwa kode komentar yang kamu kutip itu benar?

  • Astaga, commit terakhirnya justru membuat pelaporan keamanan menjadi lebih buruk: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...

    • Kenapa ini diterima? Serius bertanya

  • Landlock seharusnya dipakai di mana/bagaimana?
    Rasanya sulit benar-benar dipakai di library serbaguna seperti kompresi/dekompresi. Library tidak tahu program harus melakukan apa, dan apa yang harus dibatasi.
    Kalau berupa program, itu bisa lebih jelas.
    Serangan sshd menggunakan liblzma sebagai library. Kalau begitu, mematikan Landlock tampaknya tidak relevan? Apakah ini sinyal bahwa masih ada kode jahat lain yang belum ditemukan, atau rencananya akan dimasukkan nanti?

    • Mungkin sshd itu sendiri menggunakannya untuk mengunci hak aksesnya sendiri setelah titik tertentu dalam eksekusi.
      Jika Landlock dihapus, daemon tidak mengunci dirinya sendiri, sehingga saat mencapai tahap eksploitasi, eksekusi payload jadi lebih mudah.
      Saya tidak melihat keduanya tidak terkait. Sepertinya mereka sudah memikirkan payload, dan menyadari bahwa ini akan menjadi penghalang.
    • Aneh. Menurut saya, mengerjakan dua pekerjaan mirip backdoor yang tidak saling terkait dalam proyek yang sama itu benar-benar ceroboh. Manfaatnya kecil, sementara risiko ketahuan tampaknya jauh meningkat.
      Kasus ini sangat membingungkan. Beberapa bagiannya luar biasa canggih sampai sulit dipercaya, sementara bagian lain terlihat cukup ceroboh.
    • Bisa dipakai dan merupakan ide bagus, tetapi tujuannya lebih untuk mencegah eksploitasi kerentanan daripada backdoor yang disengaja.
      Idenya adalah library memulai pekerjaan kompleks di thread terpisah, lalu menunggu thread itu di dalam API yang dipanggil kode pengguna. Thread tersebut menerapkan Landlock pada dirinya sendiri, lalu mulai bekerja. Jika ada yang salah, kodenya terisolasi.
      Tentu saja dalam kasus ini sandbox dikendalikan penyerang, jadi tidak akan bekerja. Sebab penyerang bisa saja mematikannya atau membuatnya lebih lemah daripada semula. Meski begitu, ini juga bisa dilakukan dengan cara lain.

  • Sebenarnya apa yang mereka incar di sini? Apakah mereka berniat memasukkan lebih banyak backdoor nanti, backdoor yang lebih mudah disangkal secara masuk akal? Menurut saya oss-fuzz maupun perubahan ini kemungkinan tidak akan benar-benar menemukan backdoor yang akhirnya ditemukan.
    Lalu kenapa menaruh semua telur backdoor dalam satu keranjang, yaitu satu library?

    • Library itu tertanam cukup dalam, cukup dipercaya, dan pengembang utamanya pernah lama rehat dari internet karena masalah kesehatan mental.
      Selain itu, caranya bukan membuat backdoor pada library itu sendiri, melainkan menargetkan tool yang menggunakannya. Gaya “Reflections on trusting trust”.
      Kedengarannya seperti rencana sempurna sampai akhirnya gagal.
    • Tapi siapa yang bisa bilang itu hanya satu library?

  • Saya penasaran mengapa mencegah Landlock aktif di xz itu berguna. Apakah pada tahap berikutnya mereka berniat menyuntikkan konten berbahaya ke arsip xz? Kalau begitu, mengapa tidak langsung memasukkan perilaku berbahaya ke xz itu sendiri?

    • Karena kerentanan yang disengaja jauh lebih mudah disembunyikan daripada konten berbahaya yang sebenarnya.
      Menyusupkan buffer overflow atau use-after-free ke proyek C yang dipelihara mungkin bisa dilakukan tanpa ketahuan. Mendistribusikan trojan horse sungguhan jauh lebih sulit, dan itu terlihat pada backdoor xz-to-sshd.
    • Selain menargetkan ssh, mungkin ada backdoor lain yang lebih halus yang menargetkan xz itu sendiri. Jelas tujuannya adalah kerahasiaan.

  • Ini secara mengejutkan terlalu mencolok. Teknik mematikan fiturnya cerdik dan commit-nya juga cukup meyakinkan. Tapi mengapa memilih kesalahan sintaks yang jelas, alih-alih sekadar salah eja? Misalnya, kalau kesalahannya PR_SET_NO_NEW_PRIV, apakah orang akan menyadarinya?
    Itu juga akan memberi ruang penyangkalan yang lebih besar.

  • Secara terpisah, tim malware ini telah membuat dataset yang sangat bagus untuk melatih AI mengidentifikasi masalah keamanan. Setiap commit punya masalah keamanan, dan komunitas open source akan menelusurinya satu per satu untuk menemukannya.
    Terima kasih kepada para maintainer yang melakukan pekerjaan pembersihan. Jelas itu bukan pekerjaan yang menyenangkan.

    • Rasanya ini tidak akan tergeneralisasi dengan baik. Paling-paling hanya perlombaan senjata.
    • Ini termasuk salah satu penggunaan AI yang cukup keren yang pernah saya lihat.
    • Saya baru mendengar soal ini; bisa kirim informasi terkait?

  • Jadi saya benar-benar tidak suka sistem build gaya configure yang menyalakan dan mematikan fitur secara otomatis. Kalau menginginkan sesuatu, saya ingin mengaktifkannya secara eksplisit. Jika ada alasan kuat untuk menjadikan suatu fitur sebagai default, maka seharusnya fitur itu bisa dimatikan secara eksplisit sebagai gantinya.

    • Saat packaging, ini sangat menyakitkan. Kita mengonfigurasi paket, menambahkan dependency sampai bisa dibuild, lalu mengira semuanya selesai. Tapi ternyata fitur X tidak ada. Kenapa? Oh, karena libY tidak ada, jadi diam-diam dimatikan. Balik lagi dan tambahkan. Lalu pengguna melaporkan fitur Z tidak ada.
      Cukup sediakan kumpulan fitur default dan izinkan --enable-a --disable-b sesuai kebutuhan.
      Menelan bug dalam proses pemeriksaan secara diam-diam adalah masalah lain lagi.