WorstFit: Windows ANSI'nın Gizli Dönüştürücüleri Açığa Çıkıyor

WorstFit: Windows ANSI'nın Gizli Dönüştürücüleri Açığa Çıkıyor

TL;DR

• Windows'un dahili karakter seti dönüştürme işlevi olan Best-Fit kötüye kullanılarak yeni bir saldırı yüzeyi bulundu.
• Bu işlev, yol geçişi, argüman enjeksiyonu, uzaktan kod çalıştırma (RCE) gibi pratik saldırılara dönüştürüldü.
• Sorunun temel nedeni derleyici davranışı, C/C++ runtime ve geliştirici hatalarında yatıyor.
• Açık kaynak ekosistemine düzeltmelerin uygulanmasının zorluğu da tartışıldı.

Windows Kodlama Analizi

Başlangıç: ANSI ve Kod Sayfaları

• Windows başlangıçta ANSI kodlamasını kullanıyordu; bu, belirli diller için etkilidirken farklı karakter kümelerini aynı anda işleyemiyordu.
• Çeşitli kod sayfaları vardı ve her bir kod sayfası belirli bir dili destekliyordu.

Unicode Çağı: UTF-16

• Windows, 1990'lı yılların ortalarında, neredeyse tüm dillerin karakterlerini tek bir standartta temsil edebilmek için Unicode'a geçti.
• Başlangıçta UCS-2 kullanıldı, ancak kısa süre sonra UTF-16'ya yükseltildi.

Çift Kodlama Çağı

• Windows, eski ANSI kod sayfalarını desteklemek için iki API sürümü uyguladı.
• ANSI API ve Unicode API bulunur; geliştiriciler istedikleri veri biçimini kolayca alır.

Best-Fit'in Avantajları

• Windows'taki "Best-Fit" karakter dönüşümü, UTF-16'dan ANSI'ye dönüştürme yapılırken hedef kod sayfasında bulunmayan karakterlerin nasıl ele alınacağını belirler.
• Örneğin, ∞ sembolü Windows-1252 kod sayfasında olmadığı için Microsoft bunu 8 ile eşleştirir.

WorstFit: Windows'ta Yeni Bir Saldırı Yüzeyi

🔥 Doğu Asya Kabusu - CVE-2024-4577

• CVE-2024-4577, yalnızca Çince veya Japonca kod sayfalarını kullanan bir PHP-CGI sunucusunu basit bir ?%ADs isteğiyle bozabilen bir güvenlik açığıdır.
• Best-Fit davranışı nedeniyle U+00AD (yumuşak tire) karakteri tireyle (-) eşlendiği için geçiş (bypass) mümkün olur.

🔥 Dosya Adı Sömürüsü

• Dosya adı işleme sırasında WorstFit kötüye kullanılarak yol geçişi (path traversal) yüklerine dönüştürülebiliyor.
• Örneğin, Chrome V8 Developer Shell (d8.exe) geçerli çalışma dizinini almak için ANSI API kullanır.

🔥 Argüman Bölme

• GetCommandLineA çıktısı manipüle edilerek WorstFit davranışı, komut satırı ayrıştırmasına saldırı olarak kullanılabilir.
• Örneğin, ＂ --use-askpass=calc ＂ girdisi, sistemde calc.exe çalıştırılmasına yol açabilir.

Sonuç

• Best-Fit davranışı, sistem düzeyindeki dönüştürme sürecinde bir saldırı yüzeyi sunar ve bu, farklı araçlarda güvenlik açıklarına neden olabilir.
• Bu tür saldırılar standart kütüphane ya da programlama dili işlevleriyle tamamen engellenemez.

[GN⁺]

Hacker News Yorumları

• Microsoft bu durumu en az bir yıldır biliyor. CA2101 adlı özel bir kod analizi kuralı, best-fit eşlemenin kullanılmamasını öneriyor. Güvenlik açığına değindi ama ayrıntılar muğlaktı.

• Bu mesele sistematik. Microsoft, Unicode'u ASCII'ye dönüştüren bir "best fit" kod eşlemesi sağlıyor. Bu eşleme birçok yerde kullanılıyor ve Microsoft'un geriye dönük uyumluluğa verdiği önem nedeniyle kalmaya devam ediyor. Aslında her yerde entegre.

  • Genelde bozuk kod noktalarının slash, tire, tırnak işareti gibi karakterlere çevrilmesi için kötüye kullanılabiliyor. Modern programlama dillerinde doğru şekilde değerlendiriliyor ama kabuk komutlarına veya Win32 API'sine iletildiğinde sorun çıkıyor.

  • curl bakımcısı "curl mağdur" diyor ama asıl sorun başka bir yerde. Sunucu kullanıcı girdisini doğrularken bir mantık uygulayıp sistem kütüphanesine uygularken farklı bir davranış sergilerse problem oluşuyor.

  • Win32 tarafında "best fit" dönüşümünü seçici olarak devre dışı bırakmak çözüm olabilir. Açık kaynak sağlayıcıları bunu en iyi uygulamaya ekleyebilir.

• Windows bir Munchkin kart oyunu gibi birden fazla özelliğin yanlışlıkla birleşip ciddi bir zafiyet yaratmasına neden olabilir. ANSI alt sistemini UTF-8'e dönüştürmek bu sorunu hafifletebilir.

• Microsoft, NT 3.5'ten beri ANSI'yı aşamalı olarak kaldırıp Wide Character API kullanımını teşvik ediyor. Ancak Microsoft'un C/C++ runtime kütüphanesi implementasyonu bunun ana engeli.

  • Standart fonksiyonlar, Unicode dönüşümünün başarısızlığını raporlamadan A-fonksiyonlarını kullanıyor ve best-fit yaklaşımını alıyor.

• Microsoft'un tüm Windows sürümlerinde varsayılan olarak UTF-8'i etkinleştirmesi düşük ihtimalle olur. Eski uygulamalar belirli kod sayfalarına veya tek baytlık karakterlere bağlı kaldığı için.

  • win32 xxxA API'lerindeki Best-Fit mantığını kaldırmak daha az problemi tetikleyecektir.

• Uygulamada "Ansi" kod sayfasını UTF-8'e zorlamak için iki yöntem var. Biri Manifest dosyası kullanmak, diğeri "App Locale" aracını kullanmak.

• Kişisel Windows makinemde UTF-8 modunu açarak bu hatadan korunmuş oldum. Eski bir yabancı oyunda bozuk metin görünmesi nedeniyle bunu ayarlamıştım.

• Sorunu yalnızca main()i geniş karakter sürümüne çevirmek çözmüyor. Tüm değişkenlerin wchar_t * türüne dönüştürülmesi gerekir ve bu acı verici, hata yapmaya çok açık.

  • Bunun yerine alınan geniş karakterleri UTF-8'e çevirip charı kullanmaya devam edilebilir. ANSI veya OEMCP dizileri ile UTF-8 dizilerini karıştırmamaya özen gösterilmeli.

• Windows API'nin best-fit dönüşüm sağladığını biliyordum ama bunun varsayılan davranış olduğunu bilmiyordum. Bu özellik kapatılmalı.

• Beta kutucuğunun, ActiveCodePage'i UTF-8 yapmakla aynı olup olmadığını merak ettim. GDI süreç bazlı kod sayfasını değil, sadece global kod sayfasını takip ediyor. UTF-8'i tamamen seçemiyor olmamız çok üzücü.