Homebrew denetim raporu

 (blog.trailofbits.com)
1 puan yazan GN⁺ 2024-07-31 | 1 yorum | WhatsApp'ta paylaş
  • Trail of Bits denetimi, macOS geliştirici ekosisteminin fiili standart paket yöneticisi olan Homebrew'da beklenmedik kod yürütme ve derleme bütünlüğünün zayıflaması olasılığını tespit etti; bulgular kritik seviyede değildi
  • Kapsam, brew CLI'ının bulunduğu Homebrew/brew ile birlikte Homebrew/actions, Homebrew/formulae.brew.sh ve Homebrew/homebrew-test-bot'u da içererek yerel paket yöneticisi ile CI/CD sınırını birlikte inceledi
  • brew tarafındaki sorunlar; sandbox yapılandırma dizesi enjeksiyonu, MD5 tabanlı namespace çakışması, belirtilmemiş ağ kaynağı dahil etme, macOS socket pivot'u, sudo token'ının kötüye kullanımı ve yerel olmayan URL tabanlı formula kurulumu olasılığına uzanıyordu
  • CI/CD tarafında pull_request_target tetikleyicisi ve doğrulanmamış workflow_dispatch girdileri; bottle derlemelerinin manipüle edilmesi, kimlik bilgilerinin açığa çıkması, yetki yükseltme ve self-hosted GitHub Actions runner üzerinde kalıcılık sağlanması için yol oluşturabiliyordu
  • Homebrew güvenilir formula varsayımıyla çalışsa da, formula'nın kendisi Ruby ile yürütülen kod olduğundan ve API·CLI yüzeyi geniş olduğundan izolasyon ve bütünlük sınırlarını tutarlı biçimde korumak zor

Denetim kapsamı ve hedefler

  • Trail of Bits, geçen yaz Homebrew denetimi gerçekleştirdi
  • Denetimin hedefi, brew CLI'ının bulunduğu Homebrew/brew ile güvenlik açısından kritik üç bitişik depoydu
  • Open Tech Fund, internet altyapısının temel bileşenlerinin güvenliğini güçlendirme çalışmalarının bir parçası olarak denetime sponsor oldu
  • Raporun tamamı Trail of Bits'in publications deposunda görülebilir

Homebrew neden önemli

  • Homebrew kendisini “macOS veya Linux için eksik paket yöneticisi” olarak tanımlıyor ve macOS geliştiricileri için fiili standart paket yöneticisi rolünü üstleniyor
  • Her yıl yüz milyonlarca paket kurulumunu işliyor; kurulan paketler arasında Golang, Node.js ve OpenSSL gibi temel paketler de bulunuyor
  • Bu paketlerin derleme bütünlüğü, Homebrew'un ötesinde alt yazılım ekosisteminin güvenliğiyle bağlantılı
  • Homebrew'un core'u, brew CLI'ını ve yeniden kullanılabilir Ruby API'sini sağlayan bir Ruby monoliti
  • 2009'daki başlangıcından bu yana Homebrew, paket güvenilirliği ve kullanılabilirliğini artırmak için yapısını birkaç kez değiştirdi
    • İkili derleme biçimi olan bottle'ı tanıttı
    • Yerel kaynak derlemenin yerine bottle'ı varsayılan kurulum yöntemi yaptı
    • Tehlikeye girmiş geliştirici makinelerinin etkisini azaltmak için bottle'ların yalnızca CI/CD'de derlenmesini sağladı
  • Kurulum yöntemi giderek daha statik hale gelmiş olsa da, çekirdek kod tabanında DSL tabanlı formula'ları kullanıcı denetimli Ruby kodu olarak dinamik yükleyen tarihsel yapı hâlâ bulunuyor

