Açık kaynak projelerindeki etkileşimlerin bir mikrokozmosu olan xz arka kapı olayı

• xz/liblzma açığına dair çok sayıda analiz var, ancak çoğu saldırının ilk aşamasını atlama eğiliminde.
  • Asıl bakımcı tükenmiş durumdaydı ve yardım teklif eden tek kişi saldırgandı (bu nedenle saldırgan, asıl bakımcının zaman içinde biriktirdiği güveni devraldı).
• E-posta ileti dizisi arşivleri, bu 0. aşamanın yaşandığı andaki durumu yakalıyor.

Bakımcının tükenmişliği ve saldırganın ortaya çıkışı

• Bakımcıya makul görünen bir talep iletiliyor.

  • "XZ for Java hâlâ bakılıyor mu? Bir hafta önce soru sormuştum ama yanıt gelmedi."

• Bu soru, bakımcıyı "başarısız" olduğunu kabul etmeye itiyor.
  • Gerçekte bakımcının kimseye borcu yok ve başarısız da olmuş değil, ama öyle hissettiriyor.
  • Çünkü "topluluğu" hayal kırıklığına uğratmak korkunç bir şey.
• Bakımcı, kendisinin "geride kaldığını" kabul ediyor ve yardım istediğini düşündüren bir sinyal veriyor.
• Ancak o ileti dizisinde yardım gelmiyor; bunun yerine xz/liblzma saldırganı, kendisini yardım eden kişi olarak tanıtıyor.

  • "Jia Tan (bu saldırgan) bana yardım etti ve... ileride daha büyük bir rol alabilir... kaynaklarım çok kısıtlı olduğu için uzun vadede bir şeylerin değişmesi gerektiği açık."

• Bakımcı, kaynaklarının sınırlı olduğunu ve uzun vadede bir şeylerin değişmesi gerektiğini söylüyor.

İş birliğine yanaşmayan tüketicinin ortaya çıkışı

• İş birliğine yanaşmayan bir tüketici, bakımcıya eleştirel sözler söylüyor.

  • "Yeni bir bakımcı gelene kadar ilerleme olmayacak gibi görünüyor. ... Mevcut yönetici ilgisini kaybetmiş ya da artık bakımla ilgilenmiyor. Böyle depolar görmek üzücü."

• Bakımcı, ilgisini kaybetmediğini; ancak ruh sağlığı sorunları gibi nedenlerle bakım kapasitesinin sınırlı olduğunu savunuyor.
• Ayrıca bunun ücret ödenmeyen bir hobi projesi olduğunu da hatırlatıyor.

Taleplerin artması

• Bir hafta sonra, iş birliğine yanaşmayan tüketici yeniden ortaya çıkıp bakımcıyı suçluyor.

  • "Bu posta listesinde yavaş yavaş çürüyen sayısız yamayı görmezden geliyorsunuz."

  • "Ruh sağlığı sorunlarınız için üzgünüm, ancak kişinin kendi sınırlarını bilmesi önemli. Bunun tüm katkıcılar için bir hobi projesi olduğunu biliyorum ama topluluk daha fazlasını istiyor."

• Bu talepte bulunan kişi bazı öneriler sunsa da, fiilen yardım etmeyi teklif etmiyor.

  • "XZ for C üzerindeki bakım yetkisini devredip XZ for Java'ya daha fazla odaklanmanız nasıl olur? Ya da XZ for Java'yı başka birine devredip XZ for C'ye odaklansanız? İkisini birden sürdürmeye çalışırsanız ikisi de iyi bakılmayabilir."

• Bakımcı, yeni bir ortak bakımcı bulmanın veya projeyi tamamen devretmenin kolay olmadığını açıklıyor.

Açık kaynak projelerinin gerçeği

• Yazılım geliştiricileri istenildiği zaman takılıp çıkarılabilen dişliler değildir.
• E-posta ileti dizisi, şikâyet eden tüketicinin yardım sunmadan taleplerini sürdürmesiyle sona eriyor ve geriye sadece saldırgan kalıyor.

  • "Jia Tan ileride projede daha büyük bir rol üstlenebilir. Liste dışında çok yardım ediyor ve fiilen zaten ortak yönetici gibi. :-)"

• Bu e-posta ileti dizisi, açık kaynak projelerindeki etkileşimlerin bir mikrokozmosunu gösteriyor.
• Tüketiciler bakımcılara talepler yöneltiyor, bakımcılar ise buna stres ve tükenmişlikle farklı biçimlerde tepki veriyor.
• Bu işleyişin değişmesi gerekiyor.

[GN⁺]

Hacker News görüşleri

