La vulnerabilità individuata da Stefan Esser consente di eseguire codice sulla macchina vittima con i privilegi dell’utente Web (remote code execution). Come riportato su SecurityTracker mandando dati manipolati al Php si può generare un errore nella memoria del php_register_variable_ex() consentendo di eseguire codice.

Per tutti coloro che amministrano Server è consigliabile provvedere ad aggiornare alla versione Php 5.3.10 quanto prima.

Qui trovate l’annuncio ufficiale di Php.

Di fatto questa vulnerabilità da la possibilità di leggere aree/file del WebServer non autorizzate quali il file “/etc/passwd” e similari.

L’applicazione pratica e più semplice di tale vulnerabilità è il seguente codice:

< ?php
 symlink("/etc/passwd", "prova.txt");
 ?>

Se il “safe_mode” del Php era disabilitato nel proprio spazio sarebbe stato creato un link simbolico dal nome “prova.txt” che puntava al contenuto di “/etc/passwd”. In questo modo richiamando dal browser il link simbolico nel seguente modo:

http://<dominio>/prova.txt

avremmo visualizzato a video il contenuto del file “/etc/passwd”. A seconda dell’Hosting questo file può contenere anche le password dell’account web del Cliente e pertanto la gravità della vulnerabilità è elevata.

Nel caso, invece, il safe_mode del Php fosse stato attivo sarebbe stato visualizzato un messaggio di errore che indicava l’impossibilità di eseguire l’operazione a causa della mancanza dei permessi di accesso al file “/etc/passwd”.

Ho provato ad applicare questa tecnica su diversi Hosting dove ho sitarelli o spazi per fare dei test e in base ad alcune configurazioni di sicurezza (privilegi, followsymlink,etc.) si poteva o meno accedere a dati sensibili come, per esempio, visualizzare i file di configurazione di altri domini presenti sullo stesso server dove siamo noi.

Questa vulnerabilità del Php ha fatto nascere alcune discussioni legate ai vari attacchi di massa che si sono verificati lo scorso anno su vari Hosting condivisi noti e meno noti. Dal mio punto di vista è plausibile pensare, quindi, che questa falla abbia dato la possibilità di accedere e violare centinaia di spazi Web rubando informazioni preziose per eventuali ulteriori attacchi.

Link correlati:

Exploit

PHP 5.2.12/5.3.1 symlink() open_basedir bypass – SecurityReason.com

Symlink Attack – HTML.it

Chi utilizzava  una versione precedente ha avuto la possibilità di effettuare l’aggiornamento automatico senza dover stare a scaricare il pacchetto, unzipparlo, uploadarlo via Ftp etc..

Terminato l’aggiornamento  alcuni hanno avuto la triste sorpresa di riscontrare l’errore “500 Internal Server Error” su tutte le pagine del proprio sito. Questa problematica si manifesta negli Hosting (nel mio caso Aruba) dove i permessi di default per avere il corretto funzionamento dei file devono essere impostati a CHMOD 0755 (dovuti all’utilizzo del suExec di Apache) dato che l’aggiornamento automatico comporta il reset dei permessi a CHMOD 0644.

L’errore è facilmente risolvibile reimpostando i permessi CHMOD corretti per tutti i file e cartelle che compongono il WordPress.

La community di WordPress aveva rilasciato già in data 5/12/2008 una modifica da apportare al file “wp-config.php” per evitare il manifestarsi di questo problema.

ARTICOLO ORIGINALE

Tale modifica consente di impostare manualmente i permessi CHMOD di default (attualmente sono a 0644) da assegnare ai file del WordPress in occasione di aggiornamenti o similari.

Per implementarlo è sufficiente seguire questi pochi semplici passi:

1) Aprire con un Editor il file “wp-config.php“;

2) Aggiungere le seguenti due righe in qualsiasi punto del file:

define('FS_CHMOD_FILE',0755);
define('FS_CHMOD_DIR',0755);

Fine! d’ora in poi tutti gli eventuali aggiornamenti automatici assegneranno di default i permessi 0755

Le righe in questione sono le seguenti:

<?
ob_clean();
flush();
?>

Cosa sono?

ob_clean() – E’ il comando che cancella/svuota il contenuto dell’output_buffer senza, però, eliminare il buffer stesso.