Denetimde görülen saldırı sınırları

  • Yerel bir aktörün, açık bir brew install olmadan formula DSL'nin beklenmedik biçimde çalıştırılmasını tetikleyip tetikleyemeyeceği incelendi
  • Kullanıcının yalnızca brew tap çalıştırmasıyla bile bir tap içindeki formula değerlendirmesinin beklenmedik şekilde gerçekleşip gerçekleşemeyeceği gözden geçirildi
  • brew install foo komutunun beklenenden farklı bir formula kurmasını sağlayacak namespace karışıklığı veya çakışması yaratılıp yaratılamayacağı araştırıldı
  • Yerelde kurulu bir formula'nın, Homebrew'un derleme izolasyon mekanizmalarını gizlice atlatıp atlatamayacağı ya da zayıflatıp zayıflatamayacağı da kontrol edildi
  • CI/CD tarafında temel soru; düşük yetkili bir aktörün daha yüksek yetkiye pivot yapıp yapamayacağı, bottle derlemelerini kirletip kirletemeyeceği veya kalıcılık sağlayıp sağlayamayacağıydı

brew CLI'ında bulunan sorunlar

  • brew CLI kod tabanında, formula bazında bütünlük ve izolasyon özelliklerini zayıflatabilecek sorunlar bulundu
  • Formula'ların uzak URL'ler gibi beklenmedik kaynaklardan yüklenebileceği yollar da tespit edildi
  • Başlıca bulgular şunlardı
    • TOB-BREW-2: formula, dize enjeksiyonu ile sandbox yapılandırmasını değiştirebiliyor ve bu durum sandbox'tan kaçışa yol açabiliyor
    • TOB-BREW-5: Homebrew, sentetik namespace olan FormulaNamespace için çakışma üretmeye açık MD5 hash işlevi kullandığından, saldırgan formula'lar arasında çalışma zamanı karışıklığı yaratabiliyor
    • TOB-BREW-8: formula, resource stanza'sında belirtmeden ağa bağlı kaynakları derlemeye gizlice dahil edebiliyor
    • TOB-BREW-11: formula, macOS'ta socket pivot kullanarak derleme sandbox'ından çıkabiliyor
    • TOB-BREW-12: formula, kullanıcının önceden etkin olan sudo token'ı üzerinden fırsatçı yetki yükseltme yapabiliyor
    • TOB-BREW-13: brew install, kullanılan curl sürümünün desteklediği SFTP ve SCP gibi tüm protokoller üzerinden yerel olmayan URL'lerden formula kurulacak şekilde yönlendirilebiliyor
  • Homebrew/brew geniş ölçüde test edilmiş olsa da, büyük API·CLI yüzeyi ve yerel davranışlara dair gayriresmî sözleşmeler nedeniyle saldırganların sandbox dışı yerel kod yürütme yolları bulması için geniş alan bırakıyor
  • Bu yollar, güvenilir formula varsayımına dayanan Homebrew'un temel güvenlik öncülünü mutlaka bozmasa da, kötü amaçlı formula'lar veya yeterince arındırılmamış girdiler üzerinden beklenmedik formula yüklemelerinde istismar edilebiliyor

Homebrew CI/CD'de bulunan sorunlar

  • Homebrew CI/CD iş akışları ve actions tarafında da, CI/CD yürütmesinin bütünlüğünü zayıflatabilecek sorunlar bulundu
  • Düşük yetkili kullanıcıların daha yüksek yetkili konumlara pivot yapabilme ya da Homebrew'un self-hosted GitHub Actions runner'ı üzerinde kalıcılık elde etme ihtimali doğrulandı
  • Başlıca bulgular şunlardı
    • TOB-BREW-18: birden fazla CI/CD iş akışı pull_request_target tetikleyicisini kullanarak üçüncü taraf pull request'lerin Homebrew upstream deposu bağlamında kod çalıştırabilmesine izin verdi; bu da kimlik bilgilerinin açığa çıkmasına veya bottle derlemelerinin manipüle edilmesine yol açabiliyordu
    • TOB-BREW-23: birden fazla CI/CD iş akışı, doğrulanmamış workflow_dispatch girdileri üzerinden shell enjeksiyonuna izin vererek, iş akışını değiştiremeyen ama çalıştırabilen düşük yetkili kullanıcıların dikey yetki sıçraması yapmasına yol açabiliyordu
  • CI/CD'ye özgü sorunların yanı sıra, brew ile ilgili bazı bulgular da CI/CD ortamında önem taşıyordu
    • TOB-BREW-6: arşiv çıkarma sırasında yetersiz sandboxing ve izolasyon nedeniyle, düşük yetkili bir CI aktörü otomatik yüklenen ve çalıştırılan formula'ların veya çalıştırılabilir kodun çıkarılmasını tetikleyip daha yüksek yetkili bağlama pivot yapabiliyordu
    • TOB-BREW-13: CI'nin önceden yapılandırılmış güven bağlamında bulunmayan formula'ların brew install ile kurulması sağlanarak keyfi kod yürütme ve yetki pivot'u için kullanılabiliyordu
  • Homebrew CI/CD, paket yaşam döngüsünde insan müdahalesi noktalarını azaltma açısından olgun ve etkili olsa da, GitHub Actions iş akışlarında sık görülen hatalı kullanım kalıplarına dayanıyor
    • riskli iş akışı tetikleyicileri
    • şablon genişletme yoluyla yapılandırma, kod ve verinin karıştırılması
  • Bu kalıplar, tam anlamıyla dış bir aktörün kalıcılık kazanmasını veya pivot yapmasını mutlaka mümkün kılmasa da, rogue maintainer gibi düşük yetkili iç aktörlerin CI/CD'nin bütünlük ve izolasyon varsayımlarını zayıflatmasına imkân tanıyabiliyor

