Grave vulnerabilità nei kernel Linux a 64bit

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

fantastico, pure l'assonanza!

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

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

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.

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

Quali sarebbero i 3 sistemi operativi più noti?

Direi il riferimento era a:

[LIST]
[*]Windows
[*]Mac OSX
[*]Unix & derivati (compreso il nostro amico pinguino)
[/LIST]
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 , ma è ovunque... Minix non se lo fila nessuno

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

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.