Neredeyse tüm dünyayı enfekte edecek olan xz Utils arka kapısı hakkında bilinenler

 (arstechnica.com)
3 puan yazan GN⁺ 2024-04-02 | 1 yorum | WhatsApp'ta paylaş
  • Microsoft’tan Andres Freund, Debian sistemlerinde SSH performansındaki anormalliği izlerken, neredeyse tüm Linux/Unix türevi ortamlarda kullanılan xz Utils içine yerleştirilmiş bir arka kapı keşfetti
  • Kötü amaçlı kod xz Utils 5.6.0 ve 5.6.1 sürümlerine eklendi ve belirli bir özel anahtara sahip saldırganın SSH oturum açma sertifikasında kod gizleyerek bunu arka kapılı cihazda çalıştırabilmesi için tasarlandı
  • Saldırgan, GitHub kaynağı yerine release tarball’ı, test dosyalarını, build script’lerini ve glibc IFUNC’u kullanarak liblzma üzerinden sshd kimlik doğrulama rutinine kanca atmayı hedefledi
  • Arka kapı amd64/x86_64, glibc, Debian veya Red Hat tabanlı paket build koşullarını kontrol etti; Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed/MicroOS ve Kali Linux’un belirli dönem sürümlerine dahil edildi
  • Jia Tan adlı geliştirici personası, yıllar boyunca xz Utils bakım sürecine dahil oldu; olay CVE-2024-3094 olarak izleniyor ve Binarly tarama sayfası ile xzbot gibi tespit ve analiz araçları ortaya çıktı

Keşif ve etki alanı

  • Andres Freund, Microsoft’ta PostgreSQL ile ilgili işler yapan bir geliştirici ve mühendisti; Debian sistemlerinde SSH oturum açma sırasında CPU’nun aşırı kullanılması ve valgrind hataları görülmesini araştırırken anormalliği fark etti
  • Sebep xz Utils güncellemesiydi ve Freund, Open Source Security List’te bu güncellemenin sıkıştırma yazılımına kasıtlı olarak yerleştirilmiş bir arka kapı olduğunu açıkladı
  • xz Utils, Linux dahil neredeyse tüm Unix türevi işletim sistemlerinde kayıpsız veri sıkıştırma ve açma sağlar, ayrıca eski .lzma biçimini de destekler
  • Filippo Valsorda bunu, “kamuya açık şekilde açıklanmış tedarik zinciri saldırıları arasında en iyi uygulanmış örnek olabilir; yaygın kullanılan bir kütüphanenin kötü niyetli, yetkin ve yetkili upstream’i gibi kâbus senaryosu” diye değerlendirdi

Arka kapının hedeflediği davranış

  • Kötü amaçlı kod xz Utils 5.6.0 ve 5.6.1 sürümlerine eklenerek yazılımın çalışma biçimini değiştirdi
  • Arka kapı, uzak SSH bağlantılarında kullanılan yürütülebilir dosya sshd’yi manipüle ediyor
  • Önceden belirlenmiş bir kriptografik anahtara sahip biri, SSH oturum açma sertifikasında istediği kodu gizleyip bunu yükledikten sonra arka kapılı cihazda çalıştırabiliyor
  • Gerçekte yüklenen kod doğrulanmadığı için saldırganın hangi kodu çalıştırmayı amaçladığı bilinmiyor
  • Teorik olarak kriptografik anahtarların çalınmasından kötü amaçlı yazılım kurulmasına kadar neredeyse her şey mümkün olabilir

Sıkıştırma kütüphanesinin SSH’ye ulaşma yolu

  • Bir kütüphane, kendisine bağlanan yürütülebilir dosyanın iç işleyişini manipüle edebilir
  • OpenSSH’nin tipik sshd uygulaması varsayılan olarak liblzma ile linklenmez
  • Debian ve çeşitli Linux dağıtımları, sshd’yi systemd ile bağlayan yamalar ekledi
    • systemd, açılış sırasında çeşitli servisleri yükleyen programdır
    • systemd, liblzma ile linklidir
    • Bu bağlantı yolu nedeniyle xz Utils sshd’yi etkileyebildi

