Şimdilik yeni yazılım kurmamak daha iyi olabilir

• copy.fail sonrasında ek Linux çekirdeği güvenlik açıkları duyuruldu
• Şu anda NPM tedarik zinciri saldırılarının büyük zarar vermesi için uygun bir dönem olduğu değerlendiriliyor
• Dağıtımın sağladığı Linux çekirdeği yamaları için istisna tanınması tavsiye ediliyor
• Bunun dışında yaklaşık bir hafta kadar yeni yazılım kurmayı durdurmak daha iyi olabilir
• Gönderi yayımlandıktan sonra olgular veya durum değişmiş olabilir; bu nedenle yanlış ya da belirsiz görünen kısımlar varsa sonuca varmadan önce iletişime geçilmesi gerektiğine dair bir not eklenmiş

[GN⁺]

Hacker News görüşleri

• Bu, eninde sonunda patlaması kaçınılmaz olan bir kâbustu. Paket sayısı çok fazla ve buna bağlı olarak tedarik zinciri saldırı yüzeyi o kadar büyüdü ki bunun bir gün herkesin başına patlayacağı belliydi
  Ama fazla kullanışlıydı. Uyarmaya ya da zararı azaltmaya çalışanlar, bunu başka türlü yapma deneyimi olmayan kişiler tarafından susturuldu ve "import antigravity" vazgeçilemeyecek kadar kolaydı
  Görünüşe göre artık “bedel ödeme” aşamasına girdik

  • Bir şirkette gerçekten çok muhafazakâr çalışıyorduk. Tüm dış bileşenlerin sürümleri sabitlenirdi, inceleme olmadan güncellenmezdi ve genelde yeterli bir stabilizasyon süresi beklenirdi
    Derleyici, kernel vb. dahil neredeyse her şeyi kaynaktan derliyorduk, build sunucuları/altyapısı internete hiç erişemiyordu ve değişiklikleri içeri alma prosedürleri vardı. İlgili CVE'ler açıklandıkça incelenir, bizi etkileyip etkilemediğine ve nasıl hafifletileceğine ya da ele alınacağına karar verilirdi
    Sonra geçtiğim şirkette build'ler internete erişiyordu ve yeni sürüm çıkar çıkmaz yükseltiliyordu. İnsanlar, en son hata düzeltmelerini aldıkları gerekçesiyle bunu iyi bir pratik sayıyordu ve CVE incelemesini güvenlik ekibi yapıyordu
    Ondan sonraki startup'ta çeşitli pratiklerin karışımı vardı. Çok iyi yanları da vardı ama CVE borcu da büyüktü. Örneğin sunucularda secure boot ve şifreli disk vardı, ayrıca bileşenler arası iletişim güvenliği de oldukça iyi anlaşılmıştı
    Herkes doğru yaptığını düşünüyor. “Sık yükseltme yapan” birini, bunun yeni sorunlar getirme riski taşıdığına ikna etmek neredeyse imkânsız. Sektörün daha iyi bir pratikler setine ihtiyacı var ve kişisel olarak ilk şirketin bağımlılık yönetimi yaklaşımının daha iyi olduğunu düşünüyorum. Genel olarak güvenlik pratikleri oturmuştu ve ürün de gerçekten güvenliydi
  • Pandora'nın kutusunu açmak gibi olacak ama, ya tüm bu bilinmeyen saldırı vektörlerini açığa çıkarmanın net etkisi, dünyadaki istihbarat kurumlarının biriktirdiği açık stokunu boşaltmak olursa?
    Böylece faydalı tüm yazılımlar fuzz testi, özellik testi ve biçimsel doğrulamadan geçmiş hale gelir ve açık arayan herkes yeniden sıfırdan başlamak zorunda kalır
    Elbette bunun için, bu sırada ülkelerin ellerinde kalan araçları en kötü düşmanlarına savurduğu geçiş dönemini atlatabildiğimizi varsaymak gerekir. Ya da en sonunda birbirimizi hayvan kemikleriyle döveriz, kim bilir
  • Yıllardır yetki tabanlı güvenlik modeli istiyorum ve bunu burada da tartışmıştım. Yetki, ilişkili izinleri taşıyan bir nesne işaretçisi gibi; Unix dosya tanıtıcılarına benziyor
    İşletim sistemi düzeyinde, çalışan program shell'den ya da onu başlatan yerden yetki token'ları almalı ve tüm sistem çağrıları ilk argüman olarak bir yetki almalı. Böylece "open path /foo", open(cap, "/foo") olur. Bu yetki sahte bir dosya sistemi, gerçek dosya sisteminin bir dalı, ağ dosya sistemi vb. herhangi bir şey olabilir ve programın hangi sandbox içinde yaşadığını bilmesi gerekmez
    Kütüphane/dil düzeyinde de, npm modülü gibi üçüncü taraf kütüphaneleri alırken import anında ya da çağrı noktasında yetki geçirilmesi gerekir. O kütüphanenin programımın adres alanındaki tüm baytlara okuma/yazma erişimi olmamalı ve bilgisayarımda benmişim gibi her şeyi yapabilmemeli. Asıl soru şu: bu kodun patlama yarıçapı ne kadar? Kullandığım kütüphane kötü amaçlıysa ya da açığı varsa, hasarın boyutu için makul varsayılanlara ihtiyacımız var. lib::add(1, 2) çağrısı bilgisayarımın tamamının kalıcı biçimde ele geçirilmesine yol açmamalı
    SeL4 uzun zamandır hızlı ve verimli işletim sistemi düzeyi yetkiler sunuyor ve bu iyi çalışıyor. Birçok durumda Linux'tan daha hızlı; şeffaf sandboxing, kullanıcı alanı sürücüleri, süreçler arası iletişim ve güvenlik iyileştirmeleri için çok faydalı. Hatta Linux'u SeL4 üzerinde bir süreç olarak çalıştırabilirsiniz. Linux masaüstünün tüm işlevlerine sahip ama SeL4 gibi çalışan bir işletim sistemi istiyorum
    Ne yazık ki, istediğim türde dil düzeyi yetkilere sahip bir programlama dili yok gibi görünüyor. Rust oldukça yakın ama üçüncü taraf crate'lerin herhangi bir unsafe kod çağırmasını engellemenin bir yoluna ihtiyaç var. Buna güvenilmeyen bağımlılıkların çağırdığı unsafe de dahil. Rust'ın eski soundness hatalarının da düzeltilmesi ve yetki tabanlı bir standart kütüphane de gerekli. Global open() / listen() gibi şeyler ortadan kalkmalı; sadece openat() ve işletim sisteminin diğer parçalarına karşılık gelen eşdeğerleri kalmalı
    Eğer LLM'ler gelişmeye devam ederse, birkaç yıl içinde bunu benden önce kimse yapmazsa hepsini LLM'ye yaptırmayı düşünüyorum. Modern masaüstü işletim sistemlerinin güvenliği şaka gibi
  • Çoğu insan esasen ağzına rastgele bir şey atmaz. Mikrobiyal kültür sonucu pozitif gelene kadar bekleyip sonra da reddetmez
    Koddaki hijyen kültürüne de ihtiyacımız var ve bu, çoğu kültürün yiyecek konusunda geliştirdiği normlardan çok da farklı değil. Kaba sezgilerden oluşan bir kombinasyon ama “ıyy” hissi milyarlarca insanın hayatını kurtarıyor
  • Bir yıl önce, mümkünse üçüncü taraf bir şey almak yerine kodu kendin yazmanın daha iyi olabileceği fikrini ortaya atmıştım. O dönemde LLM'lerin boşlukları doldurmasını düşünmek bile sapkınlık gibi görülüyordu
    Şimdi bağımlılık maruziyetimi her zamankinden daha fazla azaltıyorum; özellikle de birkaç yüz satırda yazılabilecek şeylerde. Bu tam anlamıyla bir paradigma değişimi

