Xz: Linux Landlock’u etkisiz bırakan tek bir karakter

 (git.tukaani.org)
1 puan yazan GN⁺ 2024-03-31 | 1 yorum | WhatsApp'ta paylaş
  • xz.git’in CMakeLists.txt dosyasındaki değişiklik, Landlock sandbox algılamasını header varlığı kontrolünden gerçek derleme testine geçirirken test kodunun içine tek başına bir . karakterinin girdiği bir örnek
  • Yeni kontrol, linux/landlock.h bulunsa bile gerekli syscall tanımları eksik olabilecek sistemleri elemek için eklendi
  • Derleme testi <linux/landlock.h>, <sys/syscall.h>, <sys/prctl.h> dosyalarını include ediyor ve prctl, SYS_landlock_create_ruleset, SYS_landlock_restrict_self, LANDLOCK_CREATE_RULESET_VERSION öğelerine başvuruyor
  • Eski ölçüt olan HAVE_LINUX_LANDLOCK_H, HAVE_LINUX_LANDLOCK olarak değiştiriliyor; SANDBOX_COMPILE_DEFINITION ve SANDBOX_FOUND ayarları da bu sonuca bağlı oluyor
  • Commit, Autotools ve CMake build’lerindeki Linux Landlock feature test düzeltmesi; verilen diff ise CMake tarafındaki değişikliği gösteriyor

CMake’in Landlock algılama yöntemindeki değişiklik

  • Hedef dosya xz.git’in CMakeLists.txt dosyası; değişiklik noktası # Sandboxing: Landlock bloğu
  • Önceki CMake mantığı, ENABLE_SANDBOX ON veya landlock olduğunda ve SANDBOX_FOUND değilken check_include_file(linux/landlock.h HAVE_LINUX_LANDLOCK_H) ile yalnızca header varlığını kontrol ediyordu
  • Değişiklikten sonra, check_c_source_compiles ile küçük bir C kodu gerçekten derlenerek Landlock’un kullanılabilir olup olmadığı kontrol ediliyor
    • Bazı sistemlerde linux/landlock.h bulunsa bile Linux Landlock için gereken syscall tanımları olmayabilir
    • Test kodu <linux/landlock.h>, <sys/syscall.h>, <sys/prctl.h> dosyalarını include ediyor
    • my_sandbox() içinde prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0), SYS_landlock_create_ruleset, SYS_landlock_restrict_self, LANDLOCK_CREATE_RULESET_VERSION öğelerine başvuruluyor

