PHP2Shell Açığı İçin Dolaşımdaki Geçici Çözüm Yetersiz, Tek Güvence Yama

PHP topluluğu, PHP2Shell olarak adlandırılan ve 10 üzerinden 9.2 önem puanı biçilen iki kritik güvenlik açığı için günlerdir dolaşımda olan geçici çözümün aslında tam bir koruma sunmadığını kabul etti. Açıkları keşfeden Tokyo merkezli güvenlik firması GMO Flatt Security, başlangıçta önerdiği yapılandırma değişikliğinin saldırıları engellemek için yeterli olmadığını açıkladı. Resmi yama 21 Ekim saat 14:00 UTC itibarıyla yayımlanacak şekilde planlandı ve PHP bu tarihe kadar kendi tarafından onaylanmış herhangi bir geçici çözüm sunmadı.

Yayılan Geçici Çözüm Neden İşe Yaramıyor?​

Güvenlik bloglarında ve sosyal medyada hızla yayılan öneri, PHP yapılandırma dosyasına tek bir satır eklenmesine dayanıyordu: session.upload_progress.enabled=0. Bu ayar, varsayılan olarak açık gelen ve bir dosya yüklemesinin ne kadar ilerlediğini kaydeden Session Upload Progress özelliğini devre dışı bırakıyor. GMO Flatt Security, 21 Ekim'de Japonya saatiyle 14:00'te (05:00 UTC) yayımladığı güncellemede bu ayarın tek başına tam bir düzeltme olmadığını ve saldırıların bu engeli aşmasının beklendiğini duyurdu. Firma, yöneticilere yamayı hazırlamalarını, yayımlanmadan önce saldırı trafiğini izlemelerini ve düzeltme çıkar çıkmaz uygulamalarını tavsiye etti.
PHP çekirdeği geliştiricisi ve PHP Foundation tarafından desteklenen dokümantasyon yazarı Gina Peter Banyard, konuyu daha doğrudan bir dille özetledi. Yükleme ilerlemesi ayarının açığı kapatıp kapatmayamayacağını soran birine verdiği yanıtta Banyard, "Söyleyebileceğim tek şey şu: Tek geçerli önlem PHP'yi yamalamak ya da yükseltmek. Ne yazık ki çok fazla şey biliyorum" dedi.
Ayarın güvenilir bir koruma olmadığının iki temel nedeni var. Birincisi, GMO Flatt bu ayarı aşmanın bir yolunun bulunmasını beklediğini açıkladı ancak bunun nasıl gerçekleşeceğini paylaşmadı. İkincisi, açığın Session Upload Progress özelliğinde bulunduğu iddiası yalnızca bir tahmin; PHP bunu doğrulamadı, firmanın kendisi de bu sonucun kendi araştırmasının PHP2Shell ile örtüştüğü ölçüde geçerli olduğunu belirtti. Üstelik anonim bir hesap tarafından yürütülen bağımsız bir kod denetimi, başkalarının bu özellikte tanımladığı spesifik hatanın yayımlanan PHP sürümlerinde mevcut olmadığını ileri sürdü.

Farklı Güvenlik Firmalarından Farklı Değerlendirmeler​

Konu üzerinde tüm güvenlik aktörleri aynı görüşü paylaşmıyor. Upwind adlı firma, başka bir araştırmacının analizini aktararak söz konusu ayarı anlık bir önlem olarak listelemeyi sürdürdü; ancak bunu kendi testlerine değil, dışarıdan aktarılan bir analize dayandırdı. Açıklardan birini yeniden üreten watchTowr ise "şu an itibarıyla onaylanmış bir yama ya da geçici çözüm bulunmuyor" açıklamasını yaptı. Bu tabloda yöneticilerin, birbiriyle çelişen tavsiyeleri süzerken hangi kaynağa güveneceğini dikkatli biçimde değerlendirmesi gerekiyor.

Ayarı Zaten Değiştirdiyseniz Ne Yapmalısınız?​