• “Yazılımı kurmak için bir hafta bekleyin” yaklaşımı işlemez. Daha birkaç ay önce bile büyük bir açık web'i vurdu; bir aydan fazla gizlenip sonra çalıştırılan bir zaman gecikmeli saldırıydı
  Herkes bir hafta beklemeye başlarsa saldırganlar iki hafta bekler. Siber suçluların anında istismar etmesine gerek yok; sonunda istismar etmeleri yeterli. Typosquatting gibi birçok açık türü de bu yaklaşımla değişmez

  • Yazarın kastı, tüm güncellemeleri sürekli ertelemek değil; bu kez çok erken açıklanmış belirli açıklar için düzeltmeler ve yamalar dağıtılana kadar tek seferlik olarak bir hafta bekleyin demek gibi görünüyor. Onun dışındaki kısımda katılıyorum
  • Yazıyı yanlış anlamış gibisin. Öneri, yazılım yayınlandıktan sonra bir hafta bekleyip kurmak değil. Şu andan başlayarak önümüzdeki 7 gün boyunca hiç kurulum yapmayın demek
    Çünkü bu açıklar için yamalar muhtemelen henüz yok ve olsa bile yakında daha korkutucu açıkların bulunma ihtimali yüksek
  • O zaman bir ay ya da iki ay bekleyin. Bekleme süresinin amacı, zaten kurulmuş exploit'lerin çalışmasını durdurmak değil; yeni exploit kurulumundan kaçınmak
  • Popüler paketler daha çok görünürlük taşır. Bir artifact yayınlandığında tüm dünya onu görebilir ve birilerinin sürümler arasındaki farklara bakmasını bekleyebilirsiniz
    Ama hiç gecikme olmazsa henüz kimsenin bakmadığı bir exploite yakalanabilirsiniz
  • “Son birkaç ay” içinde hatırladığım bağımlılık ihlallerinin hepsi saatler içinde değil, dakikalar içinde fark edildi. litellm, axios, bitwarden CLI, Checkmarx Docker image, Pytorch lightning, intercom/intercom-php bunlar arasındaydı
    Üstelik bu ihlallerin keşfi, gerçekten istismar edilip edilmediklerine hiç bağlı değildi. Bu yüzden “herkes bir hafta beklerse saldırgan iki hafta bekler” sözü bana anlamlı gelmiyor