Tek başına karakter ve değişken adı değişikliği

  • Eklenen derleme testi kodundaki include bloğundan sonra tek başına bir . satırı var
  • Sonuç değişkeni HAVE_LINUX_LANDLOCK_H yerine HAVE_LINUX_LANDLOCK olarak değiştirildi
  • Koşul da if(HAVE_LINUX_LANDLOCK_H) yerine if(HAVE_LINUX_LANDLOCK) olarak değiştirildi
  • SANDBOX_COMPILE_DEFINITION değeri "HAVE_LINUX_LANDLOCK_H" yerine "HAVE_LINUX_LANDLOCK" kullanıyor
  • Sonrasında SANDBOX_FOUND ON ayarı korunuyor

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-31
Hacker News yorumları

  • Yanıt: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=f9cf4c05edd...
    Linux Landlock erişim denetimi sistemini iyi bilmiyorsanız açıklaması burada: https://docs.kernel.org/userspace-api/landlock.html
    xz’nin resmi (muhtemelen...) olay müdahale sayfası: https://tukaani.org/xz-backdoor/

    • Yani o fonksiyon, ardından gelen C kodunun derlenip derlenmediğini kontrol ediyor ve yalnızca o durumda Landlock’u etkinleştiriyordu, öyle mi?
      Ama diff’in sol kenarına yakın yapışmış, fark edilmesi zor küçük tek bir nokta yüzünden C kodu her zaman geçersiz hale geliyor ve bu yüzden Landlock hep kapalı kalıyordu, öyle mi?
      Alçakça derecede etkileyici, etkileyici derecede alçakça. İlk okuduğumda ben de görmedim
    • Bunda makul inkâr edilebilirlik var
      Gizlemek için Unicode benzer karakterlerini değiştirmek gibi daha iyi yollar da var. Bazıları yazı tipine bağlı olarak piksel piksel aynı görünüyor
      Akışı kaçırmış olabilirim ama burada kasıtlı olduğu kesinleşti mi?
    • Bu o kadar kötü niyetli ki PR sırasında olay yerinde yakalansa bile “Aa, IDE’min otomatik biçimlendirmesi böyle yapmış” deyip geçiştirebilir
    • Lasse Collin yeniden ortaya çıktı ve muhtemelen epey öfkeli
    • Benim sürüm kontrol sistemim, böyle yekpare yeşil/kırmızı dizeler yerine değişen karakterleri daha iyi vurguluyor gibi geliyor

  • Dikkatlice göz gezdirirken, kesinlikle olmaması gereken bir yerde bir nokta gördüm ve “sandığımdan zor değilmiş” diye düşündüm
    Ekrana hafifçe dokundum, nokta hareket etti
    Lanet monitör tozu

  • Sistem güvenliğinin böylesine gevşek bir doğruluk zincirine dayanıyor olmasına inanamıyorum. Bunun önlenebileceği bir sürü nokta vardı
    + # 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.
    Böyle sistemlerdeki header düzeltilip açıkça hariç bırakmaları sağlanmalı. Header kendi işlevini bildirmiyorsa ne anlamı var?
    Ayrıca ikili blob oluşturulduktan sonra (açık kaynaktan derlenmiş olsa bile) güvenliğin sağlam olduğunu doğrulayan tek bir testin bile neden olmadığını da anlamıyorum
    Bir web sitesinin ödeme işlevini de temel işlevler için uçtan uca testler olmadan dağıtmazsınız. Özellik eklemenin kararlılığın önüne geçtiği bir öncelik uyumsuzluğu var gibi görünüyor
    Düzeltmenin sadece . karakterini kaldırmaktan ibaret olmamasını umuyorum. HN’deki başka bir yazıda az önce . kaldırmayı gösterdiklerini gördüm

    • Adam tamamen yeni bir test framework’ü getirdikten sonra, 2 yıl boyunca yavaş yavaş arka kapıyı yerleştirdi
    • Alıntıladığın sözler Jia Tan’a ait [1]. O kötü niyetli aktörün, kontrolü en başta kasıtlı olarak bozarken yazdığı yorum bu
      Header düzeltmek ya da ek testler bunu engellemezdi. Çünkü en başta header’ın bozuk olduğuna dair bir belirti yoktu; ek testler de başka bir şekilde sabote edilebilir ya da release tarball’ında yok sayılabilirdi
      [1] https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da8a2bbb8...
    • Biraz konu dışı ama GCC 9.4.0 bir ara bozuk bir arm_acle.h header’ı dağıtmıştı [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985] — o header’ı içeren kod her zaman derlemede başarısız oluyordu
      Kullanıcı GCC 9.4.0 ile derlemeye çalışabilir ve o header’a bağlı özellik uygulama için kritik olmayabilirdi; bu yüzden build, header’ın bozuk olduğunu algıladığında sadece o özelliği kapatıp uyarı veriyordu
      xz’ye dönersek, güvenlik en yüksek öncelik değilse isteğe bağlı bir özelliğin başarısızlığını yok sayıp devam etmek de makul görünüyor. Elbette geriye dönüp bakınca parmakla göstermek kolay, ama o bağlamı çıkarmazsanız tamamen anlamsız bir karar değil
    • Açık kaynak kullanıcısı olarak böyle bir öneride bulunacak kadar iyi bildiğimi sanmıyorum; bunu bizzat geliştirip katkı olarak gönderirsen minnettar olurum
    • Alıntıladığın yorum kodunun doğru olduğunu biliyor musun?

  • Vay canına, son commit’i güvenlik raporlamasını daha kötü hale getiriyor: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...

    • Bu neden kabul edildi ki? Gerçekten merak ediyorum

  • Landlock nerede/nasıl kullanılmak üzere tasarlanmıştı?
    Sıkıştırma/açma gibi genel amaçlı kütüphanelerde pratikte kullanması zor gibi. Kütüphane, programın ne yapması gerektiğini, neyin kısıtlanması gerektiğini bilemez.
    Bir program söz konusuysa daha net olabilir.
    sshd saldırısı liblzma’yı kütüphane olarak kullanıyordu. O zaman Landlock’ı kapatmanın bununla ilgisiz görünmesi gerekmez mi? Henüz keşfedilmemiş daha fazla kötü kod mu var, yoksa bunun daha sonra ekleneceğine dair bir işaret mi?

    • Muhtemelen sshd’nin kendisi, yürütmenin belirli bir noktasından sonra kendi yetkilerini kilitlemek için kullanıyordu.
      Landlock kaldırılınca daemon kendini kilitlemiyor; bu da istismar aşamasına gelindiğinde payload’un çalıştırılmasını kolaylaştırıyor.
      Bu ikisinin ilgisiz olduğunu düşünmüyorum. Zaten payload’u hesaba katmışlardı ve bunun bir engel olacağını fark etmişler gibi.
    • Tuhaf. Aynı projede birbirinden bağımsız arka kapı benzeri iki iş yapmak bana gerçekten özensiz geliyor. Kazanç az, yakalanma riskini ise ciddi biçimde artırıyor gibi.
      Bu olay çok kafa karıştırıcı. Bazı kısımları inanması zor derecede sofistike, diğer kısımlarıysa epey baştan savma görünüyor.
    • Kullanılabilir ve iyi bir fikir, ama kasıtlı arka kapıdan çok zafiyet istismarını önlemeye yönelik.
      Fikir şu: kütüphane karmaşık bir işi ayrı bir thread’de başlatır ve kullanıcı kodunun çağırdığı API içinde o thread’i bekler. Thread, Landlock’ı kendine uyguladıktan sonra işe başlar. Bir şey ters giderse kod izole edilmiş olur.
      Elbette bu durumda sandbox saldırganın kontrolünde olduğu için işe yaramaz. Çünkü saldırgan onu basitçe kapatabilir ya da ilk halinden daha zayıf yapabilir. Yine de başka şekillerde de yapılabilir.

  • Burada hedeflenen şey neydi acaba? Daha sonra daha fazla arka kapı, daha makul biçimde inkâr edilebilir arka kapılar mı eklemeyi planlıyorlardı? Bana kalırsa oss-fuzz da bu değişiklik de bulunan arka kapıyı gerçekten yakalayamazdı.
    Peki neden arka kapı yumurtalarının hepsini tek sepete, yani tek bir kütüphaneye koydular?

    • O kütüphane yeterince derine yerleşmişti, yeterince güveniliyordu ve ana geliştirici ruh sağlığı sorunları nedeniyle uzun süre internetten uzak kalabiliyordu.
      Üstelik kütüphanenin kendisini arka kapılı yapmak yerine, onu kullanan aracı hedefleme yöntemi bu. “Reflections on trusting trust” tarzı.
      Başarısız olana kadar kusursuz bir plan gibi duyuluyor.
    • Ama bunun yalnızca tek bir kütüphane olduğunu kim söyleyebilir?

  • xz’de Landlock’ın etkinleşmesini engellemenin neden faydalı olduğunu merak ediyorum. Daha sonraki bir aşamada xz arşivlerine kötü amaçlı içerik enjekte etmeyi mi amaçlıyorlardı? Öyleyse neden kötü amaçlı davranışı doğrudan xz’nin içine koymadılar?

    • Çünkü kasıtlı bir zafiyeti gizlemek, gerçek kötü amaçlı içerikten çok daha kolaydır.
      Bakımı yapılan bir C projesine buffer overflow ya da use-after-free’i kimseye fark ettirmeden gizlice eklemek mümkün olabilir. Gerçek bir Truva atı dağıtmak çok daha zordur ve xz-to-sshd arka kapısında bu ortaya çıktı.
    • ssh’yi hedeflemenin dışında, xz’nin kendisini hedefleyen daha incelikli bir arka kapı da olabilir. Hedefin kesinlikle gizlilik olduğu açık.

  • Bu beklenmedik şekilde fazla göze batıyor. Özelliği kapatma tekniği zekice ve commit de oldukça makul duruyor. Ama neden basitçe yazım hatası yapmak yerine bariz bir sözdizimi hatası seçtiler? Örneğin hata PR_SET_NO_NEW_PRIV olsaydı fark eder miydik?
    O tarafta inkâr edilebilirlik de daha yüksek olurdu.

  • Ayrı olarak, bu kötü amaçlı yazılım ekibi, güvenlik sorunlarını tespit edecek yapay zekayı eğitmek için harika bir veri kümesi oluşturmuş oldu. Her commit’te bir güvenlik sorunu var ve açık kaynak topluluğu bunları tek tek tarayıp bulacak.
    Temizlik işini yapan bakımcılara teşekkürler. Kesinlikle eğlenceli bir iş değildir.

    • Genellemenin iyi çalışacağını sanmıyorum. En fazla bir silahlanma yarışı olur.
    • Gördüğüm yapay zeka kullanımları arasında oldukça havalı olanlardan biri.
    • Bunu ilk kez duyuyorum; ilgili bilgileri biraz paylaşabilir misin?

  • Bu yüzden özellikleri otomatik olarak açıp kapatan configure tarzı derleme sistemlerini gerçekten sevmiyorum. Bir şeyi istiyorsam açıkça etkinleştirmek isterim. Bir özelliğin varsayılan olması için yeterli neden varsa, bunun yerine açıkça kapatılabilir olmalı.

    • Paketleme sırasında bu inanılmaz acı verici. Paketi yapılandırıyorsun, derlenene kadar bağımlılıkları ekliyorsun ve bitti sanıyorsun. Sonra X özelliği eksik. Ne oluyor? Ah, libY yokmuş, bu yüzden sessizce kapanmış. Geri dönüp ekliyorsun. Sonra kullanıcı Z özelliğinin olmadığını bildiriyor.
      Sadece varsayılan bir özellik kümesi koyup gerektiğinde --enable-a --disable-b kullanımına izin versinler.
      Denetim sürecindeki hataları sessizce yutması ise ayrı bir sorun.