Laporan audit Homebrew

 (blog.trailofbits.com)
1 poin oleh GN⁺ 2024-07-31 | 1 komentar | Bagikan ke WhatsApp
  • Audit Trail of Bits menemukan kemungkinan eksekusi kode tak terduga dan pelemahan integritas build di Homebrew, pengelola paket de facto standar bagi ekosistem pengembang macOS, meski temuan yang ditemukan tidak berada pada tingkat kritis
  • Cakupannya meliputi Homebrew/brew yang berisi CLI brew, serta Homebrew/actions, Homebrew/formulae.brew.sh, dan Homebrew/homebrew-test-bot, sehingga batas antara pengelola paket lokal dan CI/CD ikut ditinjau bersama
  • Masalah pada sisi brew mencakup injeksi string konfigurasi sandbox, tabrakan namespace berbasis MD5, penyertaan resource jaringan yang tidak dinyatakan, pivot socket macOS, penyalahgunaan token sudo, dan kemungkinan instalasi formula berbasis URL non-lokal
  • Di CI/CD, trigger pull_request_target dan input workflow_dispatch yang tidak divalidasi dapat menjadi jalur untuk manipulasi build bottle, kebocoran kredensial, eskalasi hak akses, dan perolehan persistensi pada self-hosted GitHub Actions runner
  • Homebrew mengasumsikan formula tepercaya, tetapi karena formula itu sendiri adalah kode Ruby yang dieksekusi dan permukaan API·CLI-nya luas, batas isolasi dan integritas sulit dijaga secara konsisten

Cakupan dan target audit

  • Trail of Bits melakukan audit Homebrew pada musim panas lalu
  • Target audit mencakup Homebrew/brew yang berisi CLI brew serta tiga repositori terkait yang penting dari sisi keamanan
  • Open Tech Fund mensponsori audit ini sebagai bagian dari upaya memperkuat keamanan komponen inti infrastruktur internet
  • Laporan lengkap dapat dilihat di repositori publications milik Trail of Bits

Mengapa Homebrew penting

  • Homebrew menyebut dirinya sebagai “package manager yang hilang untuk macOS atau Linux” dan berperan sebagai pengelola paket de facto standar bagi pengembang macOS
  • Setiap tahun menangani ratusan juta instalasi paket, termasuk paket inti seperti Golang, Node.js, dan OpenSSL
  • Integritas build dari paket-paket ini berkaitan bukan hanya dengan Homebrew, tetapi juga dengan keamanan ekosistem perangkat lunak turunannya
  • Core Homebrew adalah monolit Ruby yang menyediakan CLI brew dan API Ruby yang dapat dipakai ulang
  • Sejak dimulai pada 2009, Homebrew beberapa kali mengubah strukturnya untuk meningkatkan keandalan dan kemudahan penggunaan paket
    • Memperkenalkan bottle sebagai build biner
    • Menjadikan bottle sebagai metode instalasi default menggantikan build sumber lokal
    • Hanya membangun bottle di CI/CD untuk mengurangi dampak dari mesin pengembang yang telah terkompromi
  • Walau cara instalasinya makin statis, codebase inti masih menyimpan struktur historis yang memuat formula berbasis DSL secara dinamis melalui kode Ruby yang dikendalikan pengguna

Batas serangan yang dilihat dalam audit

  • Diperiksa apakah pelaku lokal dapat memicu eksekusi tak terduga dari formula DSL tanpa brew install yang eksplisit
  • Ditinjau apakah evaluasi formula dari tap dapat terjadi secara tak terduga hanya dengan pengguna menjalankan brew tap
  • Ditelaah apakah brew install foo dapat dipaksa memasang formula yang berbeda dari yang diharapkan melalui kebingungan atau tabrakan namespace
  • Juga diperiksa apakah formula yang terpasang secara lokal dapat diam-diam melewati atau melemahkan mekanisme isolasi build Homebrew
  • Di CI/CD, pertanyaan kuncinya adalah apakah pelaku berhak akses rendah dapat pivot ke hak lebih tinggi, meracuni build bottle, atau menciptakan persistensi

