Angrepet er mulig i nginx-konfigurasjoner der videresending til PHP-FPM utføres ved å skille deler av URL-en ved å bruke "fastcgi_split_path_info" og definere PATH_INFO-miljøvariabelen, men uten først å sjekke eksistensen av filen ved å bruke "try_files $fastcgi_script_name" direktivet eller "if (!-f $) document_root$fastcgi_script_name)". Problemet er også
plassering ~ [^/]\.php(/|$) {
fastcgi_split_path_info ^ (. +? \. php) (/.*) $;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass php:9000;
}
Du kan spore løsningen på problemet i distribusjonssett på disse sidene:
try_files $fastcgi_script_name =404;
Problemet er forårsaket av en feil ved manipulering av pekere i en fil
Hvis fastcgi_split_path_info-direktivet spesifiserer å dele skriptbanen ved å bruke et nylinjesensitivt regulært uttrykk (for eksempel foreslår mange eksempler bruk av "^(.+?\.php)(/.*)$"), kan en angriper sørge for at en tomme verdi skrives til PATH_INFO miljøvariabelen. I dette tilfellet, videre langs utførelsen
Ved å be om en URL formatert på en bestemt måte, kan en angriper oppnå en forskyvning av path_info-pekeren til den første byten i "_fcgi_data_seg"-strukturen, og å skrive en null til denne byten vil føre til bevegelse av "char* posen" peker til et tidligere lokalisert minneområde. Den neste kalt FCGI_PUTENV vil overskrive dataene i dette minnet med en verdi som angriperen kan kontrollere. Det spesifiserte minnet lagrer også verdiene til andre FastCGI-variabler, og ved å skrive dataene deres kan en angriper lage en fiktiv PHP_VALUE-variabel og oppnå kjøring av koden deres.
Kilde: opennet.ru