• Başka bir seçenek olarak, güvenliğe YOLO yaklaşımıyla bakmayan FreeBSD gibi bir işletim sistemine geçebilirsiniz
  Güvenlik düzeltmeleri koordinasyonsuz biçimde FreeBSD kernel'ına öylece atılmaz. FreeBSD güvenlik ekibinden geçer ve patch src ağacına girdikten birkaç dakika sonra FreeBSD Update ve 15.0-RELEASE için pkgbase üzerinden binary güncellemeler dağıtılır
  Kabaca Slack'te “patch'i push ettim” mesajının görünmesi birkaç saniye, patch yüklemesi 10–30 saniye, mirror senkronizasyonu da en fazla 1 dakika sürer

  • Buna biraz şüpheyle yaklaşıyorum. Birkaç yıl önce FreeBSD güvenlik ekibine bir açık bildirmiştim; birkaç hafta sonra takip e-postası da attım ama yanıt alamadım
    Adil olmak gerekirse raporum çekirdek bir bileşenle ilgili değildi ve istismarı da kolay değildi ama Debian, OpenBSD, SUSE ve Gentoo hepsi bir hafta içinde patch çıkardı https://www.maxchernoff.ca/p/luatex-vulnerabilities#timeline
    Yine de tekil ve küçük bir raporun ele alınışına bakarak tüm işletim sistemini yargılayalım demiyorum. Çünkü gördüğüm diğer her şey, FreeBSD'nin güvenlik raporlarını epey ciddiye aldığı yönünde. Ama aynı mantık Linux kernel hatalarına da uygulanabilir. Bu tür kötü patch yönetimi Linux'ta da oldukça nadir
  • Güvenlik yüzünden BSD'ye geçilecekse neden FreeBSD? OpenBSD aşırı güvenli olan taraf değil mi? O projelere bakmayalı uzun zaman oldu, o yüzden soruyorum
  • FreeBSD, güvenlik konusunda özellikle varsayılanlar ve yapılandırma açısından oldukça gevşek
    Güvenlikten çok kullanılabilirliği tercih ediyor. Ünlü bir örnek burada: https://vez.mrsk.me/freebsd-defaults
    Projeye katkı sunanları takdir ediyorum ama böyle kötü varsayılanlar varken vicdanen insanlara geçmelerini öneremem
  • FreeBSD'de 2019'a kadar kullanıcı alanı ASLR bile yoktu, diğer hafifletmelerden biri olan kASLR da hâlâ yok. Güvenliğe önem veren biri için ciddi bir işletim sistemi değil
    FreeBSD ve güvenlik istiyorsanız Shawn Webb'in HardenedBSD'sini kullanmanız daha doğru olur
  • Bu tür konuşmalarda mutlaka biri çıkıyor. Sevdiğiniz dağıtımın kesinlikle daha güvenli olması ne güzel. Exploit sayısı tek haneli katlara inse bile geride yine birkaç bin tane kalacak. Ozymandias herhalde Gentoo kullanırdı

