Grave vulnerabilità nei kernel Linux a 64bit

[andbad]

L'unico sistema sicuro è il sistema spento.
L'unico problema è che così è poco utile.

By(t)e

[JackZR]

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!!!

[fano]

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

[WaywardPine]

RHEL non è affetto da questa vulnerabilità perchè hanno omesso la patch che la ha reintrodotta.

https://access.redhat.com/kb/docs/DOC-40330

[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

[medicina]

[post inutile]

[The Whisperer in Darkness]

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_kernel#Development_model che comprende il creatore del kernel stesso (Linus Torvalds).

[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?

[shodan]

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.

[shodan]

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.

[AlPaBo]

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"

[medicina]

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 ARROWS]

Non importa se tu non hai software x86, perché probabilmente il software che usa questa vulnerabilità penserà a usare API x86.

[mnovait]

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.

[Devil402]

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

[dennyv]

Comunque le falle sono due: https://access.redhat.com/kb/docs/DOC-40330 e https://access.redhat.com/kb/docs/DOC-40265

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

[shodan]

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.

[fano]

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_k...elopment_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

[Mercuri0]

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