flush() -E’ il comando che elimina il buffer.

Perché? Cos’è l’Output Buffer?

Il mio Hosting attuale ha l’output_buffer attivo di default e anche provando a disattivarlo tramite override con php.ini resta comunque abilitato. Solitamente non crea problemi in quanto si tratta di un buffer creato appositamente per migliorare le performance del Web Server e del Php. Una volta, quando ancora avevamo 56K e ISDN eravamo abituati a vedere la pagina caricarsi piano piano, pezzo per pezzo. Appariva il logo, poi il menu e via dicendo si componeva tutta la pagina. Con l’avvento delle attuali ADSL questa situazione non si verifica più, almeno a livello visivo. A livello prettamente tecnico l’intepretazione e la visualizzazione di una pagina Web continuano ad avere questo comportamento.

L’output_buffer server a migliorare tutto ciò aggiungendo un buffer dove viene caricata la pagina prima ancora che venga “servita” al Client, ossia il vostro Browser. In questo modo quello che una volta era il vedere il singolo pezzo caricato ora diventa un’attesa temporale, seppur minima. Utilizzando un buffer è necessario attendere che si riempia tutto prima che vengano inviati i dati al Browser (e quindi prima che iniziate a vedere la pagina visivamente).

Come e Dove?

Da quel che ho scoperto facendo varie prove è consigliato inserire le due righe di codice prima di qualsiasi output della pagina. Io nel caso di WordPress l’ho inserito prima di qualsiasi cosa nella pagina header del mio Template che si trova a questo percorso:

/<root_di_wordpress>/wp-content/themes/<nome del template utilizzato>/header.php

Ho inserito le righe prima della dicitura “<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0…” nel seguente modo:

<?
ob_clean();
flush();
?>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

Risultati

Da quel che ho potuto constatare sul mio sito e su quello di (pochi) altri le performance e soprattuto i tempi di risposta del Server migliorano.

Tengo a precisare che al momento non ho prove “scientifiche”  a sostegno della mia tesi e, quindi, vi invito a provare e se avete voglia ad informarmi dell’eventuale miglioramento (e speriamo non peggioramento) del vostro sito commentate questo post fornendo quante più informazioni possibili.

Il mio attuale Hosting ha il Php configurato come Cgi di Apache e l’output_buffering impostato a 4096.

Configurazione Php come CGI

Configurazione output_buffering a 4096

Ho riscontrato che su alcuni Hosting (Aruba per esempio) quando si clicca su uno degli Eventi presenti alla voce “Prossimamente” va in errore mostrando una pagina simile alla seguente.

Errore nella visualizzazione Eventi di Gcalendar per Joomla

Andando a verificare la pagina segnalata nell’errore ossia

/components/com_gcalendar/hiddenviews/event/tmpl/default.php

si riscontra che la riga che genera l’errore è la seguente dove viene composto l’Url da richiamare per visualizzare in un iframe l’evento direttamente dal Google Calendar.

$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

Analizzando meglio il codice si riscontra che i due campi “scheme” e “host“, da come vengono utilizzati, dovrebbero essere presenti nell’”Array $p” ma, in realtà non esistono e di conseguenza l’Url che viene generato non è corretto.

Non ho potuto effettuare molti controlli ma effettuando una stampa dell’intero “Array $p” ho riscontrato che vi è un solo campo che, tra l’altro, non viene utilizzato all’interno della pagina. Per fare una verifica approfondita andrebbe verificato il popolamento dell’Array che avviene alla riga 12 dello stesso file tramite la seguente riga:

$p= parse_url($this->gcalendar);

Dato che, come detto, non ho avuto la possibilità di effettuare controlli approfonditi ho risolto il problema a monte commentando la riga 14 dove si generava l’errore e aggiungendone una in cui l’Url viene generato “manualmente”. Ecco il codice:

#$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

$url = ‘http://www.google.com’.'/calendar/event?eid=’ . $this->eventID . $this->timezone;

Così facendo il problema, ovviamente, si è risolto.

Sicuramente non è il metodo migliore per “fixare” il problema in quanto si tratta di un accorgimento piuttosto grezzo ma, temporaneamente, funzionante.

Eccovi il file già fixato:

Joomla Gcalendar Components – RAW FIX EVENT VIEW