• Güvenlik uzmanlarının bile artık dünyamızın son derece kırılgan bir denge üzerinde durduğunu kabul etmesi gerekiyor. İnsanların bunu gerçekten küçümsediğini düşünüyorum
  Sadece IT dünyası değil, bütün dünya çok sayıda çok kırılgan denge üzerine kurulu. Güvenlik exploit'leri her zaman var olacak. Bu sadece yazılımda değil, gerçek dünyada da böyle. Birileri bir güvenlik konferansına gizlice sızmıştı ve bu kişi sadece bir YouTuber'dı. Elbette ultra güvenlikli bir etkinlik değildi ama aklıma gelen örnek buydu. Temel olarak çoğu durumda güvenliği aşmak gerçekten çok kolay
  Demek istediğim şu: dünyamız temelde, en azından insanların çoğu suistimal etmediği için işliyor. İnsan toplumu hep böyle işledi ve muhtemelen böyle işlemeye devam edecek

  • Birleşik Krallık influencer'ları arasında, “merdiven ve fosforlu yelek” yöntemiyle mekânlara girip fiziksel güvenliğin ne kadar zayıf olduğunu gösteren bir akım olduğunu hatırlıyorum https://www.youtube.com/watch?v=LTI0SeyhAPA
    Bildiğim kadarıyla YouTuber Max Fosh art arda International Security Expo'ya girmişti. Birleşik Krallık'ta https://www.youtube.com/watch?v=qM3imMiERdU, ABD'de ise https://www.youtube.com/watch?v=NmgLwxK8TvA videolarında sırasıyla “Rob Banks” ve “Nick Everything” takma adlarını kullanmıştı
    Güvenlik kültürü üzerine biraz çalışmıştım; çoğu şey sonuçta bir tarafta güvenlik, diğer tarafta kolaylık/erişilebilirlik olan bir kayan ölçeke çıkıyor. Daha güvenliyse daha az erişilebilir oluyor, tersi de geçerli

• npm, PyPI, Cargo gibi bağımlılık yöneticilerine yönelik tedarik zinciri saldırıları için zaten makul bir çözüm var. Paket sürümünün birkaç günden eski olması şartını koymak
  Son dönemdeki büyük saldırıların hepsi bir gün içinde fark edilip geri alındı, dolayısıyla böyle yapılandırılmış olsaydı güvenle kaçınılabilirdi. Bu davranış varsayılan olmalı. Kendi isteğiyle beta test yapanlar ve güvenlik tarama şirketleri en güncel paket sürümlerini bir gün kadar önce kullansın yeter. Yöntem burada: https://cooldowns.dev/

  • 3 ay önce Show HN'de çıkan şu araç daha uygun görünüyor: https://github.com/artifact-keeper
    Bu bir artifact yöneticisi. Yalnızca onayladığınız şeyleri çekmenizi sağlıyor. Gerektiğinde hızlı güncelleme yapabiliyor, gerektiğinde de tutarlı biçimde doğrulanmış kararlı sürümleri kullanabiliyorsunuz. Biraz yapılandırma geçersiz kılma gerektiriyor ama kolay bir iş
    Benzer amaçlı biraz dağınık bir aracı kendim yazıp kullanmıştım; bu iyi bir proje
  • Daha iyi yöntem, şirketin doğruladığı depoları kullanmak ve kimsenin internet depolarından doğrudan kurulum yapamamasını sağlamak
    Elbette şirket dışı kullanımda bu doğal olarak pek işe yaramıyor
  • O zaman güvenlik güncellemelerini de geç almıyor musunuz? Birçok açık, keşfedilip patch'lenene kadar yıllarca gerçek sistemlerde bulunuyor
    Bir kez fark edildiğinde hemen exploit patlaması yaşanıyor ve gecikmeli güncellemeler heyecanlanmış saldırganlara daha fazla zaman veriyor
  • Bana göre en sürdürülebilir model Linux dağıtımı/BSD ports/Homebrew modeli. Yeni bir kütüphaneyi doğrudan herkese açık registry'ye itmek yerine, her yeni değişiklik için gözden geçirilen bir paketleme script'i yazılması
    Bir diğer model de yalnızca kaynak dosyaları dağıtan Perl'ün CPAN'i

