Kayıp Şehir / Serkan Kenar

Geçtiğimiz hafta The Invisible Labs‘taki uzmanlar Intel işlemcileri etkileyen ve SMRAM’e kod sokuşturmaya imkan sağlayan bir açık buldular. Normalde bu alan yazılamaz olarak biliniyordu ve burada çalıştırılan kod en yüksek öncelikli seviye olan Sistem Yönetim Modunda (SMM) çalışıyor.

Bu iki açıdan çok tehlikeli: 1. açık işletim sisteminde bağımsız olarak işlemciyi etkiliyor. 2. bir kere SMRAM’e bulaştıktan sonra işletim sistemi veya anti virüs yazılımları tarafından tespit edilmesi mümkün değil.

Aslında işlemcilere yönelik saldırılar ve SMRAM’e erişimle ilgili daha önce de açıklanmış açıklar bulunuyor. Black Hat 2008′de bu tür saldırılar ile ilgili bir sunum yapılmış ve yine SMM üzerinden bir rootkit çalıştırılabileceği kanıtlanmıştı.

Bu tür saldırıları görünce aklıma ACM Klasiklerinden, Ken Thompson’ın Reflections on Trusting Trust yazısı geldi. Ken Thompson’ı tanımıyorsanız, en azından Unix, Plan 9, B (C’nin öncülü olan dil) ve UTF-8′i duymuşsunuzdur. Ken, bu yazısında adım adım bir derleyicinin nasıl zehirlenebileceğini ve ondan sonra derlenen tüm programların (ve tabii ki derleyicilerin de) nasıl zehirlenmiş olarak üretileceğini şaşırtıcı derecede basit bir örnekle gösterir ve şu sonuca varır:

You can’t trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.

Hiç bir şeye güvenemezsiniz. İşlemciye bile.

The Invisible Labs’in açığı açıkladığı makalesinde ilginç bir bilgi var. Intel aslında bu açığı biliyormuş ve hatta çalışanları nasıl düzeltilebileceğiyle ilgili bir patent başvurusunda bile bulunmuşlar. Yine de neden düzeltmedikleri belirli değil (?). Intel, araştırmacılar açığı bildirdikten sonra, hatayı kabul etmiş ve düzeltileceğini açıklamış.

Bu arada işlemcilerde açık var diye panik yapmaya gerek yok. Bu saldırılar çok düşük seviye çalışıldığı için ancak saldırılacak makineye göre çok hassas saldırılara imkan sağlıyor. İşletim seviyesi, uygulamalar hatta tarayıcılar seviyesindeki açıklar çok daha etkili, yaygın ve tehlikeli olmaya devam edecektir.

Geçen sonbaharda Stuttgart’taki eğitimden sonra Amsterdam’a yolum düşmüştü. İşte Amsterdam’da çektiğim fotoğraflar..

Daha önce demiştim, 40 saat yeter diye. Aşırı yoğun ve stresli çalışırsanız, olacağı bu.

Bu sitedeki yavaşlık canımı sıkıyordu. Yakın zaman önce temayı sadeleştirip, pluginlerin de bir kısmını kapatmıştım. Arada wp-cache ve wp-cache2 de kullandım. Ama yine de sorunumun geçmediğini görüyordum. Ben de YSlow’u denemeye karar verdim.

YSlow, Firebug eklentisiyle birlikte çalışarak web sitelerinin performansını analiz ediyor ve uyarılar listeliyor. Aşağıdaki ilk grafik Firebug ile sayfanın açılışını gösteriyor.

Toplam 28.8 saniye. İstekleri inceleyince çoğu prototype js kitaplığıyla ilgili. Ama kullandığım ana sayfa zaten çok sade ve bu kitaplığın efektlerine ihtiyaç duymuyor. Acaba kim yüklüyor bunları diye bir araştırdım. Eklentilerden değil. Temada da (doğal olarak) yok. Araştırmayı bir üst dizine taşıyınca gördüm ki, bu gereksiz dosyaların sebebi WordPress’in kendisi. wp-includes/script-loader.php içindeki varsayılan scriptler dosyası, prototype.js’i ekliyor. O da ilgili diğer js’leri indiriyor.

//$this->add( ‘prototype’, ‘/wp-includes/js/prototype.js’, false, ’1.6′);

İlgili satırı yukarda görüldüğü gibi bulup, yorum altına alıyoruz. Yeni grafiğimiz aşağıdaki gibi:

Toplam 10.68 saniye. 28.8′den başladığımızı düşünürsek, büyük kazanç. Üstelik liste ilkine göre yarı yarıya daha kısa. Bu değişikle bir şeyleri bozdum mu bilmiyorum..? Siteyi şöyle bir dolaşınca soruna rastlamadım.

WordPress açısından bakarsak, her sürümde giderek ne kadar gereksiz şeylerle doldurduklarını da gösteriyor. Tahminime göre bu fazladan yüklenen js dosyaları ziyaretçi tarayıcılarında önbelleğe alınmadıkça, wp-cache gibi eklentiler de fayda etmiyor. Statik sayfa ama yine de bu dosyalara bağlantılar içeriyor.

Sonuç olarak kısa sürede performans artışı sağlayan bir püf çıktı ortaya. Kolay gelsin,

Nuri Bilge Ceylan’a ödülü aldıktan sonra söylediği güzel sözleri ve başarısı için..

“tutkuyla sevdiğim yalnız ve güzel ülkeme adıyorum.”

