Alfonso Maruccia

GHOST, la falla coinvolge anche WordPress

Cresce la lista delle piattaforme potenzialmente vulnerabili al bug della libreria C di Linux, un problema che preoccupa, ma che al momento non conta su prove concrete di attacchi

Roma - Oltre a rendere vulnerabili i sistemi operativi Linux e i server email, la vulnerabilità nota come GHOST è anche potenzialmente in grado di mettere a rischio le applicazioni scritte in PHP. Su tutte, la piattaforma di blogging WordPress è quella che desta maggior preoccupazione.

GHOST è una falla derivante da un errore di buffer overflow nella GNU C Library integrata su Linux, un componente essenziale per qualsiasi sistema basato sul kernel del Pinguino e che rende vulnerabili distro molto popolari come CentOS, Red Hat Enterprise Linux, Fedora 5-7, Ubuntu 12.04 e altre ancora.

I ricercatori di sicurezza avevano sin qui parlato di un codice proof-of-concept in grado di trasformare la falla in una minaccia sui server email, Exim, per cui basta l'invio di una mail malformata per aprire una shell remota e compromettere il server.
Ma la funzione della libreria C fallata di GHOST ("gethostbyname()") viene utilizzata anche su PHP, dicono i ricercatori, e quindi l'onnipresente linguaggio di scripting rappresenterebbe l'ennesima piattaforma colpita dagli effetti vulnerabilità. In teoria basta usare una URL malformata per il pingback su un blog WordPress, dicono i ricercatori, per ottenere l'accesso al server.

PHP e WordPress sono quindi vulnerabili a GHOST come Linux e i server email, ma passando dalla teoria alla pratica il rischio va ricalcolato: al momento non si conoscono casi specifici di attacchi capaci di sfruttare la falla, segno del fatto che le difficoltà da superare per creare un exploit funzionante hanno fatto da argine alla minaccia prima di una sua diffusione "virale".

Alfonso Maruccia
Notizie collegate
  • SicurezzaGHOST, la falla che aleggia su LinuxIl kernel del Pinguino è affetto da una vulnerabilità particolarmente grave, facile da sfruttare per compromettere anche i server più sicuri. Le patch sono già pronte, l'aggiornamento è più che consigliato
