BugTraq Tarayıcı Testi

0
Soulblighter
SecurityFocus sitesinde Michal Zalewski tarafından gerçekleştirilmiş bir tarayıcı testi var. Ben de bu testin çevirisini (özetle) burada sunuyor ve yorumlarınızı merakla bekliyorum :)

Çok kullanılan web tarayıcılarının potansiyel saldırılara ve DoS ataklarına ne kadar dayanabildiklerini ölçmek istedim. Bu amaçla kullanışlı bir araç hazırladım.
1.) Arkaplan - Araç

Boş zamanımda hatalı HTML kodu üreten bir program yazdım. Program, istemciye sürekli yeni veri göndererek tarayıcının sürekli aktif olarak kalmasını sağlıyor.

Araç sadece HTML kodu üretiyor. CSS, JavaScript gibi ek özelliklwer üretmiyor. Eğer programı indirmek isterseniz buraya tıklayın.

Küçük bir canlı sunum görmek için ise buraya tıklayın.

2.) Yöntem ve Hedefler

Bu programı MS IE, Mozilla / Netscape / Firefox, Opera, Lynx ve Links için çalıştırdım.

3.) Sonuç

MSIE hariç tüm web tarayıcıları, NULL işaretçileri referansları, bellek hatası, tampon taşması gibi sebeplerden çöktü.

4.) Örnek Hatalar

Buradan hata örneklerine bakabilirsiniz.

mozilla_die1.html
NUL'dan sonra TEXTAREA, INPUT, FRAMESET ve IMG etiketleri geldiğinde ve daha sonra onları çeşitli karakterler takip ettiğinde, bellek hatası / taşması gibi problemler ortaya çıkıyor ve bu durum, tarayıcının NULL işaretçisine veya geçersiz bir işaretçiye erişirken çökmesine ve sonsuz döngüye girmesine, neden oluyor. Benim tahminim bu tarayıcı etiket uzunluğunu "strlen" gibi bir fonksiyonla ölçüyor ve bunu bir ayıraç veya ">" (büyüktür) işareti görene kadar kopyalıyor. Tabi bu sadece bir tahmin.

Bu durum etikete ve işletim sistemine bağlı ve NULL işaretçisine erişememek güvenlik tehlikesi doğurabilir.

opera_die1.html
Hatalı COL SPAN ve TBODY, Opera'nın hata yapmasına ve yüklenmemiş belleğe referans oluşturmak istemesine neden oluyor. Doğru şartlarda kullanıldığında tehlike doğurabilir.

links_die1.html
Hatalı tablo boyutları links'in "calloc" hata verene kadar tüm belleği doldurmasına ve dolduğunda ise tekrar ayrılan belleğin üzerine yazmasına neden oluyor. Bir bakıma kendisine DoS saldırısı yapmasına sebep oluyor.

lynx_die1.html
Hatalı HTML okurken sonsuz döngüye giriyor.

5.) Üreticileri Uyarma
Bazı üreticileri bu ilk tespit ettiğim hatalara karşı uyardım.

6.) Puansız Sonuçlar
Genel kod kalitesine bakıldığında kendini "güvenli" olarak duyuran diğer tarayıcıların MSIE'nin gerisinde kaldığını gördük. Sadece MSIE hatalı girdiyi doğru şekilde işledi.

Elbette bu durum MSIE'nin güvenli olduğunu göstermez. MSIE bir çok güvenlik sorununa sahip olduğu gerçek. Fakat kodun kalitesi onun "güvenli" rakiplerinden daha iyi.

Kaynak: SecurityFocus

Görüşler

0
ttk
IE'nin kod kalitesi ile ilgili çıkan sonuç ilginç.
Bir kaç yıl önce tam okuyamadığım, bir göz attığım "Hatasız Kodlama" isimli, yanlış hatırlamıyorsam bir Microsoft programcı grubu yöneticisine ait bir kitapta bu tip belirsizliklere ve bunlara karşı alınacak önlemlere vs. işaret ediliyordu. Programcılarının kafasına bu tip hatalardan kaçınmayı yerleştirmek için uğraş verdiklerinden önemle bahsediliyordu kitapta.