Ayarı önceden uygulamış olan yöneticilere geri almaları söylenmiyor; asıl vurgu, bu değişikliği bir güvence olarak saymamak gerektiği üzerine. PHP'nin kendi kılavuzu zaten upload progress bar kullanmayan uygulamalar için bu özelliği kapatmayı öneriyor; çünkü depolanan dosya adları ve alan adları doğrulanmıyor ve PHP kodu içerebiliyor. Ayarı yanlışlıkla ihtiyaç duyulan bir ortamda kapattıysanız tek kaybınız yükleme ilerleme çubuklarının çalışmayı durdurması.
Teknik bir not olarak: Ayar INI_PERDIR kapsamında olduğundan php.ini, .htaccess veya .user.ini dosyalarına eklenebiliyor. Ancak .user.ini yalnızca CGI ve FastCGI PHP sürümleri tarafından okunuyor, Apache modülü tarafından değil. Ayrıca PHP bu dosyayı varsayılan olarak her 300 saniyede bir yeniden okuyor; dolayısıyla yapılan değişiklik beş dakikaya kadar devreye girmeyebiliyor. Apache modülü kullananların .htaccess veya sunucu yapılandırmasını tercih etmesi gerekiyor. Değişikliğin gerçekten etkili olup olmadığını kontrol ederken kabuk satırındaki php -i değil, web trafiğini sunan PHP-FPM ya da mod_php üzerinden doğrulama yapılması önem taşıyor.

Yama Geldiğinde ve Gelemeyenler İçin Ne Yapılmalı?​

GMO Flatt Security, yöneticilere güncelleme adımlarını ve ardından yapılacak kontrolleri önceden doğrulamalarını, yapılandırma değişikliklerini prova etmelerini ve olası acil bir yeniden başlatma için gerekli kişi ve onayları hazır bulundurmalarını tavsiye etti. Yama yayımlandığında güncellenmesi gereken şey web isteklerini sunan çalışma zamanı, yani PHP-FPM, mod_php ya da CGI; bunların üzerinde çalışan uygulama değil. WordPress, Laravel veya başka bir uygulamayı güncellemek, altındaki PHP çalışma zamanını güncellemez; bu güncelleme sunucu paketi, barındırıcı veya konteyner imajı üzerinden gelir.
PHP yalnızca desteklediği dört dal için düzeltme yayımlıyor: 8.2'den 8.5'e kadar. Hangi sürümlerin etkilendiği ve düzeltmenin ne kadar geriye gittiği yayımla birlikte duyurulacak. 8.2 öncesi, yani 8.1, 7.x ve 5.x gibi ömrünü tamamlamış dallar için PHP tarafından herhangi bir düzeltme gelmeyecek; bu sistemler için yükseltme, çevrimdışına alma veya izole etme seçenekleri değerlendirilmeli. Bir Linux dağıtımı ya da barındırıcı kendi takviminde düzeltmeyi geri taşıyabilir.
Anında yama yapılamayan ortamlar için CERT-EU, düzeltme uygulanana kadar internete açık uygulamaları kamuya açık ağlardan izole etmeyi öneriyor. Banyard, sunucuyu bir günlüğüne kapatmanın en mantıklı seçenek olabileceğini, ancak çoğu kullanıcı için bunu talep etmenin makul olmaktan uzak olduğunu belirtti. Tamamen kapatmak mümkün değilse siteyi VPN, izin listeli istemciler veya kenarda kimlik doğrulamalı erişim arkasına almak ve trafiğin bu kontrolleri atlayıp doğrudan kaynağa ulaşamadığından emin olmak önerilen adımlar arasında. Ayrıca sunucuda depolanan veri miktarını ve ayrıcalıkları azaltmak, depolanmış kimlik bilgilerini ve bulut rollerini kaldırmak, günlüklerin etkinleştirildiğini ve güvenli bir konumda tutulduğunu doğrulamak da GMO Flatt'ın tavsiye ettiği önlemler arasında yer alıyor.
Web uygulama güvenlik duvarları bu durumda zayıf bir geçici çözüm olmaktan öteye geçemiyor. Cloudflare 21 Ekim'de acil "anormal yürütme" kuralları ekledi; ancak değişiklik günlüğü ne PHP'den ne de bu açıklardan söz ediyor. Bu tür kurallar yalnızca sağlayıcı üzerinden geçen trafiği görüyor ve varyantları kaçırabilir. Yayımlanan kısa bir kavram kanıtı videosu daha sonra kaldırıldı; bağımsız kod denetimi ise dolaşımdaki kavram kanıtı kodunun çalışmadığını belirtiyor. Öte yandan 21 Ekim itibarıyla watchTowr'ın kaydına göre herhangi bir istismar bildirilmemiş ve açıklar CISA'nın bilinen istismar edilen açıklar kataloğunda yer almıyordu. Bu tablo anlık bir fotoğraf niteliğinde ve değişebilir.

