NixOS ve yeniden üretilebilir derlemelerle tespit edilen xz arka kapısı

• Mart 2024'te, Linux dağıtımlarında kaynak tarball'larını açmak için kullanılan xz yazılımında bir arka kapı keşfedildi.
• Bu arka kapı, kötü niyetli bakımcı Jia Tan tarafından 3 yıl boyunca gizlice eklendi.
• Olay, uzaktan kod çalıştırmayı mümkün kıldığı için büyük etki yarattı ve tespit edilmesi son derece zordu.
• Microsoft'ta Postgres geliştiricisi olan Andres Freund, performans düşüşünü araştırırken bunu tesadüfen keşfederek büyük bir felaketi önledi.

Saldırı nasıl çalışıyordu

• Arka kapı, uzaktan kod çalıştırmayı mümkün kılmak için ssh programını ele geçiriyordu.
• RSA_public_decrypt işlevini değiştirerek, belirli bir RSA anahtarıyla oturum açıldığında saldırganın keyfi komutlar çalıştırabilmesini sağlıyordu.
• İki ana bileşenden oluşuyordu:
  1. Kötü amaçlı nesne dosyasını xz derleme sürecinin bir parçası olarak kuran bir betik.
  2. RSA_public_decrypt işlevini hook eden bir prosedür.

1. Kötü amaçlı nesne dosyasını kuran betik

• Kötü amaçlı nesne dosyası, xz git deposundaki test dosyalarının içinde gizlenmişti.
• Arka kapı yalnızca bakımcının sağladığı sürüm tarball'larında etkinleşiyordu.

2. RSA_public_decrypt işlevini hook etme prosedürü

• Dinamik yükleme sırasında çalışan kodu zorla yürütmek için glibc'nin ifunc özelliği kullanılıyordu.
• ssh çalıştığında libsystemd ve liblzma yükleniyor, bu süreçte arka kapı keyfi kod çalıştırıyordu.

xz felaketinden kaçınma yolları

• Açık kaynak yazılımın güvenilirliğini artırmak için hem sosyal hem de teknik sorunların ele alınması gerekiyor.
• Yazılım tedarik zinciri güvenliği süreçlerinin iyileştirilmesi gerekiyor.

Güvenilir kaynaklardan yazılım derlemek

• Saldırı etkili oldu çünkü birçok dağıtım xzyi derlemek için bakımcının sağladığı tarball'ları kullandı.
• Mümkün olduğunda yazılım, en güvenilir kaynaktan derlenmeli.

Koşullar elverdiğinde...

• NixOS, işlevsel paket yönetimi modeline dayanan bir dağıtımdır ve her paket, Nix adlı fonksiyonel bir programlama diliyle ifade edilir.
• NixOS'ta, GitHub tarafından otomatik oluşturulan kaynak arşivlerini kullanma kültürü vardır.

Güvenilmeyen sürüm tarball'ları için güven oluşturmak

• NixOS, bootstrap aşamasında bakımcının sağladığı tarball'ları kullanmak zorundaydı.
• Yazılım tedarik zinciri güvenliğini güçlendirmek için belirli koruma önlemleri hazırlanmalı.

1. Kaynakları karşılaştırmak

• Dağıtımın kullandığı kaynak tarball'ının GitHub'dakiyle aynı olup olmadığını doğrulamak önemlidir.
• Ancak sürüm tarball'ı kaynakla sık sık farklılık gösterebilir ve bu tek başına bir sorun değildir.

2. Bit düzeyinde yeniden üretilebilirlikten yararlanmak

• Yeniden üretilebilir derlemeler, aynı koşullarda iki kez derlendiğinde aynı artefaktları üreten yazılım projelerinin bir özelliğidir.
• Bit düzeyinde yeniden üretilebilirlik, güvenilmeyen bakımcı tarafından sağlanan tarball'lara güven oluşturmayı mümkün kılar.

Sonuç

• xz arka kapısı olayı, açık kaynak yazılım tedarik zinciri güvenliğinin önemini hatırlatıyor.
• NixOS gibi sistemler, yeniden üretilebilir derlemeler sayesinde güvenliği güçlendirebilir.

[GN⁺]

Hacker News görüşleri

