Shellshock Bash güvenlik açığı nasıl bulundu?

Bu hata çok sayıda platformu etkilediğinden, bu güvenlik açığının bulunduğu süreçten bir şeyler öğrenebiliriz: εὕρηκα (eureka) anı mı yoksa bir güvenlik kontrolünün sonucu mu?

Stéphane'nin Shellshock hatasını bulduğunu bildiğimizden ve diğerleri de süreci bildiğinden, hatayı nasıl bulduğu hikayesiyle ilgileneceğiz.

Birkaçını güvence altına almak için hatayı istismarları gözlemleyerek bulamadım, ifşa edilmeden önce sömürüldüğüne inanmak için hiçbir nedenim yok (tabii ki bunu ekleyemiyorum). Ben de bashkoduna bakarak bulamadım .

O zamanlar düşünce trenimi tam olarak hatırladığımı söyleyemem.

Tehlikeli bulduğum bazı yazılımların bazı davranışları (yazılım değil, davranışlar) üzerine az ya da çok yansıma geldi . Sizi düşündüren davranışlar: bu iyi bir fikir gibi gelmiyor .

Bu durumda, adının başlaması şartıyla istemciden onaylanmamış ortam değişkenlerinin geçirilmesine izin veren ssh'nin ortak yapılandırmasını yansıtıyordum LC_. Fikir şu ki, insanlar sshdiğer makinelere girerken kendi dillerini kullanmaya devam edebiliyorlar . UTF-8 özellikle denkleme getirildiğinde (ve birçok uygulama tarafından ne kadar kötü ele alındığını görünce) karmaşık yerelleştirme işleminin ne kadar karmaşık olduğunu düşünmeye başlayana kadar iyi bir fikir.

Temmuz 2014'te, glibc yerelleştirme işleminde bu sshd yapılandırmayla birleştirilmiş bir güvenlik açığı bildirmiştim ve kabuğun diğer iki tehlikeli davranışıbash (kimlik doğrulamalı) saldırganların dosya yükleyebilmeleri ve bashkullanıldıkları takdirde git sunucularına saldırmasına izin vermişti. git unix kullanıcısının giriş kabuğu (CVE-2014-0475).

bashOldukça karmaşık bir kabuk (tüm ihtiyacınız olan sadece çok basit bir komut satırını ayrıştırmak olduğunda) ve yanlış tasarımların çoğunu miras aldığı göz önüne alındığında, ssh üzerinde hizmet sunan kullanıcıların giriş kabuğu olarak kullanmak muhtemelen kötü bir fikir olduğunu düşünüyordum ksh. bashBu bağlamda (ssh'leri yorumlamak için) kullanılmakta olan birkaç problem tespit ForceCommandettiğimden, orada daha fazla potansiyel olup olmadığını merak ediyordum.

AcceptEnv LC_*adı ile başlayan herhangi bir değişkene izin verir LC_ve ben bash ihraç fonksiyonları ( zaman yararlı olsa da tehlikeli bir özellik) adı gibi bir şey olduğunu myfunction()ve orada bakmak ilginç bir şey olup olmadığını merak ortam değişkenleri kullanarak belirsiz bir hatırlama vardı.

Birinin yapabileceği en kötü şeyin LC_something , varolan komut adları olmadığı için gerçekten bir sorun olamayacak denilen bir komutu yeniden tanımlamak olacağı gerekçesiyle reddetmek üzereydim , ancak daha sonra bu ortam değişkenlerini nasıl bash içe aktardığını merak etmeye başladım .

Değişkenler çağrıldıysa ne olur LC_foo;echo test; f()? Bu yüzden daha yakından bakmaya karar verdim.

A:

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

anımsamamın değişkenlerin çağrılmadığı myfunction()ancak myfunction(ve bununla başlayan değer() ) yanlış olduğunu ortaya koydu .

Ve hızlı bir test:

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

Değişken adının sterilize edilmediğinden şüphe duydum ve kod başlangıçta değerlendirildi .

Daha da kötüsü, çok daha kötüsü, değer de sterilize edilmedi:

$ env 'foo=() { :;}; echo test' bash -c :
test

Bu, herhangi bir ortam değişkeninin bir vektör olabileceği anlamına geliyordu .

O zaman sorunun kapsamını anladım, HTTP üzerinden de ( HTTP_xxx/ QUERYSTRING... env vars), posta işleme hizmetleri, daha sonra DHCP (ve muhtemelen uzun bir liste) gibi diğerlerinden de yararlandığını doğruladım ve bildirdim (dikkatlice) .