Yıllara yayılan hazırlık işaretleri

  • 2021’de JiaT75 adlı kullanıcı, bir açık kaynak projede bilinen ilk commit’ini bıraktı
    • Bu, libarchive projesinde safe_fprint işlevini uzun süredir daha az güvenli olduğu bilinen bir varyantla değiştiren bir değişiklikti ve o sırada kimse bunu fark etmedi
  • 2022’de JiaT75, xz Utils e-posta listesine bir yama gönderdi
    • Kısa süre sonra Jigar Kumar adlı yeni bir katılımcı, Lasse Collin’e xz Utils’i yeterince sık veya hızlı güncellemediği yönünde baskı yaptı
    • Dennis Ens ve başka yeni katılımcılar da Collin’e ek bakımcılar alması için baskı yaptı
  • 2023 Ocak’ta JiaT75, xz Utils’e ilk commit’ini bıraktı ve Jia Tan adıyla xz Utils işlerine daha derin biçimde dahil oldu
    • oss-fuzz’daki Collin iletişim bilgisini kendi bilgisiyle değiştirdi
    • oss-fuzz testlerinde IFUNC özelliğini devre dışı bırakarak, daha sonra xz Utils’e girecek kötü amaçlı değişikliklerin tespit edilmesini engelleyen bir değişikliği talep etti
  • 2024 Şubat’ta Tan, xz Utils 5.6.0 ve 5.6.1 commit’lerini yaptı; bu güncelleme arka kapıyı uyguluyordu
  • Ardından Tan veya başkaları, Ubuntu, Red Hat ve Debian geliştiricilerinden ilgili güncellemeyi işletim sistemlerine birleştirmelerini istedi

Dahil edilen dağıtımlar ve çalıştırma koşulları

  • Tenable’a göre arka kapılı sürümler veya ilgili güncellemeler şu sürümlere girdi
    • Fedora Rawhide: Fedora Linux’un geliştirme dağıtımı
    • Fedora 41
    • Debian testing, unstable, experimental: 5.5.1alpha-0.1’den 5.6.1-1’e kadar
    • openSUSE Tumbleweed ve openSUSE MicroOS: 7 Mart ile 28 Mart arasında arka kapılı xz sürümleri içerdi
    • Kali Linux: 26 Mart ile 28 Mart arasında xz-utils 5.6.0-0.2 içerdi
  • Sam James’in analizine göre kötü amaçlı script, build hedefinin amd64/x86_64 olup olmadığını, linux-gnu adını kullanıp kullanmadığını ve GCC ile GNU ld kullanılıp kullanılmadığını kontrol ediyor
  • Ayrıca bunun Debian paket build’i olup olmadığını veya RPM_ARCH’nin x86_64 olup olmadığını da denetliyor
  • Saldırının, amd64 sistemlerde glibc kullanan ve Debian ya da Red Hat türevi dağıtımlar build eden ortamları hedeflediği anlaşılıyor
  • Diğer sistemlerin savunmasız olup olmadığı o sırada bilinmiyordu

Uygulama yöntemi ve gizleme teknikleri

  • Sam James, arka kapının birden fazla bileşenden oluştuğunu özetledi
    • upstream tarafından dağıtılan release tarball, GitHub’daki kodla aynı değil
    • release tarball içindeki build-to-host.m4, GitHub upstream’dekinden büyük ölçüde farklı
    • git deposunun tests/ klasöründe manipüle edilmiş test dosyaları var
      • tests/files/bad-3-corrupt_lzma2.xz
      • tests/files/good-large_compressed.lzma
    • build-to-host.m4 tarafından çağrılan script, kötü amaçlı test verisini açıyor ve build sürecini değiştiriyor
    • glibc’nin IFUNC’u, OpenSSH kimlik doğrulama rutinini çalışma zamanında kancalamak veya yeniden yönlendirmek için kullanılıyor
  • HD Moore, nihai arka kapı aşamasının yalnızca amd64 üzerinde kütüphane build edilirken ve Debian ya da RPM paketi oluşturulurken çalıştığını doğruladı
  • Araştırmacıların analizine göre SSH açık anahtar doğrulama sürecinde, belirli bir fingerprint işlevi ve açık anahtar eşleşirse, açık anahtar gerçekten doğrulanmadan önce anahtar içeriği önceden paylaşılan bir anahtarla çözülüyor
  • Çözülen içerik belirli bir biçime uyduğunda doğrudan system’e aktarılıyor
  • Fingerprint eşleşmezse veya çözülen içerik biçime uymazsa normal anahtar doğrulamasına geri dönülüyor; kullanıcıların farkı anlaması zor