21 Commenti alla Notizia GHOST, la falla coinvolge anche WordPress
Ordina
  • - Scritto da: Taphex Win
    > Rotola dal ridere

    Eh no! Quello sicuro è il kernel!
    Questo bug può rendere i server bucati come nemmeno il Gran Sasso, ma vuoi mettere la soddisfazione di poter comunque urlare "ma non è il kernel!111" con le lacrime agli occhi?
    non+autenticato
  • - Scritto da: il piu grande comico vivente
    > Eh no! Quello sicuro è il kernel!
    > Questo bug può rendere i server bucati come
    > nemmeno il Gran Sasso, ma vuoi mettere la
    > soddisfazione di poter comunque urlare "ma non è
    > il kernel!111" con le lacrime agli
    > occhi?

    che poi tecnicamente parlando è il kernel bucato, perché se da una chiamata di libreria riesci a ottenere i privilegi di kernel, come appunta succede con questa falle, allora vuol dire che è il kernel ad essere buggato. Il codice tecnicamente esegue nel contesto del kernel, quindi contrariamente a quanto dicono i linari, è una falla di linux
    non+autenticato
  • - Scritto da: malina


    > che poi tecnicamente parlando è il kernel bucato,
    > perché se da una chiamata di libreria riesci a
    > ottenere i privilegi di kernel, come appunta
    > succede con questa falle, allora vuol dire che è
    > il kernel ad essere buggato. Il codice
    > tecnicamente esegue nel contesto del kernel,
    > quindi contrariamente a quanto dicono i linari, è
    > una falla di linux

    Mi passi un proof of concept che dimostri la tua teoria ?
    non+autenticato
  • - Scritto da: Pixel
    > Mi passi un proof of concept che dimostri la tua
    > teoria
    > ?

    non serve un poc, basta vedere con ps in che contesto gira la libc: kernel!
    non+autenticato
  • - Scritto da: malina
    > - Scritto da: Pixel
    > > Mi passi un proof of concept che dimostri
    > > la tua teoria ?

    > non serve un poc, basta vedere con ps in che
    > contesto gira la libc: kernel!

    Come ti fanno notare anche altri non basta. A meno che, naturalmente, non mi dimostri il contrario.
    non+autenticato
  • - Scritto da: malina

    > non serve un poc, basta vedere con ps in che
    > contesto gira la libc:
    > kernel!

    HAHAHAHAHAHAHAHA cosa??????

    la libc gira in kernel mode? ma che 'azzo stai addì???

    la libc, in quanto libreria, gira nello stesso contesto del processo che l'ha richiamata

    e no, nessun processo utente gira in kernel mode o ha qualsivoglia tipo di accesso allo spazio d'indirizzamento del kernel
    non+autenticato
  • teoria sbagliata, se fosse come dici tu otterresti l'accesso a root con privilege escalation, invece ammesso che l'exploit funziona e che non ci siano strumenti come appmor, selinux, grsecurity che potrebberro ostacolare l'exploit, ti ritroveresti solo i permessi dell'utente specifico del server mail, quindi potresti manomettere soltanto esso, e dovresti trovare altri buchi aperti, altri exploit, il fatto che linux sia mediamente sicuro non significa che in ambito server non vanno prese ulteriori misure di sicurezza, come linux container che aggiungerebbe un ulteriore ostacolo.
    non+autenticato
  • mamma mia, mamma mia, devo correggere questa serie di castronerie ( altrimenti qualche studente magari le legge e poi le va a raccontare al suo professore di sistemi operativi )

    1. questa falla non permette la privilege escalation

    2. questa falla permette l'iniezione ed esecuzione di codice da remoto NEL CONTESTO E CON I PRIVILEGI DEL PROCESSO CHE VIENE BUCATO https://access.redhat.com/articles/1332213

    3. il contesto del kernel ( come lo chiami tu ) non è l'esecuzione con privilegi di root ( sono due cose completamente separate e che stai confondendo alla grande )

    quindi caro amico, leggi prima qualche libricino come il Tanenbaum prima di sparare vaccate su un forum
    non+autenticato
  • Fincè i sistemi operativi saranno scritti da essere umani difficilmente un S.O. sarà sicuro al 100% . Chi dice il contrario non sa quello che dice, oppure è un markettaro...
    non+autenticato
  • stessa cosa si può dire delle applicazioni....
    non+autenticato
  • il massimo risultato per ora ottenuto, con XML-RPC e pingback attivi, e' far crashare il sw.... interessante, ma non molto utile per i mass-exploiter lameroni...

    (ovviamente e' ora di fare un apt-get update ....)
    non+autenticato
  • Ricordiamoci, è la libreria, non il kernel. E nessun attacco ancora noto, e mai ci sarà. E se c'è è l'amministratore che è un incapace.
    non+autenticato
  • Se compili un programma con una libreria buggata allora anche il tuo programma rischia di essere afflitto dallo stesso bug. Se l'interprete del PHP e' scritto in C allora anche le chiamate gethostbyname() rischiano di essere buggate. Se un programma buggato (web server, mail server, interprete, ecc.. ) gira con permessi elevati allora rischi di avere un sistema compromesso. E' un rischio da non sottovalutare sopratutto per la disclosure di informazioni sensibili: mail utenti, siti web condivisi, ecc..
    non+autenticato
  • - Scritto da: Massimo

    > allora rischi di avere un sistema compromesso. E'
    > un rischio da non sottovalutare sopratutto per la
    > disclosure di informazioni sensibili: mail
    > utenti, siti web condivisi,
    > ecc..

    si paga lo scotto di non utilizzare un sistema di sandboxing dei processi come fa Android

    ma c'è chi lo sa e sta provvedendo, come ad esempio Canonical con Ubuntu Core Snappy
    non+autenticato
  • - Scritto da: Acciderbole
    > Ricordiamoci, è la libreria, non il kernel.

    è uguale, ti sfonda lo stesso il kernel essendo la chiamata eseguita a livello kernel.
    non+autenticato
  • - Scritto da: malina
    > - Scritto da: Acciderbole
    > > Ricordiamoci, è la libreria, non il kernel.

    > è uguale, ti sfonda lo stesso il kernel essendo
    > la chiamata eseguita a livello kernel.

    http://punto-informatico.it/b.aspx?i=4218859&m=421...
    non+autenticato
  • - Scritto da: malina
    > - Scritto da: Acciderbole
    > > Ricordiamoci, è la libreria, non il kernel.
    >
    > è uguale, ti sfonda lo stesso il kernel essendo
    > la chiamata eseguita a livello
    > kernel.

    uguale manco un po visto che se non riesci a trovare un servizio attaccabile che gira su root non lo vedi manco da lontano il kernel, al massimo puoi far crashare un servizio
    non+autenticato