• Bir görüşe göre, geliştiriciler kullanıcılara nazik olmaya çalışırken ve yorum yapanların iyi niyetini görmeye uğraşırken çok fazla zihinsel enerji harcıyor. Bu tür görüşler çoğunlukla eğlence için yürütülen yan projelerde (emülatörler, oyun remake'leri vb.) ortaya çıkıyor. Bu projeler, bağış veya telif hakkı sorunlarından kaçınmak için bağışlardan söz etmekten özellikle kaçınıyor. Projelere ilgi yüksek olsa da, gerçekten katkı sunabilecek nitelikli ilgi son derece sınırlı. Kullanıcıların konuşmasına izin veriliyor ve bu teşvik ediliyor, ancak bu konuşmalar bazen geliştiricilerin motivasyonunu düşüren "öneri" ya da "talep" olarak algılanabiliyor. Topluluğu canlı tutmak önemli, ancak doğrudan katkı sunmayan insanları dışlamama konusunda da kaygılar var.

• Sorunun ilk adımı, açık kaynak proje geliştiricisinin saldırganların depoyu daha fazla kontrol etmesine izin vermesi için baskı gördüğü bir sosyal mühendislik saldırısıydı.

• Güvenlik odaklı bir açık kaynak kütüphanesinin bakımını yapan biri olarak, her PR okuduğumda "bu kişi gerçekten yardım mı etmeye çalışıyor, yoksa beni kullanmaya mı çalışıyor" şüphesi ağır basıyor. Tek çözümün geliştirme hızını yavaşlatmak olduğunu düşünüyorum, ama bunun hissettirdiği şey de makalede anlatılanla aynı. Güvenilir uzmanlardan oluşan bir topluluktan yardım isteyebileceğim basit bir yöntem olsa her zaman memnuniyetle kullanırım.

• Kripto para, yapay zeka ve bu olayda olduğu gibi, en büyük sorun eninde sonunda güven sorununa çıkıyor. Kripto para güven sorununu kodla çözmeye çalışıyor, LLM'ler güven kazanmak için gösterişle kandırmaya uğraşıyor ve saldırganlar da güveni aklamada bir miktar başarılı oluyor. En önemli teknologlar güven meselesini yeterince doğru ele alamıyor. Bu durumda, yorgun ve ücretsiz çalışan açık kaynak geliştiricilerine anlayış duyuluyor.

• Port knocking yapılandırılmış bir SSH sunucusunun bu backdoor'dan güvende olup olmayacağına dair bir soru var. RCE yalnızca SSH sunucusuna bağlandıktan sonra gerçekleştirilebildiği için, port makul bir TCP/UDP knocking dizisinin arkasına gizlenmişse sorun çıkmayacak gibi görünüyor. Port knocking uygun SSH yapılandırmasının yerine geçmez, ancak SSH açıkları ortaya çıktığında önlem almak veya müdahale için zaman kazandırmak açısından ek bir savunma katmanı olarak faydalı.

• OpenSSH'in Linux'a özgü yamalarıyla ilgili soruna dair bir bağlantı var. Bu yama olmasaydı sorun ortaya çıkmayacaktı. Bu, OpenSSH sorunu değil, Linux sorunu.

• Bir görüşe göre insanlar left-pad olayından sonra bile sert bağımlılıkları ve karmaşıklığı hâlâ yeterince ciddiye almıyor. OpenSSH devasa bir kod duvarı. Karmaşık sistemler, hangi dilde yazılmış olursa olsun, doğaları gereği güvenilmesi zor yapılardır.

• Eğer Çinli bir hacker kötü niyetli bir eylem yapmak istiyorsa neden Çinli bir isim/handle kullansın? Açık kaynak bakımcılarından daha fazla güven kazanmak için İngilizce ya da Avrupalı bir isim kullanmak daha iyi olurdu. Buna karşılık, Çinli olmayan bir hacker kötü niyetli bir eylem yapmak istiyorsa Çinli bir isim kullanması daha anlamlı olurdu (Çin kötüdür vb.).

• Jigar Kumar hesabı sosyal mühendislik saldırısının bir parçası gibi görünüyor ve son derece şüpheli karşılanmalı.

• Yazılım geliştiricileri değiştirilebilir parçalar değildir; bu yüzden topluluklarda yorum yapma veya katılım hakkının sınırlandırılması düşünülüyor. Örneğin GitHub bir "kapı" sistemi getirirse, ilk kapı test paketine sürüm numarası ve test çıktısının hash'ini üreten bir test eklemek olabilir. Kullanıcı bu numarayı profiline eklerse, GitHub onun en azından make test indirip çalıştırdığına güvenebilir. Bu da belli bir düzeyde bağlılık gösterir.