Sıkça Sorulan Sorular​

PHP2Shell açığı nedir ve önem derecesi nedir?​

PHP2Shell, PHP'nin 10 üzerinden 9.2 puanla derecelendirdiği iki kritik güvenlik açığına verilen isimdir. PHP, hangi sürümlerin etkilendiğini, PHP'nin hangi bölümünün dahil olduğunu veya herhangi bir ayar değişikliğinin riski değiştirip değiştirmediğini yama yayımlanana kadar açıklamadı.

session.upload_progress.enabled=0 ayarı neden tam koruma sağlamıyor?​

GMO Flatt Security, bu ayarın tek başına tam bir düzeltme olmadığını ve saldırıların bu engeli aşmasının beklendiğini açıkladı. Ayrıca açığın Session Upload Progress özelliğinde bulunduğu iddiası PHP tarafından doğrulanmamış bir tahmin olarak kaldı; bağımsız bir kod denetimi de bu özellikte tarif edilen spesifik hatanın yayımlanan PHP sürümlerinde mevcut olmadığını ileri sürdü.

PHP2Shell için resmi yama ne zaman yayımlandı ve hangi sürümleri kapsıyor?​

PHP, yamayı 21 Ekim saat 14:00 UTC için planladı. Yama yalnızca desteklenen dört dal olan 8.2, 8.3, 8.4 ve 8.5 için yayımlanacak. Hangi tam sürümlerin düzeltmeyi içerdiği ve açığın kaç sürüme kadar geriye gittiği yayımla birlikte duyurulacak.

Hemen yama yapamayan ya da desteklenmeyen PHP sürümü kullanan yöneticiler ne yapmalı?​

CERT-EU, düzeltme uygulanana kadar internete açık uygulamaları kamuya açık ağlardan izole etmeyi öneriyor. Bunun yanı sıra siteyi VPN ya da kimlik doğrulamalı erişim arkasına almak, sunucudaki veri ve ayrıcalıkları azaltmak, depolanmış kimlik bilgilerini kaldırmak ve günlüklerin güvenli bir konumda tutulduğunu doğrulamak önerilen adımlar arasında. 8.2 öncesi, ömrünü tamamlamış sürümler için PHP tarafından herhangi bir düzeltme gelmeyecek; bu sistemler için yükseltme, çevrimdışına alma veya izole etme değerlendirilmeli.

21 Ekim itibarıyla PHP2Shell açıklarından yararlandığına dair bir saldırı rapor edildi mi?​

watchTowr'ın 21 Ekim tarihli kaydına göre herhangi bir istismar bildirilmemiş ve açıklar CISA'nın bilinen istismar edilen açıklar kataloğunda yer almıyordu. Yayımlanan kısa bir kavram kanıtı videosu daha sonra kaldırıldı; bağımsız kod denetimi ise dolaşımdaki kavram kanıtı kodunun çalışmadığını belirtti. Ancak bu tablo anlık bir fotoğraf niteliğinde olup değişebilir.