Data e Luogo

• Giovedì 2 Ottobre 2008 – Torino c/o Algo System sas Via Cernaia, 9
• Martedì 7 Ottobre 2008 – Padova c/o Ecomatica srl via della Croce Rossa,118
• Giovedì 9 Ottobre 2008 – Bari c/o Sistem Data srl Via Bitritto, 114 bis

Programma

• ore 10.00: apertura lavori
• ore 12.30 – 13.30: pausa pranzo
• ore 17.00: termine lezioni

Per maggiori informazioni sui corsi fate riferimento a questa pagina.

Non vi sono consigli veri e propri da dare in merito ma, per mia esperienza personale, l’utilizzo di un “php.ini” con abilitate alcune funzioni quali, ad esempio, la “Compressione Gzip“, permette di diminuire il numero di volte in cui il proprio sito va in Timeout o in errore “500 – Internal Server Error“.

La Compressione Gzip consente di far si che il Server comprima alcuni oggetti delle pagine ottimizzando così le performance in quanto il “peso” generale della pagina risulta ridotto.

Per attivare tale opzione vi sono vari modi ma, sinceramente, io preferisco utilizzare l’override tramite “php.ini”. Tale file contiene tutte le configurazioni del Web Server che sono, praticamente, quelle che vengono visualizzate quando si esegue il comando “phpinfo()” del Php. Per vederlo in azione basta creare e, successivamente, caricare via browser una pagina .php contenete le seguenti righe:

<?php

phpinfo();

?>

Utilizzando un php.ini opportunamente modificato è possibile variare (quando consentito del Provider) alcuni parametri come, ad esempio, il “memory_limit“, il “max_execution_time“, l’”output_buffering“, etc.

A questo link potete leggere tutti i parametri impostabili in tale file e la loro descrizione.

Tornando al discorso “Compressione Gzip” eccovi di seguito il codice da inserire nel vostro “php.ini” per abilitarla.

Io utilizzo il metodo che si appoggia alle Librerie Zlib. Il file “php.ini” per utilizzarle è il seguente:

output_buffering = 4096
output_handler =
zlib.output_compression = On
zlib.output_compression_level = 3
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

Per chi non avesse sbattimento eccovi il file già preparato da copiare nella root del proprio sito (o dove richiesto):

Php.ini – Compressione Gzip On – Librerie Zlib

In alternativa a tale metodo è possibile abilitare la compressione utilizzando le Gzip e, in tal caso, il codice da inserire è il seguente:

output_buffering = 4096
output_handler = ob_gzhandler
safe_mode = Off
max_execution_time = 120
memory_limit = 24M
post_max_size = 8M
register_globals = On
upload_max_filesize = 18M
variables_order = GPCS
disable_functions = system,popen,dl,passthru,proc_open,shell_exec
enable_dl = Off
error_reporting = 6135
expose_php = Off
extension_dir = ./
include_path = “.:/php/lib/php/”
log_errors = On
register_argc_argv = Off
safe_mode_exec_dir =
sendmail_from = me@localhost.com
upload_tmp_dir = “/tmp/”
user_dir = “home”
y2k_compliance = Off

e questo il file già preparato:

Php.ini – Compressione Gzip On – Librerie Gzip

NOTE – Il file “php.ini” ha la particolarità di resettare alle impostazioni di default di Apache le eventuali impostazioni  omesse. Se inserite solo una riga contenente l’impostazione da cambiare le restanti verrebbero resettate ai valori minimi. E’ quindi importante inserire sempre tutte le impostazioni di base necessarie per evitare il crearsi di tale situazione. Il file da me pubblicato vale per il mio Hosting e, quindi, è possibile che su altri Provider crei problemi oppure necessiti di maggiori impostazioni inserite.

Se riscontrate problemi contattatemi tramite i Commenti che provvederò a darvi una mano.

Tale applicativo giunto alla recente versione 2.2.6 scaricabile qui risulta generare un errore presso alcuni Hosting Provider come, per esempio, Aruba nello step 2 dell’installazione quando viene effettuata il check dei requisiti di Sistema.

Solitamente l’errore è un “500 Internal Server Error” causato dal superamento del tempo di Timeout impostato in Apache. Nel file “error_log” questo è l’errore che si riscontra:

[Mon Sep 22 14:18:54 2008] [error] [client xxx.xxx.xxx.xxx] ModSecurity: Output filter: Failed to read bucket (rc 70007): The timeout specified has expired [hostname "<nome_host>"] [uri "<gallery_folder>/install/index.php?step=2"] [unique_id "M2dscH8FFFEDDDryFQ3AAAC5"]

La soluzione migliore sarebbe quella di far variare i limiti di Timeout al proprio Provider ma, visto che è una di quelle richieste che difficilmente vengono esaudite, ho provveduto ad editarmi i file di installazione in modo che indipendentemente da quello che il Server ha o non ha mi dia l’ok per proseguire allo step successivo.

Il file da scaricare per la versione Gallery 2.2.6 è questo: SystemChecksSteps.

A suo tempo li feci anche per la versione Gallery 2.2.5. Eccoli qui:

SystemCheksStep – INSTALLATION 2.2.5

SystemCheksStep – UPGRADE 2.2.5

Va sostituito al posto dell’originale.

Per la versione Installation:

<cartella di gallery>/install/steps/SystemChecksSteps.class

Per la versione Upgrade (solo 2.2.5):

<cartella di gallery>/upgrade/steps/SystemChecksSteps.class

Una volta sostituito si può effettuare la normale installazione (o upgrade) senza problemi.

Tengo a precisare che, come già detto prima, tale file non risolve il problema ma, semplicemente, lo bypassa evitando di far eseguire qualsiasi check. Questo significa che se il Vostro Server non possiede i requisiti necessari per l’utilizzo di Gallery i problemi legati a tale incompatibilità persistono.

Al link seguente troverete l’annuncio ufficiale:

http://developer.joomla.org/security/news/241-20080801-core-password-remind-functionality.html

Questo, invece, quello dal Sito Italiano:

http://www.joomlaitalia.com/content/view/323/90/

Sfruttare tale vulnerabilità risulta alquanto semplice poiché bastano pochi semplici passaggi per eseguire il reset:

1) Una volta individuato il Sito in Joomla caricare questo Url:

/index.php?option=com_user&view=reset&layout=confirm

2) A questo punto apparirà un form che chiederà l’inserimento di un codice che, teoricamente, avreste dovuto ricevere in mail

3) Inserite l’apice (‘) come carattere continuate

4) A questo punto avrete il campo di cambio password e, inserendola, editerete direttamente il profilo Administrator

Il supporto Joomla individuata la vulnerabilità (la variabile token non veniva correttamente verificata) ha provveduto a rilasciare in tempi da record la versione 1.5.6 con tale problema fixato. Dalla sua uscita sono stati scoperti ulteriori vulnerabilità che han portato alla release 1.5.7 in pochi giorni:

Potete scaricare dai seguenti link questa versione:

Joomla 1.5.7 Full Eng

Joomla 1.5.7 Full Ita

Per chi avesse subito un’hacking sfruttando questa vulnerabilità consiglio di aggiornare a questa versione e, nel caso siano ancora visibili “tracce” (home page cambiate) dell’hacker ho notato, per esperienza, che le pagine maggiormente colpite sono 3:

• configuration.php
• index.php (del template attivo nel Cms)
• la cartella “cache” (consiglio di svuotarla)

Provvedete a ripristinare le originali e il problema è risolto.

Dato che trovere il vostro account Admin non accessibile visto che è stata cambiata la password sarà necessario effettuare l’accesso direttamente al PhpMyAdmin e riscrivere la password nel Database.

Una guida a questa operazione la potete trovare qui.

Per chi non avesse sbattimento ho fatto uno scriptino veloce veloce che fa la stessa cosa. Basta copiare il file nella root della vostra installazione Joomla, richiamarlo da Browser e impostare la password.

Il file lo potete scaricare dal seguente link:

Joomla Change Admin Password

Infine, x chi ha molto sbattimento, di seguito la guida a come fixare tale vulnerabilità manualmente.

1. Aprire il file “/components/com_user/models/reset.php”
2. Posizionarsi alla riga 113 dopo la riga “global $mainframe;” ed inserire il seguente codice
   

   if(strlen($token) != 32) {
   $this->setError(JText::_(‘INVALID_TOKEN’));
   return false;
   }

3. Fine dei giochi!