Masalah yang ditemukan pada CLI brew

  • Pada codebase CLI brew, ditemukan masalah yang dapat melemahkan properti integritas dan isolasi per formula
  • Juga teridentifikasi jalur yang memungkinkan formula dimuat dari sumber tak terduga seperti URL jarak jauh
  • Temuan utamanya adalah sebagai berikut
    • TOB-BREW-2: formula dapat mengubah konfigurasi sandbox melalui injeksi string, yang dapat berujung pada pelarian dari sandbox
    • TOB-BREW-5: Homebrew menggunakan fungsi hash MD5 yang rentan tabrakan untuk FormulaNamespace, namespace sintetisnya, sehingga penyerang dapat memicu kebingungan runtime antar-formula
    • TOB-BREW-8: formula dapat secara diam-diam menyertakan resource jaringan dalam build tanpa mendeklarasikannya di stanza resource
    • TOB-BREW-11: formula dapat keluar dari sandbox build di macOS menggunakan pivot socket
    • TOB-BREW-12: formula dapat melakukan eskalasi hak akses oportunistik melalui token sudo pengguna yang sebelumnya masih aktif
    • TOB-BREW-13: brew install dapat diarahkan untuk memasang formula dari URL non-lokal pada semua protokol yang didukung versi curl yang sedang digunakan, seperti SFTP dan SCP
  • Homebrew/brew telah diuji secara luas, tetapi karena permukaan API·CLI yang besar dan kontrak perilaku lokal yang informal, masih ada ruang bagi penyerang untuk mencari jalur eksekusi kode lokal di luar sandbox
  • Jalur-jalur ini tidak selalu merusak asumsi keamanan inti Homebrew yang menganggap formula tepercaya, tetapi dapat dieksploitasi melalui formula berbahaya atau pemuatan formula tak terduga dari input yang kurang difilter

Masalah yang ditemukan pada CI/CD Homebrew

  • Pada workflow dan action CI/CD Homebrew juga ditemukan masalah yang dapat melemahkan integritas eksekusi CI/CD
  • Dikonfirmasi adanya kemungkinan bagi pengguna berhak akses rendah untuk pivot ke posisi berhak lebih tinggi atau memperoleh persistensi di self-hosted GitHub Actions runner milik Homebrew
  • Temuan utamanya adalah sebagai berikut
    • TOB-BREW-18: beberapa workflow CI/CD menggunakan trigger pull_request_target, sehingga pull request pihak ketiga dapat mengeksekusi kode dalam konteks repositori upstream Homebrew, yang dapat berujung pada kebocoran kredensial atau manipulasi build bottle
    • TOB-BREW-23: beberapa workflow CI/CD mengizinkan injeksi shell melalui input workflow_dispatch yang tidak divalidasi, sehingga memungkinkan pergerakan vertikal oleh pengguna berhak akses rendah yang tidak bisa mengubah workflow tetapi bisa menjalankannya
  • Selain masalah khas CI/CD, sebagian temuan terkait brew juga penting di lingkungan CI/CD
    • TOB-BREW-6: kurangnya sandboxing dan isolasi saat ekstraksi arsip memungkinkan pelaku CI berhak rendah memicu ekstraksi formula atau kode eksekusi yang dimuat dan dijalankan otomatis, lalu pivot ke konteks berhak lebih tinggi
    • TOB-BREW-13: dapat digunakan untuk membuat CI memasang formula melalui brew install yang tidak berada dalam konteks kepercayaan yang telah diprakonfigurasi, sehingga membuka jalan ke eksekusi kode arbitrer dan pivot hak akses
  • CI/CD Homebrew matang dan efektif dalam mengurangi titik intervensi manusia pada siklus hidup paket, tetapi tetap bergantung pada pola workflow GitHub Actions yang umum namun rawan salah pakai
    • trigger workflow yang berisiko
    • pencampuran konfigurasi, kode, dan data melalui ekspansi template
  • Pola-pola ini tidak serta-merta memungkinkan pelaku eksternal sepenuhnya memperoleh persistensi atau melakukan pivot, tetapi dapat dimanfaatkan oleh insider berhak rendah seperti rogue maintainer untuk melemahkan asumsi integritas dan isolasi CI/CD

Mengapa audit package manager sulit

  • Ekosistem pengelola paket seperti Homebrew pada dasarnya memasang dan menjalankan kode arbitrer pihak ketiga, sehingga batas audit menjadi rumit
  • Perbedaan antara eksekusi kode yang diharapkan dan yang tak terduga juga umumnya bersifat informal dan didefinisikan secara longgar
  • Di Homebrew, masalah ini lebih menonjol karena formula sendiri adalah kode Ruby yang dieksekusi sebagai format distribusi paket
  • Dalam proses audit, tim bekerja erat dengan para maintainer Homebrew, Homebrew PLC, dan administrator keamanan Homebrew Patrick Linnane

Bacaan terkait

