Vulnerabilità critica su Glibc mette a rischio sistemi Linux: rilasciato il fix
Google e Red Hat hanno scoperto in maniera indipendente una vulnerabilità di sicurezza introdotta su un aggiornamento della libreria glibc del 2008
di Nino Grasso pubblicata il 17 Febbraio 2016, alle 12:31 nel canale SicurezzaGlibc, la stessa libreria GNU C alla base della vulnerabilità GHOST scoperta l'anno scorso, è potenzialmente suscettibile ad un'altra falla critica che coinvolge quasi tutte le macchine basate su Linux ed anche alcuni framework di rete dove viene usato il codice. Vecchia e attiva da parecchi anni, la vulnerabilità è stata scoperta da Google e Red Hat e divulgata solamente lo scorso martedì dopo essere stata corretta. Al momento in cui scriviamo è infatti disponibile una patch correttiva.
La falla è stata introdotta nel 2008 all'interno della libreria GNU C, collezione di codici open-source utilizzati in svariate applicazioni stand-alone e da parecchie distribuzioni di Linux, incluse quelle pensate per soluzioni embedded o router. Una delle funzioni utili per il lookup di DNS e nomi dominio contiene un bug di buffer overflow il quale consente ad aggressori esterni di eseguire codice malevolo in situazioni determinate e circoscritte. L'exploit può essere eseguito quando sistemi o app affetti dal bug sono vittime di attacchi man-in-the-middle o eseguono ricerche su domini o DNS controllati dall'aggressore.
I maintainer di glibc hanno già rilasciato una patch che corregge la vulnerabilità e le operazioni di aggiornamento per chi gestisce hardware o software basati su Linux sono di fatto estremamente consigliate. Ma se per i gestori di server Linux l'aggiornamento richiede la semplice installazione del pacchetto, la situazione potrebbe non essere così immediata per altri tipi di utenti che usano applicazioni o servizi attualmente affetti dal bug. Questi infatti devono attendere che le singole app vengano ricompilate con le nuove glibc aggiornate, processo che potrebbe non essere così rapido e che dipende dagli sviluppatori di applicazioni e dai produttori hardware.
In attesa degli aggiornamenti i gestori di sistemi potenzialmente a rischio possono proteggersi con una procedura assolutamente temporanea che Google ha specificato nelle scorse ore: "La vulnerabilità si basa su una risposta UDP o TCP sovradimensionata (2048 o più byte). Il nostro suggerimento per mitigare il problema è quello di limitare la risposta (con DNSMasq o programmi simili) a dimensioni accettate dal resolver DNS a livello locale e assicurarsi che le query DNS vengano inviate solo a server DNS che limitano le dimensioni di risposta UDP".
Il bug è presente nella versione gblic 2.9 rilasciata nel mese di maggio del 2008, ma è stato scoperto e riportato ai maintainer solo lo scorso mese di luglio. In base a quanto è possibile leggere dai documenti rilasciati pubblicamente, sembra che la falla non sia mai stata sfruttata pubblicamente. Adesso che è stata resa pubblica, tuttavia, l'aggiornamento è assolutamente consigliato visto che eventuali aggressori potrebbero prendere di mira i sistemi ancora vulnerabili. L'attacco però non è dei più semplici.
Google ha infatti commentato che "l'esecuzione di codice da remoto è possibile, ma non è così semplice. Per farlo è necessario ad esempio bypassare le soluzioni di sicurezza presenti sul sistema, come ad esempio ASLR". Ricordiamo che Android è basato su Linux ma non utilizza glibc, ma un sostituto chiamato Bionic. Il sistema operativo del robottino verde è quindi di fatto invulnerabile e assolutamente esterno alla falla di sicurezza. Maggiori informazioni possono essere trovate a questo indirizzo.
Recensione Samsung Galaxy Z Fold7: un grande salto generazionale 
The Edge of Fate è Destiny 2.5. E questo è un problema
Ryzen Threadripper 9980X e 9970X alla prova: AMD Zen 5 al massimo livello
'Il realismo ha rovinato i videogiochi' secondo un ex sviluppatore di The Last of Us: esplode la polemica
Crollano anche i TV QLED Hisense: c'è un 65" a 532€ e un 55" a 359,98€, ma TCL risponde coi mini LED
Photoshop 2025: le nuove funzioni AI che cambiano per sempre il fotoritocco
Qualcomm cresce, ma la CPU per datacenter è un'incognita: arriverà troppo tardi?
Gli iPhone in offerta oggi? C'è il 16 128GB bianco, azzurro e verde a 769€, solo 639€ per il 16e 128GB bianco
L'evoluzione di Revolut: arrivano anche le eSIM per navigare ovunque! Ecco come funzionano
Microsoft entra nel club dei 4.000 miliardi: svelati i ricavi di Azure dopo 15 anni, da non credere
Ufficiale, Google firmerà il Codice di condotta europeo sull'IA: non era così scontato
Mettereste una NPU dedicata all'intelligenza artificiale nel vostro PC? AMD sta valutando l'idea
I nuovi iPhone 17 costeranno di più: si salverà solo un modello
Zuckerberg: 'Chi non indosserà smart glasses sarà in svantaggio cognitivo'
La scopa elettrica bestseller super accessoriata torna a 104€, quella con cavo e più potente a 89€ con coupon
Amazon, svendite pesanti di 11 TV OLED: LG serie C4 (55" a 854€) e G4, Samsung e Hisense, affari unici per gli appassionati
Xbox: dal prossimo mese verifica dell'identità obbligatoria in UK, in futuro anche in altre regioni
44 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoNon voglio trollare..ma da profano leggo spesso di queste vulnerabilità, gravi e meno gravi, scoperte adesso ma che erano presenti da molti anni e mi chiedo: non è che le vulnerabilità (che una volta scoperte vengono prontamente sistemate) sono sempre state poche su Linux solo perchè erano in pochi che le cercavano, a dispetto dei "molti occhi" che possono leggere il codice?
Ripeto, non sto trollando ma vorrei sapere se solo io lo penso...
Dal 2008 a oggi sono più di 7 anni, possibile che i 10.000 occhi che osservano il codice non si sono accorti? (slogan dei mille occhi che sento da tempo) chi si è accorto sono 2 Aziende di grosse dimensioni come Google e Red Hat?
Possibile che questa falla presente nella libreria GNU C, collezione di codici open-source utilizzati in svariate applicazioni stand-alone e da parecchie distribuzioni di Linux, incluse quelle pensate per soluzioni embedded o router è passata completamente inosservata per tanti anni?
Chissa che ne pensa Battilei
...che in ogni caso sono sempre di piu' di quelli che _non_possono_ leggere il codice proprietario non disponibile di altri fornitori :P
E' un discorso che non tutti percepiscono: il software non e' figo perche' e' open source bensi' quando tanti ci lavorano liberamente e' figo, quindi deve essere open source.
E' come mysql e postgresql: mysql era open source ma gestito da un solo operatore e quando questo e' stato fatto fuori sono stati (e sono ora) dolori.
Ergo: non e' che se domani MS rilascia i sorgenti (impossibile: chissa' cosa c'e' dentro) improvvisamente diventa sicuro e forkabile. E' sicuro quando sottoposto a molteplici reviews e "dependable" quando ha dietro una community che lo conosce e lo sviluppa.
Ripeto, non sto trollando ma vorrei sapere se solo io lo penso...
No le falle scoperte di linux più o meno sono sempre sullo stesso numero dal 2004, indipendentemente dalle percentuali e indipendentemente da quanti o chi le vedono
http://www.cvedetails.com/product/4...ml?vendor_id=33
Ci sono stati giusto alcuni picchi negli anni in cui qualche azienda ha investito in Linux (2005 Ubuntu e 2013 Valve)
In ogni caso la falla dell'articolo (come specificato dallo stesso articolo anche) non è del kernel Linux direttamente ma di un componente della parte del sistema GNU, appunto Glibc, che poi unita al kernel forma il sistema GNU/Linux
(Ecco, ora mi sento Stallman per aver fatto questa precisazione :asd
Certe notizie per alcuni utenti sono come quando perde la Juve.
Uno ci spera. Così poi può festeggiare....
Ripeto, non sto trollando ma vorrei sapere se solo io lo penso...
Sì è esattamente così: prima Linux praticamente non lo usava nessuno ora inizia ad essere leggermente più usato dalle grandi aziende e si scopre che è un colabrodo!
Il problema è che le grandi corporation hanno pensato bene di dismettere i loro "veri" OS per affidarsi a Linux perché "è gratis" e il risparmio è stato doppio visto che hanno licenziato il loro intero team di sviluppo (AIX è morto, Solaris è morto, ...)! Peccato che il codice Open Source - in realtà - tra il fatto che sarà codice illeggibile / incomprensibile e tra che nessuno ne ha voglia non viene guardato, ma solo visto!
Lo slogan è "Compila? Dunque funziona!" e via che si mergia!
E` la stessa cosa di OpenSSL era piena di bachi ed era un codice senza senso eppure tutti lo usavano! Qualcuno lo aveva mai guardato?
P.S. A onor del vero anche se Android ha forkato completamente il kernel Linux (e Google ne ha riscritto una buona parte probabilmente) e usa Bionic non è invulnerabile (come Superman :Prrr
E infatti è risaputo anche che molti, scelgono il più sicuro.
Delle altre "pippe" sulla percentuale di mercato, percentuale di sicurezza, del perché e del percome non interessa nulla di nulla a nessuno.
Quindi mi viene da ridere quando un affezionato ai sistemi Microsoft si fionda su notizie come queste e cercare il suo momento di gloria.
Ripeto, non sto trollando ma vorrei sapere se solo io lo penso...
Basterebbe semplicemente essere obiettivi e accettare l'idea che il software in quanto fatto da esseri umani può essere soggetto ad errori.
L'open source consente di guardare il codice sorgente e scoprire eventuali magagne.
È una possibilità in più, non un obbligo.
Dopodiché c'è chi fa il ricercatore di sicurezza per mestiere, e chi invece scopre un bug per casualità.
Nessuno tipicamente si mette a leggere del codice per cercare degli errori se questi non si manifestano in qualche modo, a meno che appunto tu non sia un ricercatore nel campo della sicurezza.
Mostrami le centinaia di falle che lo rendono un colabrodo.
Se non ricordo male, il bug era uno (gravissimo eh, e non mi spiego come sia stato possibile non notarlo per 2 anni).
Codice senza senso, sulla base di quale argomentazione tecnica?
Finché si scriveranno software, non saranno mai esenti da bug. Il linguaggio utilizzato non c'entra una mazza.
Che poi, un OS, o un componente di basso livello, con che lo vorresti scrivere? Java (
Se non ricordo male, il bug era uno (gravissimo eh, e non mi spiego come sia stato possibile non notarlo per 2 anni).
Codice senza senso, sulla base di quale argomentazione tecnica?
Io - che sono masochista - il codice dove il bug si trovava l'ho guardato!
[LIST=1]
[*]Funzione di 1000 righe con codice ripetuto
[*]Migliaia di goto
[*]Macro orrende a dai nomi incomprensibili
[*]if la cui graffa si chiudeva dopo centinai di righe!
[/LIST]
Tutto questo faceva sì che il BUG era difficile da trovare appunto perché non si riusciva a comprendere il codice!
Certo codice scritto male non esente da bug è possibile scriverlo in qualsiasi linguaggio si usi, ma C/C++ sono unsafe by design è così facile scrivere codice bacato con buffer underrun / underflow che poi permette - chissà come - di scardinare tutta la sicurezza dell'OS fino a chiamare pezzi del kernel...
No, in Java no... in C#
Che non vuol dire far girare l'OS sotto una VM, Cosmos una volta compilato l'IL con il normale compilatore Microsoft viene ricompilato in assembler come fa il C, mantenendo comunque la sicurezza (le Stringhe per dire hanno sempre la dimensione giusta non posso scriverci più di quanto ho allocato) di avere un linguaggio Managed.
E` una sfida complessa, ma che si possa fare è certo, è già stato fatto:
http://joeduffyblog.com/2015/12/19/safe-native-code/
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".