Alfonso Maruccia

FREAK è un problema anche per Windows

La grave vulnerabilità nelle comunicazioni Web cifrate riguarda anche i sistemi operativi Windows, avverte Microsoft. In attesa di una pezza, il rischio può essere mitigato. Mentre su cloud sono dolori

Roma - Microsoft ha pubblicato l'avviso di sicurezza 3046015 riguardante FREAK, la vulnerabilità nelle comunicazioni SSL/TLS generata dalle politiche malsane delle autorità USA e che a quanto pare è in grado di far danni anche sui sistemi operativi Windows supportati ufficialmente.

La falla può essere usata per compromettere i meccanismi di sicurezza del componente Secure Channel (Schannel) che gestisce le comunicazioni Web cifrate su Windows, rivela il bollettino di Microsoft, forzando Internet Explorer o altri browser a fare uso di chiavi crittografiche RSA "deboli", facili da identificare tramite attacchi di forza bruta.

Le indagini di Redmond hanno evidenziato come Schannel sia prono a FREAK, anche se la corporation è lesta nel comunicare che, al momento della pubblicazione dell'avviso 3046015, non risultano noti casi in cui la falla sia stata sfruttata per condurre attacchi contro utenti o aziende.
Microsoft fornisce informazioni su come mitigare il rischio di farsi "bucare" da FREAK, meccanismi come la modifica del Registro su Windows Server 2003 (per inibire lo scambio delle chiavi crittografiche insicure) a cui dovrebbe seguire la distribuzione di una eventuale patch correttiva.

FREAK può far danni sui PC (e soprattutto sui server) basati su OS Windows, ma anche nel campo del FOSS la vulnerabilità sta causando non pochi problemi: la media calcolata dei servizi vulnerabili usati da un'azienda è di 122, mentre i servizi cloud ancora a rischio dopo 24 ore dalla scoperta pubblica del problema sono più di 700. E questo nonostante OpenSSL abbia già chiuso la falla a gennaio.

