Tek karakterlik hata, tek baytlık asal sayı: GoAhead'in Diffie-Hellman açığı

Aynı hafta iki kez “4”

Ekim’in son haftasında güvenlik dünyasında iki ayrı olay aynı sayıya çıktı. Birincisi Hint sertifika otoritesi eMudhra’nın gizli anahtarlarından birinin düpedüz 4 olmasıydı; onu eMudhra yazısında anlattık. İkincisi bambaşka bir yerden geldi: GoAhead web sunucusu. Low Level videosu ikisini xkcd’nin ünlü “rastgele sayı fonksiyonu hep 4 döndürür” şakasıyla bağlıyor.

GoAhead, EmbedThis’in yazdığı küçük bir C web sunucusu. Router, kamera, endüstriyel kontrol paneli gibi cihazların yönetim arayüzlerinde sık kullanılıyor. TLS için OpenSSL (varsayılan), LibreSSL ya da Mbed TLS ile derlenebiliyor. Hata Mbed TLS seçeneğinde.

Önce kısa bir Diffie-Hellman dersi

İki taraf, herkesin dinleyebildiği bir hat üzerinden ortak bir gizli anahtar üretmek istiyor. Diffie-Hellman bunu şöyle yapıyor: Herkes büyük bir asal sayı p ve küçük bir taban g üzerinde anlaşıyor. Alice gizli bir a, Bob gizli bir b seçiyor. Alice g^a mod p, Bob g^b mod p değerini açıkça gönderiyor. Sonra ikisi de karşıdan geleni kendi gizli sayısıyla üsleyip aynı sonuca ulaşıyor: g^(ab) mod p. Dinleyen kişi a ya da b’yi bulmak zorunda, bu da p yeterince büyükse pratikte imkânsız.

TLS 1.2’deki DHE şifre takımları bunu her bağlantıda yeni sayılarla yapıyor. Bu yüzden sunucunun uzun vadeli anahtarı ileride çalınsa bile kaydedilmiş eski trafik çözülemiyor. Buna forward secrecy deniyor. Bütün güvenlik p’nin büyüklüğüne dayanıyor: GoAhead’in kullandığı grup RFC 3526’daki 2048 bitlik, yani 256 baytlık asal.

Hata nerede?

FoxIO’dan Sébastien Féry’nin yazısına ve EmbedThis’in duyurusuna göre src/mbedtls.c dosyasında parametreler mbedtls_ssl_conf_dh_param_bin() fonksiyonuna verilirken asal sayının uzunluğu olarak sizeof(dhm_p) yerine sizeof(dhm_g) yazılmış. g tek bayt olduğu için Mbed TLS asalın da sadece ilk baytını okudu: 0xFF, yani 255. Sunucu el sıkışmada bu “asal”ı ilan ediyordu. FoxIO’ya göre hata 2018’deki bir API geçişinde girmiş ve 2024’teki bir TLS düzenlemesinden de sağ çıkmış.

255 asal bile değil. Taban 2 olduğunda 2^x mod 255 sadece sekiz farklı değer alabiliyor: 1, 2, 4, 8, 16, 32, 64, 128. Yani ortak gizli değer her zaman bu sekizden biri. Kaydedilmiş bir oturumu çözmek için sekiz tahmin yeterli. Videodaki “gizli anahtar 4” vurgusu bu sekiz değerden birine denk geliyor. FoxIO’nun denemesinde doğru değer beşinci tahminde bulundu.

Ne kadar tehlikeli?

EmbedThis açığı orta seviye (CVSS 5.9) olarak işaretledi, CVE numarası yok. Saldırı için trafiği kaydeden pasif bir dinleyici yetiyor ama bir şart var: İstemcinin bu kadar küçük bir grubu kabul etmesi. OpenSSL, güncel Go, Java ve tarayıcılar “modulus too small” diyerek reddediyor. Minimum boyut kontrolü olmayan gömülü ya da özel yazılmış istemciler ise oturumu tamamlayabiliyor. TLS 1.3, ECDHE ve OpenSSL ile derlenmiş GoAhead etkilenmiyor.

Aynı araştırma iki ağır açık daha buldu. OpenSSL ile derlenen sürümlerde iptal listesi (CRL) yükleniyor ama kontrol bayrağı hiç açılmadığı için iptal edilmiş istemci sertifikaları kabul ediliyor (CVSS 9.1). LibreSSL’in eski doğrulayıcısıyla da fazla uzun bir sertifika zinciri yetkilendirmeyi aşabiliyor (CVSS 7.4).

Ne yapmalı?

• GoAhead kullanan bir cihaz üretiyorsan 6.1.1’e geç. Düzeltme tek satır: sizeof(dhm_p).
• Geçemiyorsan sonlu alan DHE şifre takımlarını kapat ya da OpenSSL arka ucuna geç.
• Kendi TLS istemcini yazıyorsan sunucunun ilan ettiği grubun boyutunu kontrol et. 2048 bitten küçüğünü reddet.
• Cihaz sahibiysen üreticinin firmware güncellemelerini takip et. Düzeltme sana ancak firmware ile ulaşır.

Düşün

• Kodunda sizeof ile uzunluk verdiğin ve yanlış değişkeni yazsan derleyicinin hiç uyarmayacağı yerler var mı?
• Kriptografik parametreleri “kütüphane kontrol eder” diye mi bırakıyorsun, yoksa kendi testlerinde boyutlarını doğruluyor musun?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.