Link alla notizia: http://www.hwfiles.it/news/grave-vulnerabilita-nei-kernel-linux-a-64bit_33795.html

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

Click sul link per visualizzare la notizia.

Ennesima dimostrazione che nulla è inviolabile... comunque credo che il fix potrà essere rilasciato sotto forma di aggiornamento.

Ennesima dimostrazione che nulla è inviolabile... .

un sistema operativo è inviolabile solo nella mente del fanboy che lo difende

mmm... ma vuol dire che ci dobbiamo attendere numerosi attacchi a numerosi server nell'arco delle prossime ore?

un sistema operativo è inviolabile solo nella mente del fanboy che lo difende

:asd:

mmm... ma vuol dire che ci dobbiamo attendere numerosi attacchi a numerosi server nell'arco delle prossime ore?

:doh: :doh: :doh: :doh: :doh: :doh:

E' "solo" (:Prrr: ) un local root.
Bisogna avere accesso al sistema da Utente per sfruttare la falla e diventare amministratore della macchina.

beh veramente...un'altra testa giornalistica ha sottotitolato così questa news
Il kernel Linux soffre di una grave vulnerabilità che può aprire le porte di un server ad un utente remoto


non mi pare sia la stessa cosa...

beh veramente...un'altra testa giornalistica ha sottotitolato così questa news
Il kernel Linux soffre di una grave vulnerabilità che può aprire le porte di un server ad un utente remoto


non mi pare sia la stessa cosa...

Leggiti il sorgente, nessuna porta.
Di che testata parliamo? Ridicolo.


http://secunia.com/advisories/41476

Leggiti il sorgente, nessuna porta.
Di che testata parliamo? Ridicolo.


beh io non c'entro nulla...

se cerchi con google (o cliccki il mio link sotto) quella frase come vedi il primo e il terzo risultato
contengono la frase che ho copia/incollato

http://www.google.com/search?hl=it&q=Il+kernel+Linux+soffre+di+una+grave+vulnerabilit%C3%A0+che+pu%C3%B2+aprire+le+porte+di+un+server+ad+un+utente+remoto&aq=f&aqi=&aql=&oq=&gs_rfai=

Se si trattava di Windows eravamo già al settimo commento in stile "Microsoft sucks, Windows fa schifo, passate tutti a linux e non utilizzate quello schifo di Winzozz" :p

ho letto il codice non funziona da remoto ma da locale .
quel titolo vuol dire che se esegui questo programma dopo avendo privilegi di root puoi fare quello che ti pare (compreso mettere un programma in ascolto su una porta)

Non sono esperto di sicurezza, ma credo sia sufficiente poter eseguire codice arbitrario, quindi o si ha una login e si esegue l'exploit o si sfrutta un'altra falla in un altro software connesso per eseguirlo.

@medicina

bhe volendo si può usare una falla in un'applicazione remota per ottenere accesso ad una shell e da li poi esegui quell'exploit e hai la tua bella shell di root (o quello che vuoi se sei in grado di modificare quel codice) e tanti cari saluti al sistema

In pratica si deve aver già un accesso alla macchina, che sia da remoto o locale non cambia, ma rimane il fatto che l'accesso si deve già avere. Potrei lanciare il codice come user da remoto per e ottenere l'accesso root. Tuttavia se non dispongo già di un accesso non posso fare niente.

Non è un discorso "winzoz" è meglio o peggio. Da utilizzatore di Linux dico che oggettivamente ha le sue falle, e sempre le avrà (come tutti gli O.S.), 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.

@raistlin84

guarda che le aziende mica installano al volo tutte le patch appena escono col rischio di vedersi impallarsi tutto per problemi di compatibilità

a patchare win ci si mette tempo anke per testare le eventuali patch in modo approfondito...immagina se una patch fatta in fretta e furia impallasse i pc aziendali...sarebbero tutti con la forca sotto la sede di redmond

Microsoft sucks, Windows fa schifo, passate tutti a linux e non utilizzate quello schifo di Winzozz!
:mbe:
Ah ma si parla di Linux... :ops: :D