• NixOS ve yeniden üretilebilir build'ler xz arka kapısını tespit edemedi. NixOS kötü amaçlı xz build'ini dağıttı, ancak NixOS hedef alınmadığı için bir sorun yaşanmadı

  • NixOS geliştiricileri, arka kapı ortaya çıktığında kötü amaçlı xz sürümünün kullanıcılara dağıtıldığını görünce şaşırdı
  • Teori ile gerçeklik farklıdır ve xz'nin mümkün olmasının nedeni teknik bir zafiyet değil, 'gerçek dünya' sorunlarıydı. Yazılımla gerçek dünyayı yamayamayacağımızı kabul etmek zor geliyor

• Yazar yalnızca bu olaya odaklanıyor gibi görünüyor. Jiatan olayı tek bir örnek ve başka senaryolarda da savunma başarısız olabilir

  • Bir NixOS kullanıcısı olarak, NixOS'un bunu yakalayamamış olmasının çok muhtemel olduğunu düşünüyorum. Kanıt yokken NixOS'a güvenmek saflık olur

• NixOS, xz arka kapısı RedHat ve Debian'ı hedef aldığı için konuyla ilgili değil. İronik biçimde arka kapı bir Microsoft çalışanı tarafından keşfedildi

• Yazıda, dağıtımların geleneksel kurulum tarball'ları yerine kaynak kodunu doğrudan VCS'den (ör. Github) alması gerektiği belirtiliyor

  • Ancak kötü niyetli bir maintainer, binary blob'ları doğrudan kaynak kod deposuna ekleyebilir
  • Yazar, sanki Github kodu doğruluyormuş gibi ona güvenilebileceğini öne sürüyor, ama gerçekte Github kodu doğrulamaz

• NixOS'un önleyebileceği olaylara odaklanılacaksa, CrowdStrike olayına bakmak gerekir. Dünkü yapılandırmayla boot edilebilseydi sorunların büyük kısmı hafifletilebilirdi

• NixOS her şeyi kaynaktan derler, kullanılan kaynakların kurcalanmadığını kriptografik olarak doğrular ve paketler arasında sürüm bağımlılıkları bulunur. Debian'ın da yeniden üretilebilir build'leri vardır

  • Sorun, build sisteminin kaynaktan build etmeden önce önceden derlenmiş nesne dosyalarını kaldırmamasıydı. Kaynak kodu kimse incelemiyorsa arka kapı eklenebilir ve bunu NixOS ya da başka bir dağıtım da engelleyemez

• "Yapabilirdi" ifadesi bunun kanıtlanmadığı anlamına gelir, oysa gerçekte bunu dağıttılar

• Harika bir açıklayıcı analiz. Başlık hatalı ve yanıltıcı; muhtemelen "teknik olarak doğru", ama "arka kapılı" anlamında en iyi ihtimalle öyle

  • Build yöneticisi araçlarının gerekliliğini ve kullanımını vurguluyor; build sürecinde dosyaların diğer dosyaları nasıl etkilediğine dair nedensel izleme grafiğinin açıkça oluşturulması, bu grafiğin zorunlu kılınması ya da önceki izleme grafiğinden sapmaların raporlanması için yöntemler geliştirilmesi gerekiyor

• Jia Tan'ın PR'ı onaylansaydı, kötü amaçlı artifact'ler de tarball'da olduğu gibi kolayca Github release'lerine girebilirdi. Github release'lerinin nasıl bir güvenlik önlemi sayıldığını anlamak zor

• Release tarball'larının kaynak koddan farklı olması

  • Eğer maintainer'ın sağladığı tarball gerçekten özgün kaynak koddan dürüstçe üretilmişse, farklı sürümler vb. durumların nasıl sorun oluşturduğunu anlamak zor
  • Üretilen tarball'ın doğrudan kaynak kodun kendisinden üretilebilmesi, hiçbir şeyin hariç tutulmaması ve git add & commit yapılması gerekir. Yine de bu durumda commit geçmişini kontrol etmek gerekir; çıplak gözle zararsız göründüğü için bunun nasıl doğrulanabileceği de ayrı bir soru
  • Maintainer'ın hazırladığı tarball, projenin sahibinin kaynak kodundan üretiliyor ve Github'da yer almıyorsa bu sorun olur

• Sadece zehirli test dosyalarının push edilmesinden ibaret olmayan sorunlar da vardı, ancak Nix'in bunu nasıl önleyebileceğini anlamak zor

  • Tanınmış bir proje lider değiştiriyorsa commit'lere dikkatle bakmak ve liderin kim olduğunu doğrulamak gerekir

• Acaba yazıyı yanlış mı anladım ya da gözden kaçırdığım bir şey mi var?