Diğer browser'ları hazırlayanların web sayfalarını hazırlayanların iyi niyetine ve kodlamayı hatasız yapacaklarına güvenircesine dikkatsiz hareket etmiş olması heç de iyi olmamış, kullanıcılar açısından da oldukça tehlikeli ne yazık ki.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

Yazılım Yalan Söyler Mi? Adobe Acrobat Reader Vakası

FZ

Language Blog isimli ve genellikle dilbilimcilerin yazdığı bir kolektif blog'da Adobe Acrobat Reader ile ilgili bir girdi dikkatimi çekti.

Yazara göre Acrobat Reader'in Preferences kısmına gelir ve JavaScript'i kaldırmaya çalışırsanız baktığınız belgede JavaScript kullanıldığına ve bu özellik kaldırılırsa düzgün görüntüleme yapılamayacağına dair bir uyarı geliyor. Blog girdisinin yazarı Acrobat Reader 6.0.3'ü Mac üzerinde kullanırken böyle bir deneme yaptığında benzer bir şeyle karşılaştığını ancak işin garibi söz konusu belgenin kendi hazırladığı ve LaTeX'ten PDF'ye dönüştürdüğü bir belge olduğunu dolayısı ile JavaScript filan içermediğini belirtiyor! Dolayısı ile programın yalan söylemesi söz konusu.

Belgelerde JavaScript kullanılmasının sebebi ise Remote Approach isimli bir şirketin PDF okunduğu zaman bunun okundu bilgisini Internet üzerinden başka bir yere iletecek bir sistem geliştirmiş olması. "Web bug"lardan sonra başımıza bir de bu çıktı ;-) Neyse ki Acrobat Reader'daki JavaScript uyarılara rağmen iptal edilebiliyor.

Çalışanların 2/3'ü şifrelerini not ediyor

anonim

Searchsecurity.com tarafından yapılan araştırmada kullanıcılar IT şifrelerini en az bir defa kağıt kalem ile not ettiklerini itiraf ettiler. Bunun başlıca sebebi olarak firmaların yüzde 75'inin şifreleri en az 13 haftada bir değiştirmeleri cevabını verdiler.

Şirketler şifre seçiminin önemini yavaş yavaş kavramaya başladı fakat güvenli sağlam şifre ile akılda kalması çok zor şifre arasındaki ince çizgiyi fark etmek gerekiyor aksi takdirde kullanıcı şifreyi not almak ve hatta bu notu ekranın köşesine iliştirmek zorunda kalıyor.
Zincir en zayıf halkası kadar güçlüdür sözünü bir kez daha hatırlatıyorum.
Haberin Kaynağı

Phrack #63

sakpolat

Merakla beklenen Phrack dergisinin 63. sayısı yayınlandı.
http://www.phrack.org

Solaris Sistemlerde Ciddi Güvenlik Açığı

FZ

Dün yayınlanan ve sadece Sun Solaris 10, Solaris 11 işletim sistemlerini etkileyen güvenlik açığı telnet servisine herhangi bir sistem kullanıcısının parolasız bağlanabilmesini sağlıyor. Eğer root kullanıcısının telnet erişim yetkisi varsa bu, parolayı bilmeden sisteme tam yetkili erişilmesi manasına geliyor. Benzer bir açık 1994 yılında bazı UNIX sistemlerinde de görülmüştü.

Güvenlik açığını nasıl test edersiniz?

Internet Ortamındaki Kişisel Bilgisayarlar İçin Temel Güvenlik Tehditleri

anonim

Bilgisayarı karıştırırken bir kongre için yazıp daha sonra göndermekten vazgeçtiğim aşağıdaki tarama/derleme türündeki makale özeti gözüme çarptı. Aslında daha çok başlangıç düzeyindeki bir makalede olsa bilgisayarın harddiskinde tozlanmasına gönlüm razı olmadı. Burada en azından yeni başlayan arkadaşlar için bir kaynak olabileceğini düşünüyorum.