La vulnerabilità è effettivamente molto grave. Molte aziende devono dare accesso remoto agli utenti tramite ssh. Come soluzione temporanea si potrebbe disabilitare il layer di compatibilità per le applicazioni 64bit.
Penso che molti sistemisti passeranno qualche notte insonne per sistemare sta cosa nelle loro aziende.

No dai! Non si può trollare in una discussione su un bug, corretto e reinserito tralaltro, di Linux puntando il dito contro Microsoft! :D

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

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

By(t)e

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

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 :D

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

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 :Prrr:

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

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

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 :)

[post inutile]

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

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?

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

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

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"

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 (http://www.h-online.com/open/news/forum/S-workaround-DOES-NOT-PREVENT-EXPLOIT/forum-116020/msg-14370942/read/) disabilitare il layer di compatibilità. Almeno nel modo che è stato lì proposto.

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

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.

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

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

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.

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

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

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

Forse il buon Linus era distratto :eek:

Microsoft sucks, Windows fa schifo, passate tutti a linux e non utilizzate quello schifo di Winzozz!
:mbe:
Ah ma si parla di Linux... :ops: :D

Infatti , Windows è troppo avanti! Per prendere completo controllo del sistema, la vulnerabilità non serve neanche :asd:

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

Forse il buon Linus era distratto :eek:

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

Io non ci capisco niente di kernel, so solo installarne uno, ma mi sento comunque più tranquillo sapendo che c'è un problema su linux e che ci stanno lavorando, piuttosto che sentirmi dire che su windows non non ce ne sono, oppure che con un buon antivirus si è al sicuro...anni di utilizzo linux 64 e 32 bit mai un virus, mai un problema non gestibile.

In pratica si deve aver già un accesso alla macchina, che sia da remoto o locale non cambia, ma rimane il fatto che l'accesso si deve già avere. Potrei lanciare il codice come user da remoto per e ottenere l'accesso root. Tuttavia se non dispongo già di un accesso non posso fare niente.

Non è un discorso "winzoz" è meglio o peggio. Da utilizzatore di Linux dico che oggettivamente ha le sue falle, e sempre le avrà (come tutti gli O.S.), 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.
ben detto...
La vulnerabilità è effettivamente molto grave. Molte aziende devono dare accesso remoto agli utenti tramite ssh. Come soluzione temporanea si potrebbe disabilitare il layer di compatibilità per le applicazioni 64bit.
Penso che molti sistemisti passeranno qualche notte insonne per sistemare sta cosa nelle loro aziende.
da quando i sistemi a 32bit hanno il layer per le applicazioni a 64bit..pur di dire qualcosa vero si dicono delle cose "realistiche!!"
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 :)
Infatti, oltre al fatto che il problema è già sparito.. insomma non hanno fatto in tempo a scrivere la notizia che già non c'è più..

un sistema operativo è inviolabile solo nella mente del fanboy che lo difende

:mano:

Si discute come al solito di aria
fritta....
Windows è l'unico dove l'antivirus è praticamente
d'obbligo per cui i windows
boy hanno poco di che
essere contenti con le solite
frasi fatte trite e ritrite....

Windows è l'unico dove l'antivirus è praticamente
d'obbligo
Ho sempre criticato Windows per questo o per quello, ma quello che hai scritto è oggettivamente errato (non ci sono "se" o "ma").

"oggettivamente"quando le
statistiche dimostreranno il
contrario di quello che dici
allora ne riparleremo.
Per ora la realtà è ben diversa
e qui dentro vedo solo gente
come al solito felice che hanno
trovato un misero baco in un
sistema praticamente inviolabile.

"oggettivamente"quando le
statistiche dimostreranno il
contrario di quello che dici
allora ne riparleremo
Ho scritto "oggettivamente" perchè è proprio così usando a fondo gli strumenti che Windows mette a disposizione (io lo faccio da WinXp 32 bit sp2), che poi la maggior parte di utenti windows non li sappia usare è tutto un'altro discorso. Qua la statistica non c'entra niente.

Non è un discorso "winzoz" è meglio o peggio. Da utilizzatore di Linux dico che oggettivamente ha le sue falle, e sempre le avrà (come tutti gli O.S.), la differenza stà principalmente nel fatto che tali problemi vengono risolti nel giro di ore dalla community, mentre per Microsoft passano giorni, ....