Akamai’nin özetlediği yürütme zinciri

  • Akamai araştırmacılarına göre arka kapı, tespitten kaçmak için xz GitHub deposuna değil yalnızca kaynak kodu tarball release’lerine dahil edildi
  • Arka kapı birden fazla commit’e yayılarak oluşturuldu
    • Build sürecinde IFUNC kullanılarak kötü amaçlı kodun sembol çözümleme işlevlerini ele geçirmesi sağlandı
    • Obfuscation uygulanmış bir paylaşımlı nesne test dosyalarının içine gizlendi
    • Kütüphane build sürecinde bu paylaşımlı nesneyi çıkaran bir script çalıştırıldı
    • Süreç yetkilerini sınırlayan bir güvenlik özelliği olan landlocking devre dışı bırakıldı
  • Yürütme zinciri birden fazla aşamadan oluşuyor
    • build-to-host.m4, kütüphane build’i sırasında çalışarak bad-3-corrupt_lzma2.xz dosyasını bir bash script’i olarak decode ediyor
    • Bu bash script’i, good-large_compressed.lzma dosyasını daha karmaşık bir yöntemle decode ederek başka bir script oluşturuyor
    • Bu script, liblzma_la-crc64-fast.o paylaşımlı nesnesini çıkarıyor ve bunu liblzma derleme sürecine ekliyor
  • Bu paylaşımlı nesne liblzma içine derlenerek normal işlev adı çözümleme sürecinin yerini alıyor
  • Kötü amaçlı kütüphane, OpenSSH’nin RSA_public_decrypt işlev işaretçisini kendi oluşturduğu kötü amaçlı işleve çevirebiliyor
  • Filippo Valsorda’nın analizine göre bu kötü amaçlı işlev, kimlik doğrulama istemcisinin sertifikasından komutları çıkarıyor, tehdit aktörü olduğunu doğruluyor ve ardından system() fonksiyonuna vererek kimlik doğrulama öncesi uzaktan kod çalıştırma sağlıyor

Jia Tan ve kalan sorular

  • Jia Tan hakkında bilinenler çok sınırlı
  • Bu geliştirici personası son birkaç yılda düzinelerce başka açık kaynak yazılıma da dahil oldu
  • Jia Tan kullanıcı adının arkasında gerçek bir kişinin mi olduğu, yoksa tamamen kurgulanmış bir figür mü olduğu bilinmiyor
  • Ek teknik analizler Filippo Valsorda’nın Bluesky dizisinde, Kevin Beaumont’un analizinde ve Freund’un cuma günü yayımladığı açıklamalarda görülebilir