1 komentar

 
GN⁺ 2024-07-31
Pendapat Hacker News

  • Saya penulis tulisan ini sekaligus salah satu orang yang ikut dalam audit, jadi saya bisa menjawab pertanyaan
    Kalau laporan auditnya sendiri sulit ditemukan karena tautannya tidak langsung, saya juga meninggalkan salinannya di sini: https://github.com/trailofbits/publications/blob/eb9344f2261...

  • Kerja yang sangat bagus, dan tinjauan sistematis seperti inilah yang saya cari dari solusi open source semacam ini
    Mungkin bukan fokus code review-nya, tetapi saya penasaran dengan pandangan tentang masalah siklus hidup supply chain secara keseluruhan yang melekat pada platform manajemen paket open source. Hal-hal utamanya adalah apakah prosedur verifikasi untuk memastikan formula baru menunjuk ke sumber asli yang benar sudah memadai, bagaimana pengguna bisa yakin bahwa brew update masih merujuk ke sumber asli yang dapat dipercaya, apa yang terjadi jika domain diambil alih, dan seberapa cepat tim bisa merespons sumber formula yang tidak tepercaya
    Tidak semua masalah ini harus diselesaikan oleh Homebrew, tetapi ini pertimbangan penting di tingkat ekosistem. winget dan choco juga punya masalah yang sama, sedangkan repositori yang didukung secara komersial seperti apt atau yum lebih sedikit mengalaminya. Secara pribadi, dan bagi banyak administrator, ini juga menjadi kekhawatiran besar saat berurusan dengan Windows Store
    Terakhir, jika tim Homebrew melihat ini, akan sangat bagus jika ada notifikasi kerentanan ala npm

    • Masalah ini benar-benar serius, terutama ketika package manager dipakai di lingkungan produksi atau pipeline CI/CD
      Ada cukup banyak kasus publik ketika orang yang terkait dengan Partai Komunis Tiongkok mendapatkan hak pull request pada paket inti, dan saya kira ada lebih banyak kasus yang tidak dipublikasikan atau ditutup-tutupi. Sekadar berpindahnya kepemilikan paket dari pihak bereputasi baik ke individu yang kurang dikenal saja sudah semestinya mengkhawatirkan
      Dari posisi saya sebagai software engineer/engineering manager yang kemudian menjadi VC, saya penasaran apakah ada startup atau perusahaan komersial yang menyediakan jaminan seperti ini. Namun saya juga khawatir ukuran pasar untuk menyelesaikan masalah ini mungkin tidak cukup besar untuk menjadi bisnis mandiri

  • Sebelum pindah ke Nix, saya memakai MacPorts karena Homebrew saat itu bekerja dengan cara yang cukup aneh. Tidak bisa untuk setup multi-user, mengambil alih kepemilikan /usr/local, dan karena auto-update serta tidak adanya manajemen versi, banyak muncul masalah “works on my machine”
    Hal yang selalu terasa membuat saya gelisah di Homebrew bukan Git, melainkan fakta bahwa URL GitHub bisa dipakai seperti paket sementara. Saya penasaran apakah TOB-BREW-13 bekerja dengan cara seperti itu. Fitur itu selalu terdengar seperti insiden keamanan yang tinggal menunggu terjadi
    Bagaimanapun, saya juga ingin melihat audit Nix di macOS. Terutama saya penasaran apakah ada kelemahan pada cara kerja nix develop dan perintah terkait

    • Menarik, saya juga pindah dengan urutan Homebrew -> MacPorts -> Nix
      Homebrew mengumpulkan analitik dan versinya terlalu sering rusak. MacPorts jauh lebih stabil, tetapi beberapa paket niche tidak ter-build dengan baik dan ada masalah terminfo di tmux
      Nix bagus karena sebagian besar hal seperti ini bisa dioverride, dan saya bisa berbagi konfigurasi home manager dengan workstation Debian
    • Nix secara default tidak memakai build sandbox di macOS. Anda bisa mengaktifkannya sendiri dengan menambahkan sandbox = true di nix.conf, tetapi macam-macam hal bisa rusak
      Sandbox Nix sendiri sebenarnya juga tidak dirancang sebagai batas keamanan. Tidak ada upaya untuk mencegah sandbox escape, dan banyak hal dari host bocor ke lingkungan sandbox. Jika ingin membangun paket yang tidak tepercaya, Anda butuh sesuatu seperti gVisor atau VM penuh
    • Nix juga mengizinkan github

  • Saya melihat sekilas bug sandbox escape dan perbaikannya: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7...
    Saya ragu apakah ini benar. Sepertinya mereka mencoba mencegah karakter itu diinterpolasikan ke profil sandbox dan menimbulkan masalah, tetapi saya tidak tahu seberapa yakin kita bisa terhadap daftar karakter ini

    • Pesan commit-nya seharusnya bisa menjawab pertanyaan itu, tetapi nyatanya hanya mengulang apa yang sudah terlihat dari diff: “tidak mengizinkan karakter khusus pada path aturan sandbox”
      Tidak dijelaskan mengapa demikian, atau apa yang istimewa dari karakter tertentu yang dilarang. Pesan yang lebih baik akan memuat sesuatu seperti “jika tidak, karakter tertentu pada path diblokir karena ... . Alasan karakter-karakter ini perlu diperhatikan tetapi karakter lain aman adalah ...”
      Bahkan jika sekarang Anda menulis kode ini dan tahu apa yang dilakukannya, setahun kemudian saat melihatnya lagi Anda akan menggaruk kepala bertanya-tanya mengapa perubahan ini dibuat
      Contoh nyata pesan commit yang bagus ada di sini: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
    • Kalau itu perbaikannya, saya juga terkejut. Bukankah allowlist lebih baik daripada blacklist?

  • Beberapa waktu lalu saya mengganti brew dengan nix, dan UI teksnya masih bisa dibuat lebih ramah bagi pengguna akhir
    Jadi saya bahkan membuat wrapper bernama “ixnay” agar bisa melakukan ixnay install semudah brew (https://github.com/pmarreck/ixnay), tetapi secara keseluruhan jaminan yang didapat sepadan

    • Saya juga merasa command line nix menjengkelkan. Saya harus mencoba ini. Saya suka dokumentasi #help bawaannya
    • Andai saya tahu ixnay lebih awal. Saya juga kesal dengan pengalaman penggunanya dan akhirnya membuat tool sendiri, namanya hdn: https://github.com/seasonedfish/hdn
      Saya sudah menyebutkan ixnay di README

  • Agak mengejutkan bahwa integritas rantai pasok, yang merupakan permukaan serangan berketerampilan rendah besar pada Homebrew dibandingkan dengan hampir semua manajer paket Linux dan *BSD, tidak banyak dibahas
    Para maintainer Homebrew pada umumnya tidak menandatangani commit/paket, tidak menandatangani review/merge, tidak memverifikasi tanda tangan penulis/reviewer saat kompilasi, tidak mereproduksi build di CI yang dikontrol terpisah, dan juga tidak mewajibkan autentikasi dua faktor berbasis perangkat keras di GitHub
    Tingkat keamanan pengguna brew terikat pada tingkat orang dengan keamanan operasional terburuk hari ini di antara ratusan maintainer brew
    Selain itu, karena dependabot membuat commit secara otomatis, seseorang juga bisa memasukkan commit berbahaya ke proyek eksternal yang ia kendalikan, menunggu sampai dependabot membuat commit upgrade di Homebrew, lalu me-merge-nya sendiri. Untuk menjadi maintainer Homebrew, praktis hampir tidak ada verifikasi dan cukup memperbaiki beberapa bug mudah
    Seseorang juga bisa mengambil alih satu domain email maintainer yang sudah kedaluwarsa, mengirim email reset kata sandi ke dirinya sendiri, lalu membajak akun orang yang sedang liburan atau sedang tidak aktif
    Besar kemungkinan ribuan perusahaan bisa dibobol sebelum ada yang menyadarinya
    Sejujurnya, saya tidak akan pernah mengizinkan Brew di perangkat perusahaan yang memiliki hak akses. Itu sama saja memberi ratusan orang acak, dan siapa pun yang mengeksploitasi keamanan operasional mereka yang lemah, kemampuan untuk menjalankan kode arbitrer di sistem pengguna
    Manajer paket Linux utama juga belum cukup jauh dalam hal seperti penandatanganan review, tetapi kebanyakan setidaknya melakukan penandatanganan paket di level penulis, review manusia, dan build yang direproduksi secara independen untuk banyak paket
    Mengingat target bernilai tinggi seperti administrator sistem perusahaan sering mengizinkan brew di komputer mereka sendiri, Brew berada di jalur untuk kapan saja melampaui Crowdstrike dalam hal kerugian akibat manajemen rantai pasok yang kurang memadai

  • Jika di Mac ada dukungan PKGBUILD seperti Pacman dengan performa serupa dan paket program inti dipelihara dengan baik, rasanya kompromi yang harus diterima demi kenyamanan saat memakai Mac akan jauh lebih sedikit
    Homebrew itu hebat dan formula-nya benar-benar terawat dengan baik, tetapi karena kesederhanaan PKGBUILD, sinkronisasi yang cepat, dan beban kognitif yang lebih kecil karena tidak perlu mengingat berbagai argumen dan flag untuk tiap manajer paket, saya berharap pacman bisa langsung berjalan di Mac

    • pacman bawaan tidak berjalan di macOS seperti yang diharapkan, tetapi ada beberapa upaya untuk membuatnya berjalan dengan sedikit modifikasi/hack: https://github.com/liudongmiao/pacman, https://github.com/kladd/pacman-osx
    • Upaya seperti ini sudah beberapa kali ada. Sebagiannya mungkin benar-benar sedang berjalan
    • Bukankah MacPorts itu hal yang sama? Ini sungguh-sungguh saya tanyakan

  • Menurut saya vektor serangan utamanya adalah cukup dengan mengontribusikan formula baru dan menyelundupkan paket baru yang berbahaya
    Tim maintainer terlalu kecil untuk mengaudit semua formula yang baru dikontribusikan. Mengejutkan bahwa vektor serangan ini tidak termasuk dalam audit

    • Saya rasa para reviewer formula Homebrew core saat ini tidak akan menganggap tim mereka terlalu kecil untuk meninjau permintaan formula baru yang masuk secara memadai
      Kalaupun begitu, itu adalah salah satu ambiguitas packaging yang secara eksplisit dibahas dalam tulisan. Batas antara eksekusi pihak pertama dan pihak ketiga pada dasarnya kabur, dan menurut saya nilai keamanannya relatif lebih besar jika mencari titik ketika eksekusi pihak ketiga bisa terjadi di tempat yang tidak terduga, daripada menunjukkan semua hal yang sudah sewajarnya terjadi ketika seseorang dengan sengaja menjalankan kode pihak ketiga
      Namun, menurut saya ekosistem packaging secara keseluruhan memang perlu ditinjau untuk prosedur persetujuan seperti ini. Tetapi karena itu menyangkut prosedur manusia, sifatnya lebih dekat ke audit gaya red team daripada audit perangkat lunak
    • Bagian itu sudah dicatat, dan diasumsikan bahwa formula dapat dipercaya
      “... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...”
    • Saya juga kaget beberapa hari lalu ketika melihat seseorang mengunduh emulator konsol bernama “Cmder”. Itu kumpulan berbagai alat FOSS, dan secara harfiah ada sekitar 1.000 file yang bisa saja berbahaya, seperti skrip PowerShell, skrip Perl, skrip Python, skrip shell, DLL, EXE, dan sebagainya
      Pada akhirnya memang tidak berbahaya, tetapi menakutkan sekali orang-orang begitu saja meng-clone repositori Git seperti ini dan berharap semuanya baik-baik saja

  • Ada beberapa TOB-BREW-n yang tercantum, jadi saya sempat mengira itu semacam nomor CVE khusus proyek ini
    Edit: oh, ternyata “Trail Of Bits - homeBREW”. Tapi mungkin memang benar juga

    • Benar. Untuk hasil audit, kami memakai konvensi TOB-$PRODUCT-$XXXX. $PRODUCT adalah target audit dan $XXXX adalah penghitung unik yang meningkat untuk tiap temuan
      Setahu saya banyak perusahaan audit memakai cara serupa

  • Ungkapan di posting blog ini agak membingungkan. Disebutkan bahwa audit ini dilakukan bersama Homebrew, dan karena namanya terasa familier, saya mengecek README Homebrew lalu menemukan William Woodruff dalam daftar maintainer di https://github.com/Homebrew/brew
    Saya penasaran apakah ada alasan hal ini tidak disebutkan di posting blog. Sepertinya tidak akan membuat perbedaan besar, tetapi saya ingin memperjelasnya

    • Saat audit dilakukan, saya bukan maintainer :-)
      Saya sudah lama menjadi “member” non-maintainer proyek, semacam posisi hampir kehormatan yang diberikan kepada mantan maintainer yang ingin tetap ikut dalam percakapan internal dan tata kelola. Lalu beberapa bulan setelah audit selesai, karena pekerjaan lain terkait Homebrew yang bahkan belum ada dan belum direncanakan sebelum rencana audit, saya ditawari membership lagi
      Hal ini termasuk dalam semua pengungkapan konflik kepentingan yang saya sampaikan baik kepada perusahaan maupun para maintainer Homebrew, tetapi saya setuju bahwa ini juga bisa dibuat eksplisit di posting blog. Saya akan coba menambahkannya hari ini
      Ringkasnya, saat melakukan audit saya bukan maintainer, tetapi dulu pernah menjadi maintainer dan saat ini juga maintainer. Audit dilakukan oleh saya dan rekan-rekan sebagai pekerjaan profesional