qua veramente era già risolta 3 anni fa, ma la patch è stata rimossa...

il che da l'impressione di una gestione del progetto assolutamente caotica e disordinata. Come del resto tutti i progetti open in cui partecipano troppe persone (da linux a wikipedia, tanto per fare 2 nomi), l'affidabilità ne risente pesantemente.

ragazzi dovreste invece essere tutti contenti che continuino a trovare falle.

Immaginate cosa accadrà quando nei software troveranno anche i "falli".... :O :ciapet:

che strano leggere notizie di questo.. alla faccia dei fanboy :D
Alla fin fine, questo dimostra che tutti i sistemi operativi hanno le loro falle..

che strano leggere notizie di questo.. alla faccia dei fanboy :D
Alla fin fine, questo dimostra che tutti i sistemi operativi hanno le loro falle..

certo. la differenza è che certe falle le paghi profumatamente ed altre no. :D

un sistema operativo è inviolabile solo nella mente del fanboy che lo difende

:asd: fantastico, pure l'assonanza! :winner:

Comunque e' necessario implementare la patch nelle varie distribuzioni? Non basta il classico aggiornamento?

Fortuna che l'exploit non e' sfruttabile da remoto, molti server di aziende hanno come base linux (poi millemila macchine virtuali sopra) e sarebbe stato un bel colpo...

mmm vorrei fare alcune considerazioni....

la prima è che nessun software è inviolabile e questo credo che dovrebbe essere chiaro dal primo anno primo semestre di ingegneria informatica o informatica :D

ok, qualcuno ( WarDuck di sicuro ) dirà che sono un fanboy linux e mi sgolo per cantarne le gesta....è vero, apprezzo molto linux molto più di windows ma molto meno di freebsd o haiku per esempio

il punto da chiarire è che le falle non vengono create uguali e questa dimostra proprio l'assioma in questione.....cosa succede spessissimo su windows? compare una falla, vai su secunia et similia e ( in buona parte dei casi ) trovi "sfruttabile da remoto".....

vai su secunia e soci per cercare falle su linux e trovi che quelle sfruttabili da remoto sono la minoranza

questa falla ad esempio è sfruttabile se hai accesso alla macchina linux....ma prima devi guadagnartelo l'accesso....se hai un accesso legale ad una macchina linux allora sei identificabile e fare cazzate come il rooting non è un'idea particolarmente intelligente

la falla in questione può essere accoppiata ad altre falle che consentono l'accesso con privilegi ridotti ( che so in apache, php, mysql o che altro )....

ma il pattern rimane comunque tortuoso e sconnesso....questo fatto è una garanzia in più rispetto a sistemi dove le falle ti portano dritto al trono

la seconda considerazione riguarda il modello di sviluppo che seppur caotico ha permesso a linux in due decenni di diventare un sistema operativo enterprise che compete alla pari con alternativa closed che hanno dietro milioni di ore uomo di lavoro e centinaia di miliardi di dollari

non sono d'accordo sul fatto che ogni ragazzino può introdurre quello che gli pare e infatti un controllo viene fatto.....obiettivamente un controllo su centinaia di migliaia di righe di codice alla settimana non è proprio facilissimo e ovviamente lo strafalcione capita

realisticamente di problemi del genere su linux ne abbiamo notizia raramente e penso che questo sia un buon indicatore che le cose non vanno così male....in una scala di sicurezza da 1 a 10, io a linux darei un 7

è chiaro, confrontato con openbsd, linux fa la figura dell'idiota...ma pure confrontandolo con freebsd non ne esce bene

la terza considerazione è che linux com'è oggi non va bene e Tanenbaum aveva ragione ( certo cose sono del resto ovvie e non mi capacito di come i programmatori in certi casi siano così ottusi )....i microkernel avranno pure un livello di complessità architetturale elevato, ma sono eleganti, non sono bloated, la riusabilità del codice è spinta al massimo, costringono chi li sviluppa a farlo in maniera rigorosa, il debug è facile e la manutenibilità è qualcosa che i kernel monolitici possono solo sognare

purtroppo i microkernel sono ad oggi solo un affare da ricerca scientifica o sistemi mission critical....nessuno dei 3 sistemi operativi più noti è microkernel

