Bash Güvenlik Açığı: ShellShock - lookjapan.COM

miSy · 08 Eylül 2015, 12:57

ShellShock nedir?

Linux, MacOSX vb. sistemlerde komutlar kabuk denilen programlar aracılığıyla işletilmektedir. Sıkca kullanılan kabuklardan biri de Bash’tir.
Geçtiğimiz hafta Bash kabuğunda bir güvenlik açığı fark edildi. Bu açık, Bash’in yorumladığı betik programlama dilinde tanımlanan fonksiyonların alt süreçlere aktarımı sırasında, özel bir şekilde düzenlenmiş fonksiyonların içine yazılan komutların işletilebilmesine neden olmaktadır. Örneğin, Bash kabuğuna aşağıdaki komutu verelim:
$ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"Bu komutla sadece iki işlem yapılıyor olması gerekiyor:
* “x” fonksiyon tanımı yapılıyor.
* Bash altında “echo test” komutu çalıştırılıyor.
Bu işlemin sonucunda normalde ekrana sadece “test” yazılması, x fonksiyonunda tanımlanan işlemlerin çalıştırılmaması gerekiyor. Ancak açığı içeren bir sistemde yukarıdaki komut çalıştırıldığında ekrana hem “vulnurable” hem de “test” yazılıyor.
Bu sorunun yaklaşık 22 senedir olduğuna dair yorumlar bulunuyor. Bu nedenle, kıyasla daha yenice geliştirilen diğer kabuk yazılımlarında da benzer bir açık çıkması olasılığı bulunuyor. Bu konuda araştırmalar devam ediyor.

Olası riskler nelerdir?

Çoğu sunucu yazılımı çalıştıracakları harici süreçleri kendi kabuk ortamları içinde çalıştırırlar. Bu da, ortam değişkenleri kullanılarak ShellShock açığını tetikleyebilecek komutların çalıştırılabilmesi riskini doğurmaktadır.
Örneğin, pek çok web uygulaması web sunucuların harici bir yorumlayıcı çağırması yöntemiyle çalıştırılmaktadır. Bunun için kullanılan CGI mekanizmaları, HTTP protokolü ve web isteğinde iletilen parametreler gibi bazı bilgileri yorumlayıcıya iletmek için ortam değişkenlerini kullanır. Bu nedenle, HTTP başlık bilgilerine ShellShock açığını kullanan komutlar eklenmesi halinde, saldırganların istedikleri komutları işletmesi riski bulunuyor.
Bu sorun sadece web sunuculara özel bir sorun değil. Birçok sunucu yazılımı benzer yöntemler kullanmakta ve ShellShock saldırıları için ortam sağlamaktadır. Zaten ShellShock açığının bu kadar önemsenmesi ve gündem haline gelmesindeki nedenlerden biri de açığın boyutlarının tam olarak belirlenememesi olmuştur. Örneğin, bir başka saldırı vektörü olarak, kullanıcıları belli bir alana kısıtlayacak şekilde ayarlanmış kabuklarda (Jail) bu kısıtlamaların etrafından dolaşılma ihtimali yarattığı düşünülmektedir. Git sunucusu, kısıtlı ssh erişimi vb. sistemlerin birer saldırı vektörü olma ihtimali olduğu da düşünülüyor.
Sorunun başka nasıl kötü amaçlar için kullanılabileceği halen incelenmeye ve gerekli önlemler alınmaya çalışılıyor.

Alınan önlemler neler?

Bu sorun ilk fark edildiğinde ilgili yerlerde ambargo süreci işletilerek yönetildi. Dağıtıcılar (vendor) sorundan ve düzeltmelerinden belli bir zaman önce haberdar edildi ve sorunun herkese açıklanması için TSİ salı günü 17:00 ambargo bitimi olarak belirlendi. Ambargo bitiminden önce dağıtımların güncelleme için gerekli çalışmaları tamamlamış olmaları ve ambargo bittikten sonra düzeltmeleri yayınlamaları gerekiyor.
Redhat tabanlı sistemler, Suse/OpenSuse ambargo biter bitmez düzeltme paketlerini yayınladılar, ve hemen 1-2 saat içerisinde yansılara düzeltmeler dağıldı. Mandrake ve Slackware 1 gün gecikmeli olarak düzeltme paketlerini (güncellemeleri) yayınladı. Ubuntu ve Debian sadece son sürümler ve LTS sürümler için düzeltme yayınlayacaklarını açıkladılar. Örneğin, Ubuntu 13.x sürümlerinde bu sorun düzeltilmeyecek.

