È possibile interrogare gli exploit della riga di comando della stringa nelle vecchie implementazioni CGI di PHP protetti senza aggiornare le versioni di PHP?

Question

È possibile interrogare gli exploit della riga di comando della stringa nelle vecchie implementazioni CGI di PHP protetti senza aggiornare le versioni di PHP?

#1 da (1 voti)

0

Di recente l'abbiamo ricevuto da un controllo di sicurezza:

PHP is a general purpose scripting language that can be embedded into HTML. A vulnerability exists in PHP versions prior to 5.3.12 and 5.4.2 due to improper parsing of query string parameters when configured with a CGI-based setup (e.g., Apache's mod_cgid). Processed query string parameters supplied to an arbitrary PHP file are improperly parsed as command line arguments. Remote attackers could leverage this issue to pass command-line switches (e.g., -s, -c, -n, -f, -r, -B, -R, -F, -E, -t, etc.) to the php-cgi binary and disclose potentially sensitive source code information or execute arbitrary code on vulnerable systems with the privileges of the web server. Successful exploitation requires that the HTTP server complies with section 4.4 (The Script Command Line) of The Common Gateway Interface (CGI) Request for Comments (RFC 3875).

Abbiamo diversi ambienti PHP, tutti in esecuzione come CGI / Fast CGI in IIS. L'aggiornamento di tutte le versioni di PHP è ovviamente la soluzione ideale a lungo termine. Tuttavia, ci vorrà un po 'di tempo, test e pianificazione. Alcuni server sono gestiti da host esterni con i quali stipuliamo contratti, il che complicherà ulteriormente gli aggiornamenti della versione.

Come posso controllare ambienti specifici per questa vulnerabilità? C'è un modo per impedire agli attaccanti remoti di sfruttarlo senza un aggiornamento completo della versione?

php webserver

posta Beofett 19.11.2013 - 16:52

fonte

1 risposta

Leggi altre domande sui tag php webserver

Memoria di autenticazione token e crittografia / hashing Come funzionano gli exploit di applet Java? [chiuso]

score 1 · Accepted Answer

PHP ha pubblicato un bollettino qui:

The PHP development team would like to announce the immediate availability of PHP 5.4.2. This release delivers a security fix.

There is a vulnerability in certain CGI-based setups that has gone unnoticed for at least 8 years. Section 7 of the CGI spec states:

Some systems support a method for supplying a array of strings to the CGI script. This is only used in the case of an 'indexed' query. This is identified by a "GET" or "HEAD" HTTP request with a URL search string not containing any unencoded "=" characters. So requests that do not have a "=" in the query string are treated differently from those who do in some CGI implementations. For PHP this means that a request containing ?-s may dump the PHP source code for the page, but a request that has ?-s&a=1 is fine.
A large number of sites run PHP as either an Apache module through mod_php or using php-fpm under nginx. Neither of these setups are vulnerable to this. Straight shebang-style CGI also does not appear to be vulnerable.

If you are using Apache mod_cgi to run PHP you may be vulnerable. To see if you are just add ?-s to the end of any of your URLs. If you see your source code, you are vulnerable. If your site renders normally, you are not. To fix this update to PHP 5.3.12 or PHP 5.4.2. We recognize that since this is a rather outdated way to run PHP it may not be feasible to upgrade these sites to a modern version of PHP, so an alternative is to configure your web server to not let these types of requests with query strings starting with a "-" and not containing a "=" through. Adding a rule like this should not break any sites. For Apache using mod_rewrite it would look like this:
RewriteCond %{QUERY_STRING} ^(%2d|-)[^=]+$ [NC]
RewriteRule ^(.*) $1? [L]
If you are writing your own rule, be sure to take the urlencoded ?%2ds version into account.

Nota che questo è specifico per mod_cgi su Apache .

Per assicurarti di non essere vulnerabili, verifica se il metodo sopra descritto è applicabile anche ai tuoi server IIS. In tal caso, è necessario assicurarsi che per ogni server IIS sia necessario abilitare url-rewrite e fare sicuro di imitare lo stesso comportamento scritto sopra.

La soluzione a lungo termine non applica la patch al software, l'obiettivo a lungo termine dovrebbe essere un'adeguata gestione delle patch e un migliore controllo del ciclo di vita dello sviluppo del software. Patch come queste dovrebbero essere in grado di essere rilasciate in meno di due settimane (questo è l'obiettivo).

Dovresti anche avere cura di tenere traccia delle vulnerabilità da te, il fatto che il team di audit debba ricordarti delle vulnerabilità critiche dimostra che anche la tua gestione delle vulnerabilità è carente.