13 Mayıs’ta sadece Debian ve Ubuntu işletim sistemlerinde bulunan bir açık yayınlandı. Ama etkisi sadece bu sistemlerle sınırlı değil. Debian/Ubuntu sistemleri üzerinde 2006-2008 Mayıs arası üretilen tüm SSL sertifikaları hatalı!

Detaylı İnceleme

Sorun 2 Mayıs 2006′da Debian geliştiricilerinin daha önce defalarca bildirilen bir uyarıya istinaden kodun iki satırını silmelerinden kaynaklanıyor.

Valgrind ve Purify gibi yazılımlar C/C++ kodunu inceleyip, sorunlu buldukları noktalarda (örneğin ilk değer verilmemiş değişkenlerin, hafıza alanlarının kullanılması gibi) uyarılar vererek, kodun kalitesini arttırmaya yardımcı olurlar. Ancak OpenSSL içinde bir nokta bulunuyor ki burada yazılımcılar “bilerek” ve “isteyerek” hafızadaki ilk değer verilmemiş alanı kullanıyorlar. Yazılımın bu noktasında verilen uyarıyı OpenSSL ekibi şu çağrıda cevaplamış:

I think there’s we need to create a FAQ entry about this …
….
No, it’s fine – the problem is Purify and Valgrind assume all use of
uninitialised data is inherently bad, whereas a PRNG implementation has
nothing but positive (or more correctly, non-negative) things to say
about the idea.

Debian ekibi OpenSSL takımını dinlemeyip sadece bu uyarıya bakarak, gereksiz gördükleri şu iki satırı kaldırdıkları için, rasgele sayı üreteci o noktada, sadece o anki süreç numarasını (process id – pid) kullanır olmuş:

MD_Update(&m,buf,j);
…
MD_Update(&m,buf,j); /* purify complains */

Linux’ta PID numarası en çok 32768 farklı değer alabiliyor. Bu da hızlı gökkuşağı tablosu saldırılarına imkan sağlıyor. (Bu sayfadaki araçlarla 1024-bit sertifika imzaları yaklaşık 2 saat gibi bir sürede oluşturulmuş. Tablo elinizde olduktan sonra sertifikanın kaç bit olduğunun bir önemi yok.)

Sorun Giderme

Debian, 13 Mayıs 2008′de yayınladığı güvenlik bildirisinde sorunlu sertifikaları tespit etmek için bir araç gösterilmiş. Problem ne yazık ki, tahmin edilenden çok daha geniş bir kesimi etkiliyor. Bu işletim sistemlerinde üretilen tüm sertifikalar etkilenmiş durumda. Sertifikalarını onaylatmış yerlerin tekrar sertifika oluşturmaları gerekecek. İşletim sistemlerindeki güncellemeler bu sertifikaları yeniliyor, ancak bu yeterli değil. Eylül 2006 ile Mayıs 2008 arasında Debian/Ubuntu sistemlerinde OpenSSL kullanılarak üretilen tüm güvenlik materyallerinin yenilenmesi tavsiye ediliyor.

Yorum

Debian geliştiricileri en temel ilkeyi ihlal etmişler görünüyor. “Kendi güvenlik sisteminizi oluşturmaya çalışmayın, mevcut sistemleri modifiye etmeyin.” Basit gibi görünün iki satır, iki yıl boyunca onlarca makineyi çok ciddi biçimde etkiledi. Hata, kaliteyi arttırmaya çalışan otomatik analiz araçlarının güvenirliğini sorgulamaya açması açısından da ilginç..

Konuyla ilgili en detaylı analiz ve araçlara ulaşım için şu sayfaya bakabilirsiniz.

NOT: Aslında sertifikalar teknik olarak hatalı değil. Sorun çok kısıtlı bir rasgele sayı havuzundan değerlerle yaratıldıkları için açık anahtardan, özel/gizli anahtarın keşfedilmesi çok kolay.

Dikmen Caddesi, Başbakanlığın, Genel Kurmay Başkanlığının az ilersinden başlayıp, Türkiye’nin Büyük Millet Meclisinin, Deniz Kuvvetleri Komutanlığının önünden uzayıp, Keklikpınarı‘na kadar uzayan Ankara’nın belki en önemli, en göz önünde caddesidir. Şimdilerde bu caddenin Keklikpınarı’na doğru gidiş istikametinde yol bir tarladan farksızdır, tam da meclise doğru gelmenize yakın ışıkları yanmaz, üstelik paralel şekilde kazılmış ve çökmüş bir yamayla kapatılmış haldedir. Yolu sıkılmaz devam ederseniz, Keklikpınarı’na yaklaştıkça daha da felaket hale gelmiş, artık üstüste parça parça 5-6 defa atılmış yamalı yollarda seke seke gitmeye çalışırsınız. Ve bu yol yıllardan beri bu haldedir.

Bu caddenin sahibi Büyükşehir Belediyesi mi, Çankaya Belediyesi mi? Kimse buraların yetkilisi artık bulunsun, onlar da şu yollara artık bir çözüm bulsun! Ankara’da bu kadar bakımsız, bu kadar sahipsiz bir başka cadde daha yoktur. (Belki Hürriyet Caddesi geçebilir, bilmiyorum hangisi daha felaket halde)

Biliyorum yıllarca, yıllarca bu sorunları büyütüp, sonra yerel seçimler yaklaşırken düzeltecekler ve oy toplamaya çalışacaklar. Sonra başka belediyelerin sınırlarından topladıkları oylarla, akıllarınca yetkilerinde olan ama oy çıkmayan yerleri “cezalandıracaklar”..

Bir belediyenin yapması gereken görevleri yerine getirmemesine karşı yapılabilecek bir hukuki eylem yok mudur? Bana bir bilen anlatsın…