Paket yöneticisi denetimi neden zor

  • Homebrew gibi paket yöneticisi ekosistemleri tasarım gereği keyfi üçüncü taraf kodu kurup çalıştırdığı için denetim sınırını belirlemek zor
  • Beklenen kod yürütme ile beklenmedik kod yürütme arasındaki ayrım da çoğu zaman gayriresmî ve gevşek biçimde tanımlanmış durumda
  • Homebrew'da bu sorun daha belirgin, çünkü paket taşıma biçimi olan formula'nın kendisi Ruby ile yürütülen kod
  • Denetim sürecinde Homebrew maintainers, Homebrew PLC ve Homebrew güvenlik yöneticisi Patrick Linnane ile yakın çalışıldı

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-31
Hacker News görüşleri

  • Bu yazının yazarı ve denetime katılan kişilerden biri olduğum için soruları yanıtlayabilirim.
    Denetim raporunun kendisini bulmak zorsa, bağlantı dolaylı olduğu için bir kopyasını da buraya bırakıyorum: https://github.com/trailofbits/publications/blob/eb9344f2261...

  • Harika bir çalışma; böyle açık kaynak çözümlerinde aradığım şey tam da bu tür sistematik bir incelemeydi.
    Kod incelemesinin odağı olmayabilir ama açık kaynak paket yönetim platformlarının doğasında bulunan genel tedarik zinciri yaşam döngüsü sorunları hakkındaki görüşünüzü merak ediyorum. Yeni bir formula’nın doğru kaynağa işaret ettiğini garanti eden doğrulama sürecinin yeterli olup olmadığı, kullanıcıların brew update’in hâlâ güvenilir bir kaynağa referans verdiğinden nasıl emin olacağı, alan adı ele geçirilirse ne olacağı ve ekibin bir formula’nın güvenilmeyen kaynağına ne kadar hızlı yanıt verebileceği temel konular.
    Bu sorunların tamamı Homebrew’ün çözmesi gereken şeyler değil, ancak ekosistem düzeyinde önemli değerlendirme konuları. winget ve choco’da da aynı sorun var; apt veya yum gibi ticari olarak desteklenen depolarda ise daha az. Kişisel olarak ve birçok yönetici için Windows Store ile uğraşırken de bu büyük bir endişe.
    Son olarak Homebrew ekibi bunu görüyorsa, npm tarzı güvenlik açığı bildirimleri olsa gerçekten iyi olurdu.

    • Bu sorun, özellikle paket yöneticileri üretim ortamında veya CI/CD pipeline’larında kullanıldığında gerçekten ciddi.
      Çin Komünist Partisi ile ilişkili kişilerin kritik paketlerde pull request yetkisi elde ettiği yeterince açık vaka var; kamuya açıklanmayan veya üstü kapatılan daha fazlası olduğunu düşünüyorum. Paket sahipliğinin itibarlı bir aktörden daha az tanınan bir kişiye geçmesi bile doğal olarak endişe verici.
      Yazılım mühendisi/mühendislik yöneticisiyken VC’ye geçmiş biri olarak, bu tür güvenceler sağlayan startup’lar veya ticari şirketler olup olmadığını merak ediyorum. Bununla birlikte, bu sorunu çözmeye yönelik pazar büyüklüğünün bağımsız bir iş olacak kadar yeterli olmayabileceğinden de endişeliyim.

  • Nix’e geçmeden önce Homebrew o zamanlar oldukça tuhaf davrandığı için MacPorts kullanıyordum. Çok kullanıcılı kurulumlarda çalışmıyor, /usr/localın sahipliğini alıyor, otomatik güncellemeler ve sürüm yönetimi eksikliği yüzünden çok sayıda “benim makinemde çalışıyor” sorunu çıkarıyordu.
    Homebrew’de beni hep huzursuz eden şey Git değil, GitHub URL’lerinin geçici paketler gibi kullanılabilmesiydi. TOB-BREW-13’ün bu şekilde çalışıp çalışmadığını merak ediyorum. Bu özellik bana her zaman bir güvenlik olayının yaşanmasını bekliyormuş gibi gelmişti.
    Her hâlükârda macOS’ta Nix denetimi de görmek isterim. Özellikle nix develop ve ilgili komutların çalışma biçiminde kusurlar olup olmadığını merak ediyorum.

    • Benim de Homebrew -> MacPorts -> Nix sırasıyla geçmiş olmam ilginç.
      Homebrew’de analiz toplama vardı ve sürümler çok sık bozuluyordu. MacPorts çok daha kararlıydı ama bazı niş paketler düzgün derlenmiyordu ve tmux’ta terminfo sorunları vardı.
      Nix’in bunların çoğunu yeniden tanımlamaya izin vermesi ve Debian iş istasyonuyla home manager yapılandırmasını paylaşabilmem güzel.
    • Nix, macOS’ta varsayılan olarak derleme sandbox’ı kullanmaz. nix.conf içine sandbox = true koyarak kendiniz açabilirsiniz, ancak bu çeşitli şeyleri bozabilir.
      Nix sandbox’ı da aslında bir güvenlik sınırı olarak tasarlanmış değil. Sandbox’tan kaçışı engellemeye yönelik çaba harcanmış değil ve host’taki pek çok şey sandbox ortamına sızıyor. Güvenilmeyen paketleri derlemek istiyorsanız gVisor veya tam bir VM gibi bir şeye ihtiyaç var.
    • Nix de github’a izin veriyor.

  • Sandbox’tan kaçış hatası ve ilgili düzeltmelere göz attım: https://github.com/Homebrew/brew/pull/17700/commits/f4e5e0c7...
    Bunun doğru olup olmadığından emin değilim. Sandbox profiline yerleştirilip sorun çıkarmasını engellemeye çalışıyor gibi görünüyor, ama bu karakter listesi konusunda ne kadar emin olunabilir bilmiyorum.

    • Commit mesajı bu soruya yanıt verebilirdi, ama gerçekte diff’in zaten gösterdiği “sandbox kural yollarında özel karakterlere izin verme” ifadesini tekrarlamakla kalmış.
      Nedenini veya yasaklanan belirli karakterleri neyin özel yaptığını açıklamıyor. Daha iyi bir mesaj, “aksi hâlde ... nedeniyle yoldaki belirli karakterleri engeller. Bu karakterlerin önemsenmesi gerekirken diğerlerinin sorun olmamasının nedeni ...” gibi bir içerik taşırdı.
      Şu anda bu kodu yazıp ne yaptığınızı biliyor olsanız bile, 1 yıl sonra tekrar baktığınızda bu değişikliği neden yaptığınızı anlamak için başınızı kaşıyacaksınız.
      İyi bir commit mesajının gerçek örneği burada: https://github.com/git/git/commit/92fe7c7d42cc941ed70d6fce98...
    • Düzeltme buysa ben de şaşırırım. Kara liste yerine izin verilenler listesi daha iyi olmaz mı?

  • Bir süre önce brew yerine nix kullanmaya başladım; metin kullanıcı arayüzü son kullanıcı dostluğu açısından daha iyi olabilir.
    Bu yüzden brew kadar kolay ixnay install yapabilmek için “ixnay” adında bir wrapper bile yaptım (https://github.com/pmarreck/ixnay), ama genel garantiler buna değiyor.

    • Ben de nix komut satırını can sıkıcı buluyorum. Bunu bir denemem gerekecek. Yerleşik #help dokümantasyonunu beğendim.
    • ixnay’i daha önce bilmiş olmayı isterdim. Ben de kullanıcı deneyiminden rahatsız olup sonunda kendi aracımı yaptım; adı hdn: https://github.com/seasonedfish/hdn
      README’de ixnay’den bahsettim.

  • Neredeyse tüm Linux ve *BSD paket yöneticileriyle karşılaştırıldığında Homebrew’ün büyük düşük beceri gerektiren saldırı yüzeyi olan tedarik zinciri bütünlüğünün pek ele alınmamış olması biraz şaşırtıcı
    Homebrew bakımcıları genelde commit’leri/paketleri imzalamıyor, inceleme/birleştirmeleri imzalamıyor, derleme sırasında yazar/inceleyici imzalarını doğrulamıyor, ayrı denetimli CI’da derlemeleri yeniden üretmiyor ve GitHub’da donanımsal iki faktörlü kimlik doğrulamayı da zorunlu kılmıyor
    brew kullanıcılarının güvenlik seviyesi, yüzlerce brew bakımcısı arasında bugün operasyonel güvenliği en kötü olan kişinin seviyesine bağlı kalıyor
    Ayrıca dependabot otomatik olarak commit oluşturduğu için, kontrolünüzdeki harici bir projeye kötü amaçlı bir commit koyup dependabot’ın Homebrew’e yükseltme commit’i oluşturmasını bekledikten sonra bunu kendiniz birleştirmeniz de mümkün. Homebrew bakımcısı olmak için fiilen neredeyse hiç doğrulama yok; birkaç kolay hatayı düzeltmek yeterli
    Bir bakımcının süresi dolmuş e-posta alan adını ele geçirip parola sıfırlama e-postasını kendinize gönderebilir, tatilde olan ya da ara vermiş birinin hesabını da ele geçirebilirsiniz
    Birileri fark etmeden binlerce şirketi ihlal edebilme olasılığı yüksek
    Açıkçası yetkili şirket cihazlarında Brew’e asla izin vermezdim. Bu, yüzlerce rastgele kişiye ve onların zayıf operasyonel güvenliğini istismar eden herkese kullanıcı sistemlerinde keyfi kod çalıştırma yetkisi vermek demek
    Başlıca Linux paket yöneticileri de inceleme imzası gibi konularda yeterince ileri gitmiş değil, ama çoğu en azından yazar düzeyinde paket imzalama, insan incelemesi ve pek çok paket için bağımsız yeniden üretilebilir derlemeler yapıyor
    Şirket sistem yöneticileri gibi yüksek değerli hedeflerin kendi bilgisayarlarında brew’e sıkça izin verdiği düşünülürse, Brew yetersiz tedarik zinciri yönetimi nedeniyle verebileceği zarar açısından her an Crowdstrike’ı aşacak bir yörüngede

  • Mac’te Pacman gibi PKGBUILD benzer performansla desteklense ve temel program paketleri düzgün biçimde bakımlı olsa, Mac kullanırken kolaylık uğruna katlanılması gereken tavizlerin çok daha az olacağını düşünüyorum
    Homebrew harika ve formula’lar gerçekten iyi bakılıyor, ama PKGBUILD’in sadeliği, hızlı senkronizasyon ve her paket yöneticisi için bir sürü argüman ve bayrak hatırlama yönündeki bilişsel yükün azlığı nedeniyle pacman’in Mac’te doğrudan çalışmasını isterdim

    • Varsayılan pacman macOS’te beklendiği gibi çalışmıyor, ama küçük değişiklikler/hack’lerle çalıştırmaya yönelik girişimler var: https://github.com/liudongmiao/pacman, https://github.com/kladd/pacman-osx
    • Böyle girişimler birkaç kez oldu. Bazıları gerçekten çalışıyor da olabilir
    • MacPorts aynı şey değil mi? Gerçekten merak ediyorum

  • Başlıca saldırı vektörünün, basitçe yeni bir formula katkısı yaparak kötü amaçlı yeni bir paketi gizlice içeri sokabilmek olduğunu düşünüyorum
    Bakımcı ekibi, yeni katkı yapılan tüm formula’ları denetlemek için fazla küçük. Bu saldırı vektörünün denetime dahil edilmemiş olması şaşırtıcı

    • Mevcut Homebrew core formula inceleyicilerinin, ekiplerinin gelen yeni formula isteklerini yeterince incelemek için fazla küçük olduğunu düşüneceğini sanmıyorum
      Öyle olsa bile, bu yazıda açıkça ele alınan paketlemenin belirsizliklerinden biri. Birinci taraf ve üçüncü taraf çalıştırma arasındaki sınır doğası gereği bulanık; üçüncü taraf kodu kasıtlı olarak çalıştırdığınızda olan bariz şeylerin hepsini işaret etmektense, üçüncü taraf çalıştırmanın beklenmedik yerlerde gerçekleşebileceği noktaları bulmanın güvenlik değeri bence görece daha yüksek
      Yine de paketleme ekosisteminin genelinin bu tür onay süreçleri açısından incelenmesi gerektiğini düşünüyorum. Ancak bu insan süreçleriyle ilgili olduğundan, yazılım denetiminden çok red team tarzı bir denetime daha yakın
    • O kısım not edilmişti ve formula’ların güvenilir olduğu varsayılmıştı
      “... These avenues do not necessarily violate Homebrew’s core security assumptions (which assume trustworthy formulae),...”
    • Ben de birkaç gün önce birinin “Cmder” adlı bir konsol emülatörünü indirdiğini görünce irkildim. Çeşitli FOSS araçlarının bir araya getirilmiş haliydi; PowerShell betikleri, Perl betikleri, Python betikleri, shell betikleri, DLL’ler, EXE’ler vb. kötü amaçlı olabilecek kelimenin tam anlamıyla yaklaşık 1.000 dosya vardı
      Sonuçta zararsız çıktı, ama insanların böyle Git depolarını olduğu gibi klonlayıp her şeyin yolunda gitmesini umması gerçekten ürkütücü

  • Birden fazla TOB-BREW-n listelendiğini görünce, bunun bu projeye özel CVE numarası gibi bir şey olup olmadığını düşündüm
    Düzeltme: Ah, “Trail Of Bits - homeBREW”müş. Yine de muhtemelen doğru gibi

    • Evet. Denetim bulgularında TOB-$PRODUCT-$XXXX geleneğini kullanıyoruz. $PRODUCT denetlenen hedef, $XXXX ise her bulgu için benzersiz artan sayaç
      Bildiğim kadarıyla birçok denetim şirketi benzer bir yöntem kullanıyor

  • Bu blog yazısındaki ifade biraz kafa karıştırıcı. Bu denetimin Homebrew ile birlikte yapıldığı söyleniyor; isim tanıdık geldiği için Homebrew README’sini kontrol ettim ve https://github.com/Homebrew/brew adresindeki bakımcı listesinde William Woodruff var
    Blog yazısında bunun neden belirtilmediğini merak ediyorum. Büyük bir fark yaratacak gibi değil, ama netleştirmek istedim

    • Denetimi yaptığımız sırada bakımcı değildim :-)
      Uzun süre projenin bakımcı olmayan bir “üyesi”ydim; bu, iç konuşmalara ve yönetişime katılmaya devam etmek isteyen eski bakımcılara verilen yarı onursal bir pozisyon gibi. Daha sonra, denetim bittikten birkaç ay sonra, denetim planlanmadan önce var olmayan ve planlanmamış başka Homebrew bağlantılı işler nedeniyle bana yeniden üyelik teklif edildi
      Bu konu, hem şirkete hem de Homebrew bakımcılarına yaptığım çıkar çatışması açıklamalarında yer alıyordu; ancak blog yazısında da açıkça belirtilebileceğine katılıyorum. Bugün eklemeye çalışacağım
      Özetle, denetimi yürüttüğüm sırada bakımcı değildim; ama geçmişte bakımcıydım ve şu anda da bakımcıyım. Denetimi ben ve meslektaşlarım profesyonel iş olarak yürüttük