Alfonso Maruccia
Notizie collegate
18 Commenti alla Notizia FREAK è un problema anche per Windows
Ordina
  • è pur difficile per chi probabilmente non ha capito bene doverlo poi spiegare chiaramente ad altri. Questo articolo ne è la conseguenza.
  • - Scritto da: lalla63
    > è pur difficile per chi probabilmente non ha
    > capito bene doverlo poi spiegare chiaramente ad
    > altri. Questo articolo ne è la
    > conseguenza.

    Cos' è che non hai capito?
    non+autenticato
  • Dev'essere un bel discorso, perchè non si capisce niente!
    non+autenticato
  • - Scritto da: castramacac hi
    > https://blog.lookout.com/blog/2015/03/05/the-state
    >
    > dove sono i macachi adesso? Rotola dal ridere
    e non dimentichiamoci del sempreverde http://www.huffingtonpost.com/2013/09/09/nsa-steve...A bocca aperta
    non+autenticato
  • si staranno cacando sotto...
    non+autenticato
  • L' espressione "sicurezza informatica" è una trollata poco divertente, le implementazioni sono il principale strumento per chi vuol portare a termine attacchi MITM, anche ammesso che l' azienda che affitta il craudde a Giggi sia onesta Rotola dal ridere i dati possono tranquillamente essere spolpati prima del loro arrivo sul server... Mitico!
    non+autenticato
  • il pezzo jsse pare violentemente buggato ("skip-tls"), ma ha fatto poco rumore....
    non+autenticato
  • - Scritto da: bubba
    > il pezzo jsse pare violentemente buggato
    > ("skip-tls"), ma ha fatto poco
    > rumore....

    Perché, un buco in Java da quando è una novità?
    non+autenticato
  • - Scritto da: Sucks
    > - Scritto da: bubba
    > > il pezzo jsse pare violentemente buggato
    > > ("skip-tls"), ma ha fatto poco
    > > rumore....
    >
    > Perché, un buco in Java da quando è una novità?
    mi aspettavo l'obiezione sarcastica (ma sensata)A bocca aperta

    E' che qua' non e' la "solita"Sorride violazione della sandbox, ma una cosina piu' subdola, e -pare[1]- anche parecchio piu' grave[2] della molto strombazzata rsa-export, nonche' presente da altrettanto tempo (o cmq da parecchio)..


    [1] "pare" perche appunto in dettaglio non ho letto niente
    [2] non serve affittare un cluster, cfg il sw per crackare chiavi, ecc..
    non+autenticato
  • Java io lo considero una specie di Basic (Beginners... ecc..) implementare "sicurezza" in Java è volersi fare del male per 2 motivi:

    1) La crittografia e le matematiche (big numbers ecc.) son roba "cpu intensive" in un ambiente dove hai bisogno di performance è il modo più "sicuro" di infilarsi in un collo di bottiglia.
    2) Se trovi il modo di mandare in vacca la implementazione della VM puoi avere scritto la applicazione bene quanto vuoi ma ti hanno "ownato".

    Poi per carità ci si può fare male in tanti modi anche più "facili"...
    Personalmente anche se non userei mai Java consiglio sempre di utilizzare per le "factory" che si occupano di sicurezza almeno un vrapping di librerie native ( in C tanto per capirci) anche se questo è un palliativo dato che il non controllo della memoria a livello di garbage collection rende praticamente impossibile la applicazione di uno dei criteri base della programmazione "sicura" ovvero il "clean mem reuse"... per clean mem reuse si intende il fatto che un pezzo di memoria (o buffer ma tanto è la stessa cosa) debba essere "ripulito o riscritto" prima del rilascio e idem prima del suo utilizzo.
    In questo senso è molto complesso (a meno di non fare VM che abbiano API ad hoc per questo fine) stare "sicuri" con roba non compilata nativamente perchè la gestione del garbage collection è un propblema comune a qualunque tipo di sistema con interpretazioni "runtime" del codice.
    non+autenticato
  • 1. il clean mem reuse di cui parli serve quando non si usano linguaggi managed, cioè linguaggi che implementano controlli sulla reale allocazione di un oggetto puntato da una variabile e soprattutto il bound checking

    2. puoi ownare la vm java così come puoi ownare il microcodice della cpu, stessi problemi, stessi casini

    semmai il problema è che hotspot è scritto da cani e pieno di bug, ma questo non c'entra con la bontà delle soluzioni jit-based
    non+autenticato
  • - Scritto da: collione
    > 1. il clean mem reuse di cui parli serve quando
    > non si usano linguaggi managed, cioè linguaggi
    > che implementano controlli sulla reale
    > allocazione di un oggetto puntato da una
    > variabile e soprattutto il bound
    > checking
    Che cavolo dici?

    1) Credi davvero che le variabili allocate vengano rilasciate in tempo reale?
    E se così fosse cosa è il garbage collection?

    2) il bound check non ha un piffero a che fare con il mem reuse.

    3) la cpu non è ownabile se l'OS è sensato una JVM invece è una normale Applicazione ne più ne meno ( e solitamente non è scritta granchè bene come dimostrano i fatti).

    >
    > 2. puoi ownare la vm java così come puoi ownare
    > il microcodice della cpu, stessi problemi, stessi
    > casini
    >
    > semmai il problema è che hotspot è scritto da
    > cani e pieno di bug, ma questo non c'entra con la
    > bontà delle soluzioni
    > -basejitd
    Veramente in quelle che tu chiami soluzioni "jit based" hai 2 problemi il primo è il codice scritto da cani e il secondo la jvm scritta da cani...
    E i fatti dimostrano che i buchi stanno da ambedue le parti...
    Qui non si parla di reoria ma di pratica.
    Se scrivi bene in nativo puoi fare una applicazione sicura in un OS sicuro se scrivi bene in java ti resta la jvm che è insicura (oltre che lentissima per la crittografia) a prescindere da OS e applicazione.

    E del tutto onestamente ho visto codice scritto coi piedi sia in java che in C ma decisamente il codice scritto in java è scritto in genere molto peggio anche (anzi sopratutto) perchè il livello di professionalità è generalmente più basso.
    non+autenticato
  • Alla fine del tuo intervento hai chiarito tutto, se il codice è scritto da cani dipende dal programmatore e non dal linguaggio.

    Un macinacodice scriverà spazzatura a prescindere dal linguaggio. Il C ha solo il vantaggio che essendo lievemente (tanto) più complesso di Java e quindi fa più selezione.

    Certo però se uno va a guardare quanti danni si possono fare avendo il controllo pieno dell'allocazione della memoria quasi quasi il garbage collector sembra uno dei mali minori.

    La JVM è stata scritta da scimmie ubbriache (almeno alcune parti) ma questo non è direttamente legato con Java (anzi non vorrei dire una cretinata ma la stessa JVM non credo sia stata scritta in java)
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 8 discussioni)