certo. la differenza è che certe falle le paghi profumatamente ed altre no. :D

:asd:

Infatti, oltre al fatto che il problema è già sparito..

Ieri su OpenSUSE non era affatto sparito, oggi controllerò di nuovo ma temo ci vogliano ancora un paio di giorni massimo.

qua veramente era già risolta 3 anni fa, ma la patch è stata rimossa...

il che da l'impressione di una gestione del progetto assolutamente caotica e disordinata. Come del resto tutti i progetti open in cui partecipano troppe persone (da linux a wikipedia, tanto per fare 2 nomi), l'affidabilità ne risente pesantemente.

Il modo di sviluppare di Wikipedia e Linux hanno poco in comune. In Wikipedia il controllo delle modifiche, che vengono fatte da chiunque, è affidata alla disponibilità del momento e al tempo (e, per inciso, alcuni discipline della versione italiana sono un vero disastro in termini di qualità). In Linux non viene accettato niente se prima non viene controllato. In realtà nello sviluppo del software sia aperto e chiuso si ha come un problema costante il presentarsi di regressioni, che a volte riguardano la perdita involontaria di caratteristiche prima presenti, altre volte, come in questo caso, sono inerenti la perdita di sicurezza.

Come ho scritto prima, non è corretto parlare di patch rimossa, ma di patch vanificata da modifiche successive.

ben detto...

da quando i sistemi a 32bit hanno il layer per le applicazioni a 64bit..pur di dire qualcosa vero si dicono delle cose "realistiche!!"

Infatti, oltre al fatto che il problema è già sparito.. insomma non hanno fatto in tempo a scrivere la notizia che già non c'è più..

Chiedo venia.. il layer per le applicazioni 32bit sul kernel 64.

purtroppo i microkernel sono ad oggi solo un affare da ricerca scientifica o sistemi mission critical....nessuno dei 3 sistemi operativi più noti è microkernel

Quali sarebbero i 3 sistemi operativi più noti?

Direi il riferimento era a:


Windows
Mac OSX
Unix & derivati (compreso il nostro amico pinguino)

