Curl'da bir heap taşması nasıl yarattım

• curl 8.4.0'da tespit edilen önemli güvenlik sorunu CVE-2023-38545 hakkında bir yazı; bu sorun uzun süredir curl'daki en ciddi güvenlik açığı olarak değerlendiriliyor
• Sorun, SOCKS5 proxy'sine bağlanan işlevdeki bir kusurdan kaynaklanan bir heap taşması problemi
• Bu sorun, işlev 2020 başlarında bloklayan çağrıdan bloklamayan bir durum makinesine dönüştürüldüğünde ortaya çıktı; bu değişiklik, SOCKS5 üzerinden büyük ölçekli paralel aktarım performansını artırmak için yapılmıştı
• Kusur, durum makinesinin INIT durumunda bulunuyor; burada bir yerel değişken ayarlanıyor ve curl'ün ana makineyi çözüp çözmeyeceği ya da adı proxy'ye iletip iletmeyeceği belirleniyor. Ana makine adı çok uzunsa kod yerel çözümleme moduna geçiyor ve bu da ana makine adı hedef arabellekten uzunsa bellek taşmasına yol açabiliyor
• Arabellek boyutu 65541 bayttan küçük ayarlanmışsa ve ana makine adı arabellek boyutundan uzunsa taşma oluşabiliyor. Bunun gerçekleşmesi için kötü niyetli bir aktörün formüle aşırı büyük bir ana makine adı girmesi ve kusuru tetiklemesi gerekiyor
• libcurl kullanan ve SOCKS5 proxy üzerinden erişilen HTTPS sunucusunu kontrol eden bir saldırgan, HTTP 30x yanıtı üzerinden uygulamaya manipüle edilmiş bir yönlendirme döndürerek heap arabellek taşmasını tetikleyebilir
• Sorun, curl 8.4.0'da ana makine adı fazla uzunsa uzaktan çözümlemeden yerel çözümlemeye geçmek yerine curl'ün hata döndürmesi sağlanarak düzeltildi. Bu senaryo için özel bir test durumu da eklendi
• Yazar, curl bellek güvenli bir dilde C yerine yazılmış olsaydı bu kusurun ortaya çıkmayacağını kabul ediyor; ancak curl'ü başka bir dile taşımak şu anda planlar arasında değil
• Yazar, bellek güvenli dillerle yazılmış daha fazla bağımlılığın kabul edilmesi, kullanılması ve desteklenmesinin uygulanabilir bir yaklaşım olduğunu; zamanla curl'ün bazı parçalarının kademeli olarak değiştirilebileceğini öne sürüyor
• Yazar hatasını kabul edip özür diliyor ve bu kusurun daha iyi bir test setiyle tespit edilebileceğini söylüyor. Ayrıca bu işlevdeki sorunu yakalayamayan statik kod analiz araçlarına da değiniyor
• Yazar, 20 milyardan fazla kurulumda bulunan bir kodda heap taşması yayımlamanın tavsiye edilecek bir deneyim olmadığı sonucuna varıyor

[GN⁺]

Hacker News görüşü

• Curl kütüphanesindeki heap overflow sorunu hakkında bir yazı; bu kütüphane çok sayıda cihazda kullanılıyor ve büyük ölçüde tek bir kişi tarafından yazılıyor.
• Curl'un yazarı Daniel, kodda 1315 gün boyunca fark edilmeyen bir kusurun yol açtığı hata için özür diliyor.
• Yazı, Curl C yerine bellek güvenli bir dille yazılmış olsaydı bellek güvenliği sorunlarının önlenebileceğini öne sürüyor.
• Yazar, Curl'un bazı bölümlerini daha bellek güvenli bir dille kademeli olarak değiştirme olasılığını değerlendiriyor, ancak böyle bir geliştirmenin yavaş ilerleyeceğini kabul ediyor.
• Yazar, Curl'daki güvenlik açıklarının %41'inin bellek güvenli dillerle önlenebileceğini savunuyor.
• Bu yazı, sorunun arkasındaki mantığı ve bakış açısını açıklayan net ve samimi anlatımıyla takdir görüyor.
• Bazı yorumlar, saldırı vektörünün çok dar olduğunu ve istismar için son derece belirli koşullar gerektiğini söyleyerek sorunun ciddiyetini sorguluyor.
• Bir yorum, sansür karşıtı araçları kullanan kişiler için DNS üzerinden kullanıcı kimliğini sızdırabilecek kod bölümünü eleştiriyor.
• Başka bir yorum, yazarın RFC1123'te belirtilen DNS ana makine adı kısıtlamalarını göz ardı ettiğini ve bunun soruna katkıda bulunmuş olabileceğini belirtiyor.
• Windows 10 için yayımlanan en son güvenlik güncellemesinin Curl'un yeni sürümünü içermediği de not ediliyor.