Alfonso Maruccia

MySQL vulnerabile con qualsiasi password

Una falla di sicurezza mette a rischio le installazioni MySQL: in talune istanze di MySQL e MariaDB basta ripetere i tentativi di login un numero finito di volte per ottenere l'accesso

Roma - Versioni non recenti di MySQL e MariaDB sono affetti da un problema di sicurezza abbastanza grave, dicono i ricercatori, potenzialmente capace di garantire l'accesso senza particolare fatica da parte di chi attacca: basta ripetere i tentativi di login un numero finito di volte per "aprire le porte" dei server.

La falla, comune sia alla versione "liscia" di MySQL che all'alternativa "open" al sistema di database relazionale di proprietà di Oracle, consiste in un problema nella verifica delle password con la funzione memcmp: nelle installazioni affette dal problema c'è una possibilità su 256 che ripetendo i tentativi di login con un nome utente noto (come ad esempio il classico "root" di default) si riesca ad accedere ai server senza la necessità di conoscere la password reale.

La falla ora descritta è stata in realtà già tappata sia in MySQL che MariaDB, e i ricercatori considerano vulnerabili le versioni dei due software fino alle release 5.1.61, 5.2.11, 5.3.5 e 5.5.22. Vulnerabili anche diverse versioni di Ubuntu Linux (10.04, 10.10, 11.04, 11.10 e 12.04), Fedora, OpenSUSE 12.1.
Anche in questo caso il consiglio maggiormente dispensato è quello di aggiornare (o far aggiornare, nel caso di server "hosted") al più presto sistemi operativi, build Linux e binari MySQL/MariaDB. Per dare un'idea del rischio corso da utenti e aziende, i ricercatori che hanno descritto la falla hanno identificato quasi 900mila server MySQL (oltre la metà di quelli scansionati) come vulnerabili all'attacco.

Alfonso Maruccia
Notizie collegate
  • TecnologiaMariaDB, cresce l'alternativa a MySQLNuova versione per il fork nato dopo l'acquisizione di Sun da parte di Oracle. Gli sviluppatori promettono maggiore velocità, nuove funzionalità e compatibilità assoluta con il progenitore