08 Eylül 2015, 12:57	#1
miSy Üyelik tarihi: 01 Eylül 2015 Mesajlar: 33 WEB Sitesi: # IRC Sunucusu: # İlgi Alanı: Alınan Beğeni: 3	Bash Güvenlik Açığı: ShellShock ShellShock nedir? Linux, MacOSX vb. sistemlerde komutlar kabuk denilen programlar aracılığıyla işletilmektedir. Sıkca kullanılan kabuklardan biri de Bash’tir. Geçtiğimiz hafta Bash kabuğunda bir güvenlik açığı fark edildi. Bu açık, Bash’in yorumladığı betik programlama dilinde tanımlanan fonksiyonların alt süreçlere aktarımı sırasında, özel bir şekilde düzenlenmiş fonksiyonların içine yazılan komutların işletilebilmesine neden olmaktadır. Örneğin, Bash kabuğuna aşağıdaki komutu verelim: $ env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"Bu komutla sadece iki işlem yapılıyor olması gerekiyor: * “x” fonksiyon tanımı yapılıyor. * Bash altında “echo test” komutu çalıştırılıyor. Bu işlemin sonucunda normalde ekrana sadece “test” yazılması, x fonksiyonunda tanımlanan işlemlerin çalıştırılmaması gerekiyor. Ancak açığı içeren bir sistemde yukarıdaki komut çalıştırıldığında ekrana hem “vulnurable” hem de “test” yazılıyor. Bu sorunun yaklaşık 22 senedir olduğuna dair yorumlar bulunuyor. Bu nedenle, kıyasla daha yenice geliştirilen diğer kabuk yazılımlarında da benzer bir açık çıkması olasılığı bulunuyor. Bu konuda araştırmalar devam ediyor. Olası riskler nelerdir? Çoğu sunucu yazılımı çalıştıracakları harici süreçleri kendi kabuk ortamları içinde çalıştırırlar. Bu da, ortam değişkenleri kullanılarak ShellShock açığını tetikleyebilecek komutların çalıştırılabilmesi riskini doğurmaktadır. Örneğin, pek çok web uygulaması web sunucuların harici bir yorumlayıcı çağırması yöntemiyle çalıştırılmaktadır. Bunun için kullanılan CGI mekanizmaları, HTTP protokolü ve web isteğinde iletilen parametreler gibi bazı bilgileri yorumlayıcıya iletmek için ortam değişkenlerini kullanır. Bu nedenle, HTTP başlık bilgilerine ShellShock açığını kullanan komutlar eklenmesi halinde, saldırganların istedikleri komutları işletmesi riski bulunuyor. Bu sorun sadece web sunuculara özel bir sorun değil. Birçok sunucu yazılımı benzer yöntemler kullanmakta ve ShellShock saldırıları için ortam sağlamaktadır. Zaten ShellShock açığının bu kadar önemsenmesi ve gündem haline gelmesindeki nedenlerden biri de açığın boyutlarının tam olarak belirlenememesi olmuştur. Örneğin, bir başka saldırı vektörü olarak, kullanıcıları belli bir alana kısıtlayacak şekilde ayarlanmış kabuklarda (Jail) bu kısıtlamaların etrafından dolaşılma ihtimali yarattığı düşünülmektedir. Git sunucusu, kısıtlı ssh erişimi vb. sistemlerin birer saldırı vektörü olma ihtimali olduğu da düşünülüyor. Sorunun başka nasıl kötü amaçlar için kullanılabileceği halen incelenmeye ve gerekli önlemler alınmaya çalışılıyor. Alınan önlemler neler? Bu sorun ilk fark edildiğinde ilgili yerlerde ambargo süreci işletilerek yönetildi. Dağıtıcılar (vendor) sorundan ve düzeltmelerinden belli bir zaman önce haberdar edildi ve sorunun herkese açıklanması için TSİ salı günü 17:00 ambargo bitimi olarak belirlendi. Ambargo bitiminden önce dağıtımların güncelleme için gerekli çalışmaları tamamlamış olmaları ve ambargo bittikten sonra düzeltmeleri yayınlamaları gerekiyor. Redhat tabanlı sistemler, Suse/OpenSuse ambargo biter bitmez düzeltme paketlerini yayınladılar, ve hemen 1-2 saat içerisinde yansılara düzeltmeler dağıldı. Mandrake ve Slackware 1 gün gecikmeli olarak düzeltme paketlerini (güncellemeleri) yayınladı. Ubuntu ve Debian sadece son sürümler ve LTS sürümler için düzeltme yayınlayacaklarını açıkladılar. Örneğin, Ubuntu 13.x sürümlerinde bu sorun düzeltilmeyecek. [Üye Olmadan Linkleri Göremezsiniz. Üye Olmak için TIKLAYIN...]
	Alıntı

Benzer Konular
Konu	Konuyu Başlatan	Forum	Cevaplar	Son Mesaj
Steam'de ciddi bir güvenlik açığı ortaya çıktı	miSy	Güvenlik Açıkları	0	08 Eylül 2015 12:59
Samsung telefonlarda büyük güvenlik açığı	miSy	Güvenlik Açıkları	0	08 Eylül 2015 12:54
Güvenlik açığını bulma - Sitelerde Güvenlik Açığı Bulma	miSy	Güvenlik Açıkları	0	08 Eylül 2015 12:53
Joomlada açığı olan bileşenler listesi	Violence	Joomla	0	27 Temmuz 2015 21:20
WHMCS Güvenlik Önlemleri	Ahmet	WHMCS	2	06 Mart 2015 16:06

Konuyu Toplam 1 Üye okuyor. (0 Kayıtlı üye ve 1 Misafir)

Etiketlenen üyelerin listesi
Kullanıcı isimlerini birbirinden ayırarak giriniz : Örnek - Üye1,Üye2,Üye3