• Sürekli entegrasyon ve container'laştırılmış build'leri nispeten yakın zamanda devreye alanlar, her build'de birden fazla paketten latest çekip çekmediklerini sistemlerinde kontrol etmeli
  Biz tüm dış bağımlılıkları içeren bir temel container oluşturuyoruz ve yalnızca güncelleme zamanı geldiğine karar verdiğimizde bunu açıkça yeniliyoruz
  Böylece en güncelin biraz gerisinde kalabiliyoruz ama rastgele bir tedarik zinciri açığının anında tüm dünyaya dağıtılması riskini çok daha az üstleniyoruz

  • Bunun CI build süresini ve dengesiz başarısızlıkları da ciddi biçimde azalttığını göreceksiniz
  • Ayrıca, yalnızca dahili repository kullanmak iyi olur

• Aktif biçimde zararlı bir görüş yazısı. Mantığını anlamak zor
  copyfail ve dirtyfrag açıklarının gerçekte ne kadar eski olduğunu kontrol etmek 45 saniye sürer. Yazıyı okumaktan daha uzun ama yine de kısa. Dirtyfrag, 2017'ye kadar giden sistemleri etkiliyor olabilir
  Etkilenen şey “yeni” yazılım değil. Ve gerçekten eski yazılımlar, sorun bulmak için çok daha fazla zaman olduğu için aslında daha kötü durumda

  • Orijinal gönderi, şu anda bir tedarik zinciri saldırısı olursa kötü olabileceğini; bu yüzden NPM paketi kurmayarak/güncellemeyerek bu riski azaltmayı öneriyor

• Günün birinde biri, işletim sisteminden uygulamalara kadar tüm stacki proof-carrying code yükseltmeleriyle yeniden kuracak
  Güvenilir kod çalıştırmanın tek yolu, ispat ile kodun birlikte tasarlanması ve birlikte inşa edilmesidir

• Bu sadece yazılıma değil, aslında neredeyse her şeye uygulanır
  Bunu nerede okuduğumu hatırlamıyorum ama sonuçta ihtiyaç ile istek arasındaki farka dayanıyor
  Yeni araba mı ikinci el araba mı alınacağına, üst düzey süpürge mi temel model mi seçileceğine karar verirken bu kuralı kullandım. Parlak yeni cihazlar, teknoloji yığınına yeni bir şey eklemek ya da yeni bir teknoloji yığını seçmek için de aynısı geçerli

• copyfail'in ne olduğunu ve NPM paketleriyle nasıl bağlantılı olduğunu anlamama yardım edebilir misiniz?
  Toparlayabildiğim kadarıyla copyfail, kötü amaçlı bir npm paketinin Linux sunucuda root yetkisi elde etmesini sağlayan bir kernel bug gibi görünüyor
  Yani henüz patch'lenmemiş sunucular varken, saldırganların NPM paketlerini hedeflemesi için mükemmel zaman bu mu demek?
  Tavsiyenin sadece “kernel'i güncelleyin” olmamasının sebebi, ilgili yeni sorunların hâlâ ortaya çıkıyor olması mı?

  • En yeni açıklar için patch'ler henüz çıkmadı bile. Bu yüzden şu anda yeni bir tedarik zinciri saldırısı olursa, neredeyse tüm sistemlerde root elde etmek mümkün olacağı için zamanlama gerçekten çok kötü
  • NPM tedarik zinciri saldırıları gerçekten çok hızlı yayılır
    Popüler bir NPM paketi ele geçirilip içine copy.fail exploit'i konursa, birçok sistem root yetki yükseltmesine açık hale gelir
  • Tavsiyenin “kernel'i güncelleyin” olmamasının nedeni, güncelleme olmaması. copy.fail'den sonra keşfedilen en son açıklar için hâlâ düzeltme yok