CVE ve doğrulama araçları

  • Bu zafiyetin izleme kimliği CVE-2024-3094
  • Binarly’nin xz.fail sayfası IFUNC uygulamasını tespit ediyor ve davranış analizine dayanıyor
    • Benzer bir arka kapı başka bir yere yerleştirilse bile değişmeyen koşulları otomatik olarak tespit edebilir
  • xzbot, analiz ve deney amaçlı işlevler sunuyor
    • honeypot: exploit girişimlerini tespit etmek için sahte savunmasız sunucu
    • ed448 patch: kendi ED448 açık anahtarını kullanacak şekilde liblzma.so yaması
    • backdoor format: arka kapı payload biçimi
    • backdoor demo: ED448 özel anahtarının bilindiği varsayımıyla RCE’yi tetikleyen CLI

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-02
Hacker News yorumları

  • Amaç, standartlaştırılmış bir test framework’ü kullanarak XZ için test yazmayı kolaylaştırmaktı.
    Jia’nın 2022-06-17’de yazdığına göre henüz test edilmemiş çok sayıda özellik vardı; testleri artırmanın projenin uzun vadeli kararlılığına yardımcı olacağını düşünüyordu.
    Yani bu, uzun zamandır hazırlanmakta olan bir değişiklikti.

  • Kütüphanenin RSA_public_decrypt araya girmesini mümkün kılan linkleme mekanizması pek tartışılmamış gibi görünüyor.
    Süreç izolasyonu gibi konular çok konuşuluyor, ama o fonksiyon çağrısının yeniden yönlendirilmesi hakkında daha az şey söyleniyor.
    SSH üzerinden gelen kod gibi temel bileşenleri kütüphanelerle hiyerarşik bir güven modeliyle linkleyip, “çağırdığım konumda güveniyorum ama başka çağrı noktalarına kendiliğinden araya girmesine izin vermiyorum” gibi bir model kurulamaz mı diye düşünüyorum.
    Etrafından dolaşma yolları var diye anlamsız gören “security through obscurity” refleksini tetikleyebilir, ama yine de bunu saldırı yüzeyini küçültme olarak görmek mümkün.

    • Programın alt bileşenlerinin kendi güvenlik bağlamlarına sahip olup birbirlerini mesaj iletimiyle çağırdığı Erlang actor’larına benzer bir model de işe yarayabilir.
      Ancak işletim sisteminde birden fazla güvenlik bağlamı üst üste biner. XZ arka kapısıyla ilgili olarak bu daha çok modül düzeyinde capability tabanlı güvenlik meselesi, ama program düzeyi capability’ler, bellek düzeyi izolasyon (paging), mikro-mimari düzey izolasyon gibi katmanlar da var.
      Bu unsurları birlikte çalıştırıp bir yandan performans almak epey zor; Unix türevlerinin böyle bir modele geçmesi ise süreç kavramının kendisini değiştirmeyi gerektireceği için fiilen imkânsız görünüyor.
    • Bana göre sorun glibc’nin IFUNC kullanımı.
      Bu, XZ testlerini bozdu; ardından birdenbire o testleri devre dışı bırakmak için lobi yapan hesaplar ortaya çıktı ve sonuçta exploit mümkün hale geldi.
    • Özünde bu kod, build zamanında (./configure && make çalıştırılırken) C dosyasını gizlice değiştirerek ifunc resolver’ı patch’liyor ve sağlanan kötü amaçlı nesneyi çağırmasını sağlıyor.
      Bozulmuş nesne dosyası now linker flag’iyle linkleniyor; böylece kütüphane yüklenirken ifunc hemen çözümleniyor ve o anda süreç link tablosu hâlâ yazılabilir durumda olduğu için patch’lenmiş resolver çağrılıyor.
      Kritik nokta da tam burası: kütüphane yüklendiğinde bellekteki RSA_public_decrypt fonksiyonunu doğrudan ele geçirebiliyordu.
      Arka kapı enjeksiyon sürecini çok iyi analiz eden yazı: https://research.swtch.com/xz-script
    • systemd kısa süre önce sıkıştırma kütüphaneleri için dlopen kullanılmasına yönelik değişikliği birleştirdi: https://github.com/systemd/systemd/pull/31550
      Bu anlamda daha güvenli bir linkleme biçimi.
    • ltrace’in çağrılan sembolleri izlemesi yeterli olur mu merak ediyorum.

  • Neden dünyanın “neredeyse” tamamına bulaştırdı deniyor, bilmiyorum.
    En azından oldukça popüler 3 Linux dağıtımı, Arch, Gentoo, openSUSE Tumbleweed, arka kapıyı haftalarca dağıttı ve Tumbleweed’de kesin olarak çalışıyordu.
    Haftalar boyunca arka kapı içeren SSH söz konusuydu; “neredeyse” demek zayıf kalıyor.

    • Bu dağıtımlarda exploit fiilen çalıştırılmadı.
      Yalnızca deb/rpm hedeflerinde çalıştığı için pratikte prodüksiyona ulaşmadan durdurulmuş oldu.
    • Arch ve Gentoo hobi amaçlı dağıtımlar arasında oldukça popüler, ancak bu saldırının hedeflediği SSH sunucuları gibi profesyonel operasyon ortamlarında çok daha az yaygınlar.
      Bu, sorun olmadığı anlamına gelmiyor; eğer bu RHEL ya da Debian/Ubuntu stable’a girecek kadar uzun süre fark edilmemiş olsaydı, bankalar veya sağlık kurumları gibi yerlerden bildirimler alıyor olurduk.
      Kimlik doğrulama öncesi uzaktan kod çalıştırma söz konusuysa, ağı sıkı biçimde kısıtlamayan ve iyi akış loglamasına sahip olmayan yerler için “etkilenmedik” demek zor olurdu.
    • Arch ikili paketlerine gerçekte dahil edilmemiş gibi görünüyor; bunun nedeni, arka kapının build sisteminin Arch için arka kapıyı eklememiş olması.
      xz-5.6.1-1 ile xz-5.6.1-2 içindeki liblzma.so.5.6.1 dosyaları cmp -l ile karşılaştırıldığında yalnızca çok küçük farklar var.
      Tavsiye metni yazılmadan önce bunun bilinmediği anlaşılıyor.
      https://github.com/QubesOS/qubes-issues/issues/9067#issuecom...
    • sshd çalıştıran Linux makinelerin çoğunun rolling release değil, LTS dağıtımlar kullanacağını düşünüyorum.
      Yine de bunu destekleyecek verinin nasıl elde edileceğini bilmiyorum.
    • Umarım açık kaynak bakımcıları ve büyük şirketler mesajı alır. Açık kaynak bakımının finansal görünümünü değiştirmek gerekiyor.

  • Önümüzdeki 12 ay içinde benzer bir şeyin gerçek ortamlarda bulunacağına 101 dolar yatırırım.
    Çünkü bakımcılar birbirlerinin eski commit’lerinden şüphelenip incelemeye başlayacak.

    • Bence bu tür saldırılar son 10 yılda arttı.
      Önemli ama pek bilinmeyen ve çok az bakımcısı olan codebase’lere bakmak yeterli.
    • Halihazırda çalıştırılmış ve kullanılmış örnekleri bulup bulamayacağımızı merak ediyorum.
      Ben böyle bir şeye sahip olsaydım ve iyi çalışsaydı, daha sonra başka bir hesapla bunu “keşfedip” düzelttirirdim.

  • Bu olaydan çıkardığım kişisel sonuçlar birkaç tane
    Birincisi, kaynak deposundan farklı kod içeren kaynak dağıtım tarball’ları iyi değil; bunlardan uzaklaşmak gerekiyor. Bir başka büyük tedarik zinciri saldırısı olan event-stream de benzer bir noktadan yararlanmıştı
    Bunun sonucu olarak otomatik üretilen çıktılar her zaman commit edilmelidir
    İkincisi, kod incelemesinde herkesin Page Down ile geçip gittiği otomatik üretilen çıktılar sorunlu. Böyle dosyalar depoda varsa, birinin bunlarla oynayıp oynamadığını kontrol eden otomatik testler de olmalı; bu aynı zamanda eski otomatik üretilmiş dosyaların bırakılıp unutulmasını da önler
    Üçüncüsü, 1 ve 2’nin sonucu olarak autotools kötü, autotools kültürü de kötü
    Dördüncüsü, Libsystemd ekosistem için bir sorun. Bunu söyleyince systemd düşmanı diye yaftalanıyorsunuz ama büyük, karmaşık, çok bağımlılığı var ve çoğu program bunun yalnızca çok küçük bir kısmını kullanıyor. Her servisin başlatma bildirimi için buna bağımlı olmasını teşvik etmek delilik
    Beşincisi, kod yeniden kullanımının her zaman iyi olduğu ve küçük bir özellik için büyük bir kütüphaneye bağımlı olmanın sorun olmadığı yönünde bir kültür var; bu doğru değil. Bağımlılıklar bakım yükü ve güvenlik riskidir; getirdikleri işlevlerle tartılmaları gerekir
    Altıncısı, dağıtım bakımcılarının paketlere büyük yamalar uygulaması da bir sorun. Asıl bakımcıların bakmadığı kütüphane ve uygulamaların yaygın kullanılan fiilî fork’ları ortaya çıkıyor
    Yedincisi, geliştirici açısından OSS’nin finansal olarak sürdürülebilir hale gelmesi gerekiyor. Liblzma ve xz-utils’in on milyonlarca kurulumu olmalı; buna rağmen ruh sağlığı sorunları yaşayan tek bir bakımcıya dayanıyordu
    Sekizincisi, söylemek istemiyorum ama artık kod incelemesi ve bakım yetkisinin devrinde jeopolitik değerlendirmeler de yapmak gerekiyor

    • Jeopolitik değerlendirmeler işe yaramaz
      Jia Tan’ın gerçek adı olduğuna dair kanıt yok; gerçek bir kişi olduğuna dair bile kanıt yok
      Projeler Asyalı gibi duyulan isimlerden katkı almamaya başlarsa, bir sonraki saldırıda Richard Jones adını kullanmaları yeterli olur
    • Libsystemd konusunda tamamen katılıyorum
      BSD dünyasından gelince systemd şok edici; canavar gibi ve dokunaçlarını her yere uzatıyor
    • Buna ek olarak kişisel bir gözlemim var
      Tüketiciler saf ama yazılım sektörünün kendisi de güvenlik tehditleri konusunda saf
      Sosyal exploit’ler, kod exploit’lerinin bir parçasıdır
      FOSS’un “koda bakan göz ne kadar çoksa o kadar iyi” ilkesi doğru, ama yalnızca o gözler eğitimli gözlerse işler. FOSS’un sektörün maddi desteğine ihtiyacı var
      Bu exploit’i bir MSFT mühendisi yakaladı, ama yine de Fedora 41, openSUSE ve Kali’nin genel herkese açık sürümlerine girmişti
      Geliştirme araç zinciri ve test süreçleri hiçbir zaman güvenliği test etmek üzere tasarlanmadı. SolarWinds de bakmaya değer: https://www.wired.com/story/the-untold-story-of-solarwinds-t...
    • tarball dağıtımını durdurma önerisi, sürüm çıktılarının neden var olduğunu tamamen göz ardı ediyor
      Sürüm çıktılarında yalnızca autoconf betikleri bulunmaz
      Bir sürüm arşivine ikili blob koymanın birçok nedeni vardır. Oyun kaynakları, firmware imajları, test vakaları vb. mpv’nin, özel mülk bir encoder ile üretilmiş bazı medya dosyalarını test vakası olarak dahil ettiğinden de söz edilmişti; bu kötü değil, iyi bir şey
      İyi bakımı yapılan sqlite her yerde kullanılıyor ve harika bir test paketi de var. Her sürümde bir değil, derleme aşamalarına göre iki tarball yayımlıyor. Bunu durdurmak kolay olurdu ama yalnızca paket bakımcılarının işini artırır, güvenliği iyileştirmez
      Debian’ın seçilmiş tarball’dan derleme yapmasının nedeni, bunların insanlar tarafından seçilip iyi bilinen anahtarlarla imzalanmasıdır. Elbette git’ten de derlenebilir ama bunun durumu iyileştirip iyileştirmeyeceği belirsiz. Her proje sürüm etiketlerini imzalamıyor; imzalasa bile bunun daha büyük olasılıkla otomatikleştirilmiş olması mümkün
      Değişikliklerin önce upstream bakımcı tarafından, sonra paket bakımcısı tarafından incelenmesini istiyoruz ve bu iki tarafın birbirinden bağımsız olmasını tercih ediyoruz
      Bu kez yozlaşmış bir upstream bakımcı bu sürece saldırdı, ama bu upstream bakımcıları ortadan kaldırmamız gerektiği anlamına gelmez. Son birkaç yılda bu yapı sayesinde birden fazla backdoor girişimi engellendi; dikkatli inceleme yapmadan çöpe atılacak bir süreç değil
      Sürekli söylediğimiz iyileştirme yönü aynı. Yeniden üretilebilir derlemeler için daha çok çaba göstermeli, mümkün olduğunda saldırı yüzeyini ve derleme karmaşıklığını azaltmalı, bakımcılara güvenmeli ama işi doğrulamalıyız
    • systemd bakımcıları hiçbir zaman her servisin libsystemd’ye bağımlı olmasını teşvik etmedi
      Aksine bu noktada kafa karışıklığı yaşadılar ve libsystemd olmadan basit datagramların nasıl uygulanacağına dair dokümantasyon ekliyorlar
      liblzma ve xz-utils’in kurulum sayısı on milyonlardan çok daha fazla olmalı. Python, PHP, Ruby gibi birçok dil libxml2’ye bağımlı; libxml2 de liblzma kullanıyor. Başka bağımlılıklar da çok
      Jeopolitik değerlendirmeler bakımcının işi değil. OSS hiçbir garanti olmadan sunulur
      Üstelik “Jia Tan”ın tamamen sahte olma ihtimali var. Commit zaman damgalarına bakınca, aynı gün içinde bile zaman dilimi Doğu Avrupa’dan Asya’ya değişiyor. En azından bir kimlik oyunu oynandığı kesin

  • Bu sorunu keşfeden kişinin Azure Postgres’te çalışan bir Microsoft mühendisi olduğunu bilmiyordum
    Teşekkürler Microsoft, artık Azure’u sevmeye başladım

    • Artık insanlar Valgrind anomalilerinin hepsine bakmaları gerektiğini düşünüyor
      Çünkü bu sorun böyle keşfedildi
      Ardından sorunlu kütüphaneye bakıp, sahte bir persona’nın projeyi ele geçirdiği benzer aykırı durumları aramak gerekiyor
      Bu tür hataları görmezden gelmek yaygın bir uygulama gibi görünüyor
    • O kişi Microsoft’un işe aldığı bir PostgreSQL PGDG mühendisi
      Bu tarz paketlemeye gerçekten katlanamıyorum

  • xz’nin asıl bakımcısı, Jia Tan’ı bizzat görmeden ya da en azından onunla telefonda bile konuşmadan sorumluluğu devretmiş gibi görünüyor
    Yalnızca e-posta veya GitHub üzerinden iletişim kurmanın yaygın bir şey olup olmadığını merak ediyorum
    Bu olaydan sonra bazı açık kaynak proje bakımcıları daha dikkatli davranacak gibi

    • Yalnızca e-posta/GitHub üzerinden iletişim kurmak tamamen yaygın
      Ben de gerçek kişinin kim olduğunu hiç bilmeden, sadece metinle iletişim kurarak kütüphane bakımını devraldım veya devrettim
      Ama bu olaydan “bakımcıların daha dikkatli olması gerekir” sonucunu çıkarmanın tamamen yanlış olduğunu düşünüyorum
      İnsanların kendi projelerine neyi dahil ettiklerinin sorumluluğu bakımcıda değil, o projede çalışan kişilerde
      Ya bakımcıya güvenirsiniz ya da güvenmezsiniz; bir kütüphaneye bağımlı olmaya başladığınız anda kime güvendiğinizi sürekli güncelleyeceğinizi zımnen kabul etmiş olursunuz
    • Mevcut yapı fiilen böyle
      Milyonlarca şirket, ücretsiz çalışan açık kaynak geliştiricilerinin emeğinden bedavaya yararlanıyor
      Bu yüzden onların ayrılması ve sorun çıkması şaşırtıcı değil
    • Bir telefon görüşmesi ne fark yaratırdı, merak ediyorum
      O kişinin niyetleri hakkında nasıl ek bir güven sağlayacaktı?
    • E-posta/GitHub üzerinden iletişim kurulduğu doğru
      GitHub’da 100 yıldızdan 30 bin yıldıza kadar farklı ölçeklerde yaklaşık altı açık kaynak projeye katıldım; kimseyle telefonda konuşmadım ve metin tabanlı iletişim standarttı
    • Birden fazla kişi çalışma hızı konusunda baskı yaparsa, bakımcının sorunun kendisi olduğunu düşünüp projeyi o sırada en iyi seçenek olduğunu düşündüğü kişiye devretmesi garip olmaz
      Ama birini şahsen tanımak da sorunu mutlaka çözmez
      Uzun zaman önce anonim olarak bir açık kaynak projesinde çalışmıştım; burada adını vermek istemiyorum. Baş programcının, onu oldukça iyi tanıyor gibi görünen bir ortak bakımcısı vardı
      Bu ortak bakımcı beni ve daha sonra gelen diğer bakımcıları sürekli gaslighting’e maruz bıraktı, küçümsedi ve çok küçük hatalar yüzünden suçlayarak ayrılmalarına neden oldu. Hakaretleri bir kenara bırakırsanız, eğitici nitelikteki Linus Torvalds tarzı azarlamalardan da farklıydı
      Baş bakımcı, iddianın teknik özüne katıldığı için onu cesaretlendirdi
      Birkaç yıl sonra bu ortak bakımcı projeyi düşmanca ele geçirmeye çalıştı ve işler beklendiği gibi gitmedi. Kısa süre sonra çeşitli özel yazışmalar yayımlandı; bunlar, onun en başından beri bunu istediğini ve diğer bakımcıları gaslighting’e maruz bırakmasının da bu hedefin bir parçası olduğunu ortaya koydu
      İki kişi birbirini tanımasına rağmen bunlar yaşandı

  • Herkes bu backdoor’un erken yakalandığını düşünüyor, ama belki de amacına çoktan ulaşmış olabilir
    Özellikle hedef Kali veya Debian gibi rolling release dağıtımlar kullanan bir geliştiriciyse bu mümkün

  • “Lasse Collin xz Utils’i yeterince sık ya da hızlı güncellemiyordu” şeklindeki meme hataydı

  • SSH’nin neden xz kullandığını bilmiyorum
    Kullanması mı gerekiyor? Gerçekten bu kadar önemli mi?

    • OpenSSH xz kullanmıyor
      OpenSSH, başlatma bildirimi sağlamak için libsystemd’yi içeri çekti; libsystemd de liblzma’yı içeri çekti. Normalde liblzma’nın kodu OpenSSH’nin içine girmez
      Ancak libsystemd’nin bağımlılığı olarak derlendiği için, derleme betiği libsystemd ve OpenSSH ile aynı ortamda çalışır
      Saldırı yükü, liblzma test dizininde sıkıştırma test vakası gibi gizlenmiş, obfuscate edilmiş bir ikili blob olarak saklanmıştı
      lzma’yı git kaynağından derleyip autotools ile derleme betikleri üretildiğinde şüpheli bir şey yoktu. Ancak dağıtım paketleyicilerinin kullandığı kaynak tarball’larında autotools zaten çalıştırılmıştı ve saldırgan otomatik üretilen, okunması zor betik çıktısını değiştirmişti
      Bu betik, liblzma’nın OpenSSH ile aynı ortamda derlenip derlenmediğini ve .deb veya .rpm paketine girecek şekilde derlenip derlenmediğini kontrol ediyordu; ikisi de doğruysa saldırı yükünü OpenSSH’ye yerleştiriyordu
      Daha sonra payload, OpenSSH’nin init betiğiyle normal şekilde mi başlatıldığını yoksa elle mi çalıştırıldığını, yaygın hata ayıklama araçlarının bulunup bulunmadığını ve benzeri birçok kontrol yapıyor; hata ayıklama aracı olmadan “doğal” bir önyükleme gibi göründüğünde ancak çalışan sürece bağlanıyordu
      Çalışırken özel anahtar doğrulamasına hook takıyor ve doğru özel anahtar oturum açmayı denerse gelen paketin geri kalanını system ile çağırarak root yetkili uzaktan kod çalıştırma sağlıyordu
    • OpenSSH xz kullanmıyor, ancak bazı dağıtımlarda systemd ile entegre çalışırken xz kullanılıyor