47 Commenti alla Notizia MySQL vulnerabile con qualsiasi password
Ordina
  • E c'è chi dice che non serve a niente farlo, vai a scovare un nome utente valido!
    Shiba
    4018
  • perche' tutta l'attenzione e' concentrata solo sull'accesso diretto al db via tcp/3306 ? non si puo exploitare questa vulnerabilita' attraverso innumerevoli frontend web (invece di cercare una sql injection) ??


    PS: quello che non mi sfugge, purtroppo, e' leggere i commenti sinora pubblicati... quasi tutti ridicoli (a parte quello che considera GIUSTAMENTE una idiozia esporre l'accesso tcp diretto al db) ...
    Mi riferisco alla solita flamewar postgres vs mysql .. giusto 2 gg fa e' uscito un security patch che fixava 2 vuln di postgres
    Non parliamo poi di oracle.. il blob di patch che fixava anche quella di mysql , uscita mi pare a meta' aprile, conteneva una marea di fix anche di prodotti nativi Oracle (oltre che quelli acquisiti da sun)... ironicamente il binario prodotto da Oracle di mysql (buggato) non triggerava la vuln (perche non compilato con le glibc-sse )
    non+autenticato
  • A tutti quelli che dicono che MySql non è un db serio, chiedo Facebook che Db usa?

    Detto questo anche io tifo per Apache DerbyOcchiolino

    A parte gli scherzi, questo vuole essere uno spunto di riflessione, niente da dire contro la qualità di PostgreSQL.
    non+autenticato
  • Mi sono dimenticato questo:
    http://royal.pingdom.com/2010/06/18/the-software-b.../

    Come vedete più che il DB è importante usare l'intelligenza... se poi non la avete c'è sempre Oracle.
    non+autenticato
  • - Scritto da: poiuy
    > Mi sono dimenticato questo:
    > http://royal.pingdom.com/2010/06/18/the-software-b

    Sarebbe bello vedere i numeri aggiornati, ma già al 2010 era impressionante
    Funz
    12995
  • bisogna sempre prendere con le pinze queste notizie

    ho testato tutti i miei server, raggiungibili dall'esterno, che montano release di MySQL precedenti a quelle indicate nell'articolo, senza riscontrare nessun problema

    In linea statistica, un tentativo ogni 256 deve riuscire ma dopo aver effettuato quasi cinquantamila tentativi non riesco ancora a entrare
    non+autenticato
  • > In linea statistica, un tentativo ogni 256 deve
    > riuscire ma dopo aver effettuato quasi
    > cinquantamila tentativi non riesco ancora a
    > entrare
    E' perche usi la password giusta, prova con quelle sbagliate.

    Cmq. mysql lo puoi pure prendere con le pinze, basta che lo butti nel bidone poi.....
    non+autenticato
  • - Scritto da: daniele_dll
    > bisogna sempre prendere con le pinze queste
    > notizie
    NO. non c'e' nessuna pinza da prendere. la cosa e' molto chiara.
    MySQL sino a 5.1.61, 5.2.11, 5.3.5, 5.5.22 e' buggato.
    MA la vuln NON viene triggerata (quindi defacto non exploitabile) SE mysql NON e' compilato con la glibc ottimizzata per SSE [*].... questo perche la funzione memcmp ,"pietra dello scandalo", restituisce valori diversi nei due casi... e mysql ha errato nell'assumere come buono un determinato valore (son restato sul vago, leggi le dox vere per i dettagli).
    [*] Ovviamente non si escludono altre casistiche possibili...
    non+autenticato
  • si, avevo letto la documentazione, e proprio per questo ho detto che andava presa con le pinze!
    il problema non sta tanto in MySQL ma nelle GLIBC in quanto la versione ottimizzata per le SSE (non è mysql che decide quale usare, e chi imposta i flag di compilazione delle glibc)
    L'indicazione che la versione SSE della funzione memcmp da valori non conformi a quella non ottimizzata dove sta scritta? ad esempio ho guardato nelle man pages e li non c'è niente

    - Scritto da: styx
    > - Scritto da: daniele_dll
    > > bisogna sempre prendere con le pinze queste
    > > notizie
    > NO. non c'e' nessuna pinza da prendere. la cosa
    > e' molto
    > chiara.
    > MySQL sino a 5.1.61, 5.2.11, 5.3.5, 5.5.22 e'
    > buggato.
    > MA la vuln NON viene triggerata (quindi defacto
    > non exploitabile) SE mysql NON e' compilato con
    > la glibc ottimizzata per SSE [*].... questo
    > perche la funzione memcmp ,"pietra dello
    > scandalo", restituisce valori diversi nei due
    > casi... e mysql ha errato nell'assumere come
    > buono un determinato valore (son restato sul
    > vago, leggi le dox vere per i
    > dettagli).
    > [*] Ovviamente non si escludono altre casistiche
    > possibili...
    non+autenticato
  • 50.000 tentativi???
    Avresti fatto prima ad aggiornare i tuoi server...
    non+autenticato
  • - Scritto da: ...
    > 50.000 tentativi???
    > Avresti fatto prima ad aggiornare i tuoi server...

    ma anche no, visto che sono sistemi di hosting e se ci sono problemi con l'aggiornamento scoppia il finimondo

    quando si fanno gli aggiornamenti devono essere cose organizzate e soprattutto vanno testati per assicurarsi che tutto funzioni ancora ... casi estremi a parte ... motivo per il quale ho fatto i tentativi
    non+autenticato
  • Ma c'è qualche "ganzo" mysqllista che espone l'accesso al server MySQL da remoto?
    Ora se uno ha il serverino in casa con l'adsl e non mette
    firewall o altro allora il bug potrebbe essere preoccupante.
    Ma per la gente "seria" con una DMZ, con i db non acessibili
    dall'esterno, ecc.. ecc.. ecc... tale bug non è un
    problema grosso grosso ... forse per qualche ISP "cialtrone" si.
    E cmq, Mysql, windows e sltro sono solo dei giocattoli che si
    sono diffusi solo per politiche commerciali (postgresql all'inizio
    non era disponibile sotto windowS) e non per le loro funzionalità
    Volete un rdbms serio? PostgreSQL!
    non+autenticato
  • - Scritto da: flavio c
    > Ma c'è qualche "ganzo" mysqllista che espone
    > l'accesso al server MySQL da
    > remoto?
    > Ora se uno ha il serverino in casa con l'adsl e
    > non mette
    >
    > firewall o altro allora il bug potrebbe essere
    > preoccupante.
    > Ma per la gente "seria" con una DMZ, con i db non
    > acessibili

    Forse vivi su un mondo tutto tuo personale -.-'

    non vedo perché, visto che è possibile definire nome utente, password e pure l'indirizzo sorgente di connessione, non si dovrebbe dare accesso all'esterno

    le stesse probabilità di trovare un bug del genere, ci sono anche per l'ssh, l'ftp, e qualsiasi webapplication ... così come qualsiasi software che tu stai usando ... proprio perché si parla di BUG

    > E cmq, Mysql, windows e sltro sono solo dei
    > giocattoli che si sono diffusi solo per
    > politiche commerciali (postgresql all'inizio
    > non era disponibile sotto windowS) e non per le
    > loro funzionalità
    > Volete un rdbms serio? PostgreSQL!

    ho capito, tu sei il tipo che spara alle mosche con la bomba nucleare ... buon per te ^^
    non+autenticato
  • >
    > ho capito, tu sei il tipo che spara alle mosche
    > con la bomba nucleare ... buon per te
    > ^^
    No, probabilmente e' solo uno sviluppatore sensato.
    non+autenticato
  • - Scritto da: Basta Basta pirateria
    > >
    > > ho capito, tu sei il tipo che spara alle
    > mosche
    > > con la bomba nucleare ... buon per te
    > > ^^
    > No, probabilmente e' solo uno sviluppatore
    > sensato.
    Naaahh, direi con assoluta certezza che è un trollone come te
    non+autenticato
  • certo, quando ci sono le corruzioni a causa di una mancanza di corrente viene la fatina dei denti che come lavoro parttime ripara i db di pgsql

    -.-'

    il fatto che TU non vedi le riparazioni e/o tool di riparazione non significa che non c'è ne siano

    INFATTI per INNODB, l'engine di MySQL che uso in quanto sarei un pirla ad usare MyISAM, non ha tool ESTERNI di riparazione, ma ovviamente le riparazioni se le fa da solo senza interventi esterni

    - Scritto da: Basta Basta pirateria
    > >
    > > ho capito, tu sei il tipo che spara alle
    > mosche
    > > con la bomba nucleare ... buon per te
    > > ^^
    > No, probabilmente e' solo uno sviluppatore
    > sensato.
    non+autenticato
  • CosaaaaaaA bocca aperta

    Spero che tu non lo faccia sui pc dei clienti. Per la cronaca: in caso di problemi 8intrusioni non autorizzate) potrebbero con le normative in vigore da un paio d'anni anche pensare di passare a vie legali per una cosa del genere!!!! Occhio!!!! Se trovo il link te lo posto (non si trattava di mysql ma di Oracle per la cronaca)
    non+autenticato
  • quando leggo queste sparate mi fate ridere veramente

    senti, ma se il BUG invece di stare in MySQL stava nel software che usavi per accedere a MySQL (che internamente ha le sue credenziali di accesso) che cosa sarebbe cambiato?

    assolutamente NULLA ... solo che invece di sparare stupidaggini su MySQL le avreste sparate su XYZ

    tra l'altro, hai letto le specifiche della vulnerabilità? E' un problema che si verifica SOLO su linux e SOLO con quando le GLIBC sono compilate con le ottimizzazioni SSE e questo perché la funzione in questione restituisce un range di valori differenti rispetto a quella non ottimizzata e/o per altre piattaforme (così come rispetto ad altre implementazioni)

    - Scritto da: crumiro
    > CosaaaaaaA bocca aperta
    >
    > Spero che tu non lo faccia sui pc dei clienti.
    > Per la cronaca: in caso di problemi 8intrusioni
    > non autorizzate) potrebbero con le normative in
    > vigore da un paio d'anni anche pensare di passare
    > a vie legali per una cosa del genere!!!!
    > Occhio!!!! Se trovo il link te lo posto (non si
    > trattava di mysql ma di Oracle per la
    > cronaca)
    non+autenticato
  • - Scritto da: daniele_dll
    > quando leggo queste sparate mi fate ridere
    > veramente

    Invece quando ho letto quello che hai scritto tu mi viene da piangere.

    >
    > senti, ma se il BUG invece di stare in MySQL
    > stava nel software che usavi per accedere a MySQL
    > (che internamente ha le sue credenziali di
    > accesso) che cosa sarebbe
    > cambiato?

    Assolutamente nulla, ma avresti interposto comunque un layer tra il mondo ed i tuoi dati. Leggerissima diversità che può salvarti il deretano in caso di accessi non autorizzati.

    >
    > assolutamente NULLA ...

    Leggi sopra.

    > solo che invece di
    > sparare stupidaggini su MySQL le avreste sparate
    > su
    > XYZ

    Ho usato MySql da quando è SUN ed ho pure (indirettamente, a dire il vero) contribuito al codice. Ma qui o fanboy o niente?

    >
    > tra l'altro, hai letto le specifiche della
    > vulnerabilità? E' un problema che si verifica
    > SOLO su linux e SOLO con quando le GLIBC sono
    > compilate con le ottimizzazioni SSE e questo
    > perché la funzione in questione restituisce un
    > range di valori differenti rispetto a quella non
    > ottimizzata e/o per altre piattaforme (così come
    > rispetto ad altre
    > implementazioni)

    Senti: io ti ho solo dato un consiglio. Poi fai quello che hai voglia.
    Ne ho conosciuto uno ultimamente che voleva trasferire dati da una clinica ad un db centralizzato con questo sistema.
    Ti lascio indovinare cosa gli è successo.

    >
    > - Scritto da: crumiro
    > > CosaaaaaaA bocca aperta
    > >
    > > Spero che tu non lo faccia sui pc dei
    > clienti.
    > > Per la cronaca: in caso di problemi
    > 8intrusioni
    > > non autorizzate) potrebbero con le normative
    > in
    > > vigore da un paio d'anni anche pensare di
    > passare
    > > a vie legali per una cosa del genere!!!!
    > > Occhio!!!! Se trovo il link te lo posto (non
    > si
    > > trattava di mysql ma di Oracle per la
    > > cronaca)
    non+autenticato
  • - Scritto da: daniele_dll
    > Forse vivi su un mondo tutto tuo personale -.-'
    >
    > non vedo perché, visto che è possibile definire
    > nome utente, password e pure l'indirizzo sorgente
    > di connessione, non si dovrebbe dare accesso
    > all'esterno
    >
    > le stesse probabilità di trovare un bug del
    > genere, ci sono anche per l'ssh, l'ftp, e
    > qualsiasi webapplication ... così come qualsiasi
    > software che tu stai usando ... proprio perché si
    > parla di BUG

    Prego ????

    Cioè con i rischi che ci possano essere bug che permettono accessi indiscriminati ad un db ed al suo contenuto te ti fidi della sicurezza integrata del db server ?

    Guarda io lavoro in ambito medicale e con tutte le normative di rispetto della privacy che ci sono se facessimo una cosa del genere ai nostri clienti i contratti che abbiamo li userebbero per arrotolarsi della maria, ma tutto questo è tranquillamente riportabile in qualsiasi ambito dove ci sono in ballo dati sensibili, progetti coperti da segreto industriale, dati di fatturato/vendita/marketing e chi più ne ha più ne metta.
    mura
    1720
  • Sono interessato all'argomento.
    Il mio capo, che di informatica ci smanetta ma ci capisce una mazza (l'importante è che le cose funzionino) ha fatto in modo che i database MySql fossero raggiungibili dall'esterno utilizzando l'indirizzo ip pubblico e la porta 3306. Io gli ho detto che stavamo facendo una cazzata e che siamo a rischio, ma non mi ha voluto sentire.
    In questo caso (necessita che un programma dall'esterno si colleghi ai dati) cosa avremmo dovuto fare?
    Io che in questo campo informatico ci capisco poco e sono contrario alla sua massima (l'importante è che funzioni) gli avevo suggerito di fare un programma che esportasse ogni tot minuti i dati che ci interessavano su file xml. Magari questa soluzione è peggio della prima.
    Non è il mio campo, ma sono curioso.

    Grazie, ciao.
    non+autenticato
  • Database raggiungibili direttamente da remoto per me è orripilante come idea.
    Costa poco mettere su una vpn. Ti colleghi alla vpn e fai quel che vuoi.
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)