Grave vulnerabilità nei kernel Linux a 64bit

Grave vulnerabilità nei kernel Linux a 64bit

E' stata individuata una vulnerabilità all'interno dei kernel Linux a 64bit che può essere sfruttata per prendere il pieno controllo del sistema

di pubblicata il , alle 17:32 nel canale Sicurezza
 
I migliori sconti su Amazon oggi

Amazfit Bip 5, 46 mm, Smartwatch, Schermo grande, chiamate Bluetooth, Alexa, GPS, durata della batteria di 10 giorni, fitness tracker con frequenza cardiaca, monitoraggio dell'ossigeno nel sangue

Compra ora

TCL 55T6C 55" QLED TV 4K HDR, Fire TV (Smart TV con Dolby Vision e Atmos, HDR10+, Premi e Chiedi ad Alexa)

Compra ora
66 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
medicina20 Settembre 2010, 22:06 #31
Originariamente inviato da: Opteranium
domanda: il fatto che si utilizzi solo software a 64 bit ti mette al riparo? Ovvero, questo layer di compatibilità è attivo di default oppure si "accende" quando lanciamo un programma a 32 bit?


Sembra che non sia sufficiente disabilitare il layer di compatibilità. Almeno nel modo che è stato lì proposto.
II ARROWS20 Settembre 2010, 22:21 #32
Non importa se tu non hai software x86, perché probabilmente il software che usa questa vulnerabilità penserà a usare API x86.
mnovait20 Settembre 2010, 22:25 #33
Originariamente inviato da: Devil402
Quello che mi fa più ridere è che questo bug è del 2007 (Corretto subito...) ed è stato reinserito appena un anno dopo...non capisco, davvero...perchè rimuovere la patch? che senso aveva? Qualcuno nel team per caso ha "buone" idee? xD In ogni caso, è una falla relativamente innocua se non si ha accesso alla macchina, no? Quindi non mi preoccuperei più di tanto...inoltre vabbè...ricordo un topic con una falla simile, non sfruttabile senza accesso alla macchina in windows...stranamente, li, c'erano i profeti della verità che ci illustravano il vero futuro dei sistemi operativi e l'attuale ciofeca...bah...continuando nell'OT e terminando questa piccola frase insulsa, ci terrei solo a dire che detto praticamente, qui si ha la dimostrazione che l'opensource fa bene, ma anche male...se un giorno un'altro genietto volesse rimuovere la patch così, perche gli va, come fu nel 2008, tutti gli exploit andrebbero di nuovo con al massimo qualche modifica...

chi parla di bug difendendo un particolare sistema operativo dimostra di non sapere NULLA di sicurezza informatica.

la probabilità che una porzione di codice sia buggato è direttamente proporzionale al numero delle sue righe.
un esempio?

fate un giro su questo sito http://www.securityfocus.com/
scoprirete il MONDO di bug.
Devil40220 Settembre 2010, 22:47 #34
Ma è normale che ci siano bug in un software, è normale che vengano risolti a seconda degli ambiti con tempistiche diverse, ma NON è normale che li si reintroduca dopo averli corretti per poi correggerli nuovamente con patch GIA' PRONTA dopo 2 anni...credo non sia normale questo...alla fine dei conti, tutti i software presentano bug, è impossibile esserne esenti...
dennyv20 Settembre 2010, 23:18 #35
Comunque le falle sono due: https://access.redhat.com/kb/docs/DOC-40330 e https://access.redhat.com/kb/docs/DOC-40265
olivobestia20 Settembre 2010, 23:29 #36
Sulle distribuzioni serie (quasi tutte) a 64bit il layer di compatibilità non viene installato di default. E non ha neanche senso che ci sia visto che tutte le applicazioni e librerie dei repository sono compilate a 64bit.
Il layer serve se si devono far girare applicazioni proprietarie a 32bit e non c'è bisogno di toccar nulla nel kernel.
shodan20 Settembre 2010, 23:35 #37
Originariamente inviato da: olivobestia
Sulle distribuzioni serie (quasi tutte) a 64bit il layer di compatibilità non viene installato di default. E non ha neanche senso che ci sia visto che tutte le applicazioni e librerie dei repository sono compilate a 64bit.
Il layer serve se si devono far girare applicazioni proprietarie a 32bit e non c'è bisogno di toccar nulla nel kernel.


Ciao,
a quanto pare, il fatto che non venga installato il layer userspace (le librerie ia32) non impisce l'esecuzione dell'exploit, dato che la stragrande maggioranza dei kernel ha compilato al suo interno il layer di compatibilità per il kernelspace.

In pratica un exploit non dovrebbe necessitare del layer userspace (non installato di default) ma solo di quello kernelspace (installato pressocchè sempre). Almeno questo si legge in giro.

Ciao.
fano21 Settembre 2010, 00:21 #38
Originariamente inviato da: The Whisperer in Darkness
Vorrei inoltre far notare che "quel coso mastodondito che chiamano kernel" non viene aggiornato da "ragazzetti": prima che le modifiche siano introdotte nel kernel vengono vagliate da un team http://en.wikipedia.org/wiki/Linux_...velopment_model che comprende il creatore del kernel stesso (Linus Torvalds).


Se preferisci dico "vecchioni" comunque mi pare in sto caso il vaglio non sia venuto molto bene dai la patch c'era da 2 anni ed è stata pure tolta?
Alla faccia dei vagli e dei sarc@zzi...

Forse il buon Linus era distratto
Mercuri021 Settembre 2010, 00:40 #39
Originariamente inviato da: bondocks
Microsoft sucks, Windows fa schifo, passate tutti a linux e non utilizzate quello schifo di Winzozz!

Ah ma si parla di Linux...


Infatti , Windows è troppo avanti! Per prendere completo controllo del sistema, la vulnerabilità non serve neanche
medicina21 Settembre 2010, 02:59 #40
Originariamente inviato da: fano
Se preferisci dico "vecchioni" comunque mi pare in sto caso il vaglio non sia venuto molto bene dai la patch c'era da 2 anni ed è stata pure tolta?
Alla faccia dei vagli e dei sarc@zzi...

Forse il buon Linus era distratto


Ma non sarà stata letteralmente tolta, più semplicemente vanificata da una modifica successiva. Nel vaglio non ci si è accorti della regressione...
« Pagina Precedente     Pagina Successiva »

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".

La discussione è consultabile anche qui, sul forum.
 
^