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

AMAZFIT Active 2 Smart Watch 44mm, AI, Controllo Vocale, GPS e Mappe incluse, Batteria da 10 Giorni, 160+ Modalità Sportive, Resistente allAcqua 5 ATM per Android e iPhone, Nero

Compra ora
66 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
JackZR20 Settembre 2010, 19:49 #21

Troller Upgrade

Tutta colpa dei 32 bit e dei pigri programmatori che non programmano a 64bit, se non esistessero più applicazioni a 32 bit non ci sarebbe bisogno dell'emulatore delle istruzioni IA32 e di conseguenza non ci sarebbe questo bug nel layer di compatibilità per l'emulazione delle istruzioni a 32bit!!!

fano20 Settembre 2010, 20:15 #22
Il problema è che i 64 Bit non servono a nulla non da nessun vantaggio un'applicazione scritta a 32 o 64, quindi perché sbattesi?

I 64 Bit sono solo marketing

Detto questo:
Linux sucks, Linux fa schifo, passate tutti a Windows e non utilizzate quello schifo di Linuzzz !

A parte gli scherzi credo questo si possa considerare l'altra faccia dell'opensource se il primo ragazzetto che passa può scrivere porcate in quel coso mastodontico che chiamano "kernel" o cancellare patch e ben più grave sembra non esserci nessun controllo di qualità voglio dire sto genio ha ranzato la patch e nessuno gli ha detto "grazie della collaborazione, Diego. La patch però la rimettiamo..."?

Caso simile era successo con ssh (di Ubuntu/Debian mi pare) che invece di generare chiavi random generava sempre le stesse chiavi praticamente conoscendole a priopri uno poteva scardinare la sicureazza di ssh... se poi lo sommavi a quest'altro bacozzo... tanti saluti Linux
WaywardPine20 Settembre 2010, 20:55 #23
RHEL non è affetto da questa vulnerabilità perchè hanno omesso la patch che la ha reintrodotta.

https://access.redhat.com/kb/docs/DOC-40330
floc20 Settembre 2010, 21:03 #24
fuoco di paglia... o meglio, MOLTO meno grave di quanto si puo' pensare a una prima lettura, bisogna avere un account utente locale valido per effettuare l'excalation. oltre al fatto che su un server puro a 64bit il layer di compatibilita' non c'e'

quindi i detrattori di linux dovranno attendere un altro po' per avere la loro fine del mondo
medicina20 Settembre 2010, 21:06 #25
[post inutile]
The Whisperer in Darkness20 Settembre 2010, 21:11 #26
E' superfluo considerare un sistema sicuro al 100% in quanto ogni sistema è oggetto di continue modifiche. Un sistema rimane sicuro se non viene più modificato e nessuno cerca di scardinarlo: nel momento stesso in cui sono introdotte nuove funzionalità questo viene fatto tramite righe di codice che significano nuove potenziali vurnerabilità.

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).
Opteranium20 Settembre 2010, 21:20 #27
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?
shodan20 Settembre 2010, 21:55 #28
Originariamente inviato da: floc
fuoco di paglia... o meglio, MOLTO meno grave di quanto si puo' pensare a una prima lettura, bisogna avere un account utente locale valido per effettuare l'excalation. oltre al fatto che su un server puro a 64bit il layer di compatibilita' non c'e'

quindi i detrattori di linux dovranno attendere un altro po' per avere la loro fine del mondo


Ciao,
non sono d'accordo: secondo me il problema è davvero reale e a quanto pare anche la comunità degli sviluppatori la pensa così, dato che il bug è già stato corretto.

Il punto è che è abbastanza comune dover dare un accesso a un sistema remoto, senza considerare che in teoria il bug dovrebbe essere attivabile anche tramite programmi a loro volta vulnerabili e soggetti a shellcode.

L'ipotesi di dover disabilitare completamente il layer a 32 bit, per quanto efficacie, non è molto elegante: a volte capita di trovarsi davanti ad applicazioni che richiedono la compatibilità IA32 e non sempre la ricompilazione è una strada percorribile.

Ciao.
shodan20 Settembre 2010, 21:56 #29
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?


A quanto pare, per essere al riparo devi disabilitare completamente, lato kernel, li supporto alle applicazioni a 32 bit.

Ciao.
AlPaBo20 Settembre 2010, 22:06 #30
Originariamente inviato da: raistlin84
la differenza stà principalmente nel fatto che tali problemi vengono risolti nel giro di ore dalla community, mentre per Microsoft passano giorni, e mentre un privato può anche avere un sistema non subito patchato (personlmente non condivido, visto che si paga), un'azienda non può certo permettersi questo lusso.


Forse non hai lett l'articolo: la falla è del 2007, è stata corretta ed è stata reintrodotta nel 2008

Ovviamente la correzione è stata rapida (la patch c'era già...) ma in questo caso non dimostra nulla sulla "rapidità della community"
« 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.
 
^