I primi due si definiscono "kernel ibridi" (pare sia marketing... non vuol dire 'na sega in realtà), Linux invece si definisce "orgogliosamente" monolitico...

Anche Haiku/BeOS dovrebbe essere un kernel "ibrido" (qualunque cosa significhi)... l'unico vero microkernel minimamente noto è Minix... noto più che per il thread sui newsgroup del suo autore che diceva che Linux avrebbe succhiato per sempre... e che Minix ce l'aveva grosso... ironia della sorte 20 anni dopo Linux succhia lo stesso :Prrr: , ma è ovunque... Minix non se lo fila nessuno :D

Trovato il link al thread originale del 92:
http://bit.ly/bNItFm

Ieri su OpenSUSE non era affatto sparito, oggi controllerò di nuovo ma temo ci vogliano ancora un paio di giorni massimo.



Il modo di sviluppare di Wikipedia e Linux hanno poco in comune. In Wikipedia il controllo delle modifiche, che vengono fatte da chiunque, è affidata alla disponibilità del momento e al tempo (e, per inciso, alcuni discipline della versione italiana sono un vero disastro in termini di qualità). In Linux non viene accettato niente se prima non viene controllato. In realtà nello sviluppo del software sia aperto e chiuso si ha come un problema costante il presentarsi di regressioni, che a volte riguardano la perdita involontaria di caratteristiche prima presenti, altre volte, come in questo caso, sono inerenti la perdita di sicurezza.

Come ho scritto prima, non è corretto parlare di patch rimossa, ma di patch vanificata da modifiche successive.
il rilascio del kernel 2.6.35.5 non ti dice nulla?
si parlava di kernel sistemato non di suse...

il rilascio del kernel 2.6.35.5 non ti dice nulla?
si parlava di kernel sistemato non di suse...

Se avevo da segnalare la non avvenuta correzione del problema, non aspettavo il tuo intervento per contraddire l'articolo che stiamo commentando. Invece volevo far notare a tutti quanto diffuse distribuzioni Linux gratuite possano metterci tempo per rimediare alla falla.

sicuramente non ci metteranno mesi come qualcun'altro e poi alla fine questa è una non notizia, un'articolo esce su un problema già risolto nel kernel ufficiale.
la vulnerabilità riguarda una "emulazione di codice a 32bit su 64bit, evento assai raro, sebbene, come il sottoscritto, ci siano casi obbligati ad usare ad esempio, googlearth su linux a 64bit, (tra l'altro ho già aggiornato il kernellino) ma non so quanto sia possibile arrivare al mio pc, come quello di tanti...Quando ho letto questa notizia, dal titolo, sembrava prannuciare il "crollo del mondo" alla fine è tanto fumo e poco arrosto... come spesso capita..
Linus& co sono stati moto rapidi a chiudere il buco, questo deve essere l'atteggiamento, noi dobbiamo essere felici per questo non perchè hanno trovato un buco nel kernel. I problemi ci saranno sempre, importante risolverli in tempi decenti.. non dopo 6 mesi o 1anno...

sicuramente non ci metteranno mesi come qualcun'altro e poi alla fine questa è una non notizia, un'articolo esce su un problema già risolto nel kernel ufficiale.
la vulnerabilità riguarda una "emulazione di codice a 32bit su 64bit, evento assai raro, sebbene, come il sottoscritto, ci siano casi obbligati ad usare ad esempio, googlearth su linux a 64bit, (tra l'altro ho già aggiornato il kernellino) ma non so quanto sia possibile arrivare al mio pc, come quello di tanti...Quando ho letto questa notizia, dal titolo, sembrava prannuciare il "crollo del mondo" alla fine è tanto fumo e poco arrosto... come spesso capita..
Linus& co sono stati moto rapidi a chiudere il buco, questo deve essere l'atteggiamento, noi dobbiamo essere felici per questo non perchè hanno trovato un buco nel kernel. I problemi ci saranno sempre, importante risolverli in tempi decenti.. non dopo 6 mesi o 1anno...

Ciao,
non è un "evento assai raro".

Il problema pare non essere relativo alla semplice esecuzione di applicazioni a 32 bit (che su un sistema a 64 bit possono essere la minoranza), ma alla presenza nel kernel dello stack necessario a farle funzionare. E questa funzione è implementata in _tutti_ i kernel che ho visto da anni a questa parte.

Ciao. :)

Ciao,
non è un "evento assai raro".

Il problema pare non essere relativo alla semplice esecuzione di applicazioni a 32 bit (che su un sistema a 64 bit possono essere la minoranza), ma alla presenza nel kernel dello stack necessario a farle funzionare. E questa funzione è implementata in _tutti_ i kernel che ho visto da anni a questa parte.

Ciao. :)

riflettendoci non è assai raro, ma comunque parliamo già del passato..

Minix non se lo fila nessuno :D

Non esattamente, proprio venerdì scorso sono stato segato a un esame su Minix...:cry:

Vedrete che ora Tanenbaum verrà qui e dirà a tutti "Nel mio fighissimo microkernel quella vulnerabilità non c'è! Linux suck, Minix FTW!":D

ma infatti per linux non si è mai parlato di inviolabilità ma si è sempre detto che non becchi virus perchè non è interessante per chi produce virus... almeno questo è quello che ricordo io...
cmq avranno cominciato a interessarsi a linux per via del grosso riscontro che ha avuto nell'utenza media quindi ora la musica cambia...

Su RedHat e Fedora ramo stabile è stata risolta da tre giorni almeno con l'update del kernel (RH era afflitta da https://access.redhat.com/kb/docs/DOC-40265) senza aspettare un martedì del mese prossimo (cit.)

daniele@tmbook Scaricati]$ ./a.out
resolved symbol commit_creds to 0xffffffff8106b731
resolved symbol prepare_kernel_cred to 0xffffffff8106b619
mapping at 3f80000000
UID 500, EUID:500 GID:500, EGID:500
sh-4.1$ id
uid=500(daniele) gid=500(daniele) gruppi=500(daniele)
sh-4.1$ exit

La vera diffrenza con Windows e peggio Mac sta qua, trasparenza e rapidità. Senza contare i vari work-around che sono saltati fuori in questi giorni.