Link alla notizia: https://www.hwupgrade.it/news/sistemi-operativi/caos-nel-mondo-linux-patch-introducono-vulnerabilita-nel-kernel-c-e-del-marcio-in-minnesota_97137.html

Bufera nel mondo Linux dopo il ban dell'Università del Minnesota per aver inviato patch con falle di sicurezza o senza alcun valore per il kernel. Il manutentore Greg Kroah-Hartman ha deciso di non fare sconti e rimuovere dal kernel qualsiasi commit pubblicato dall'ateneo finora.

Click sul link per visualizzare la notizia.

Si, ma Linus che dice? O lo stanno tenendo 'addormentato' da qualche parte?

Han ragione i maintainer del kernel, punto.

1. Gli sviluppatori non sono delle c@zzo di cavie da laboratorio. Il paper sul "proviamo a committare merda e vediamo la community come la prende" se lo potevano risparmiare.

2. Se vomiti una marea di commit generati dalla tua $merdavigliosaApplicazioneScrittaACDC e non li controlli o, peggio, non sei in grado di comprenderne la bontà, allora vai a zappare la terra e lascia perdere il kernel linux.

Si, ma Linus che dice? O lo stanno tenendo 'addormentato' da qualche parte?

Sarà ancora rinchiuso in qualche monastero assieme a Stallman per non esplodere e droppare un vaffanculo nucleare sulle TdC di quell'uni.

Han ragione i maintainer del kernel, punto.

1. Gli sviluppatori non sono delle c@zzo di cavie da laboratorio. Il paper sul "proviamo a committare merda e vediamo la community come la prende" se lo potevano risparmiare.

2. Se vomiti una marea di commit generati dalla tua $merdavigliosaApplicazioneScrittaACDC e non li controlli o, peggio, non sei in grado di comprenderne la bontà, allora vai a zappare la terra e lascia perdere il kernel linux.

Ad ogni modo io non credo nella bonta' di questo progetto.
Penso che dietro vi sia la NSA o qualche altra agenzia americana che ha voluto 'tastare' il terreno.

Sta usando il suo portavoce per evitare di essere rinchiuso di nuovo

DA un certo punto di vista la ricerca ha un valore non trascurabile: la capacitá della comunitá linux di individuare velocemente contributi malevoli é importante.
D'altro canto, mettere a repentaglio la sicurezza del software solo per fare un esperimento é quantomeno opinabile...

Tagliare i tubi dei freni nei negozi di alimentari?:D

Comunque se lo scopo di questi "ricercatori' era verificare se venivano beccati ed espulsi gli faccio i complimenti perché ottenuto un successo

Ad ogni modo io non credo nella bonta' di questo progetto.
Penso che dietro vi sia la NSA o qualche altra agenzia americana che ha voluto 'tastare' il terreno.

Se vuoi testare il terreno non fai una ricerca ufficiale di una università prestigiosa e ne rovini la reputazione

Tagliare i tubi dei freni nei negozi di alimentari?:D

Delle auto all'esterno ovvio.. non so perché abbia fatto questo esempio un po' contorto... però se non vado errato, e come tutti posso sbagliare, mi pare che è quanto abbia scritto.

Si, ma Linus che dice? O lo stanno tenendo 'addormentato' da qualche parte?

Sedato e legato perché aveva già in mano un'ascia per andare a esprimere cosa ne pensava dei ricercatori dell'Università del Minnesota

Si, ma Linus che dice? O lo stanno tenendo 'addormentato' da qualche parte?Starà abbracciando la sua coperta per trovare qualche sicurezza in più :asd:

Visto il periodo introdurre volontariamente vulnerabilità nel kernel non mi sembra una scelta saggia, capisco la ricerca e posso anche dire che è stata fatta senza l'intenzione di creare danni...però prima di fare ste cose forse è il caso di collegare il cervello e farsi due domande, che li abbiano bannati poi non ci vedo nulla di strano, è solo la logica conseguenza per quello che è stato fatto...non si potevano aspettare fiori, una targa ricordo e pacche sulle spalle.

Se vuoi testare il terreno non fai una ricerca ufficiale di una università prestigiosa e ne rovini la reputazione

Potrei anche essere d'accordo.
Ma la seconda opzione e' che questi sono talmente ingenui che non solo si meritano il ban perenne ma dovrebbero pure cambiare mestiere.

Ho inviato patch nella speranza di ottenere dei feedback. Non siamo esperti nel kernel di Linux...

Non stai patchando il notepad, ma il kernel linux. È un una procedura estrema, non etica e che non doveva nemmeno partire.
Difatti è stata bloccata.

Han ragione i maintainer del kernel, punto.

1. Gli sviluppatori non sono delle c@zzo di cavie da laboratorio. Il paper sul "proviamo a committare merda e vediamo la community come la prende" se lo potevano risparmiare.

2. Se vomiti una marea di commit generati dalla tua $merdavigliosaApplicazioneScrittaACDC e non li controlli o, peggio, non sei in grado di comprenderne la bontà, allora vai a zappare la terra e lascia perdere il kernel linux.

concordo in pieno, sti qua si sono bevuti il cervello, e invece di vergognarsi e scusarsi pubblicamente ribattono pure.

Mio dio che branco di cialtroni.
Se sei un neofita ti scarichi il kernel lo studi e te lo modifichi per gli affaracci tuoi.
È già abbastanza impestato di suo. Giusto evitare che venga aggiunta porcheria inutile.

Ho un po' di dubbi sul fatto di cancellare tutte le patch introdotte ANCHE in passato dall'Università del Minnesota.
E' un po' come dire che se una persona oggi ha rubato una mela, è sempre stato un ladro fin da quando era in fasce... :D :D :D

A parte l'idiozia del "ricercatore" che è palese, la cosa inquietante (sempre che abbia capito qualcosa, correggetemi se sbaglio) è che il gruppo di manutenzione non controlla le patch proposte prima di inserirle nei kernel ufficiali... o no?

Che fallisca la UMN e vadano tutti a casa.
Non si fanno cosi' gli esperimenti e i test sui programmi !

Potrà essere eticamente discutibile, ma l'idea di introdurre vulnerabilità da una linea "privilegiata" non è da sottovalutare per niente.

Innanzitutto perché può capitare sempre e comunque, magari a seguito di compromissione di credenziali utente, e in secondo luogo perché un utente realmente malevolo avrebbe potuto farlo in maniera molto meno eclatante e ben nascosta.

Il problema esiste ed è stato portato alla luce, che che se ne dica e che che raglino i vari mantainers.

Secondo me il ban è pure poco.
Se uno taglia i freni delle auto, o scassina le porte di casa altrui, perché, per ricerca scientifica, vuol vedere quanto è facile farlo e dopo quanto i proprietari se ne accorgono... beh, non credo che se la cavi semplicemente con un "ban"...

Ma faceva cosi' schifo lavorare su un repository locale per poterlo sputtanare come si voleva? Se lo scopo era verificare il tool di analisi statica, bastava mettere le patch con i bachi nel repository locale, per poi far partire il tool. Non capisco che utilita' potesse avere andare a sperimentare col repository ufficiale...

Potrà essere eticamente discutibile, ma l'idea di introdurre vulnerabilità da una linea "privilegiata" non è da sottovalutare per niente.

Innanzitutto perché può capitare sempre e comunque, magari a seguito di compromissione di credenziali utente, e in secondo luogo perché un utente realmente malevolo avrebbe potuto farlo in maniera molto meno eclatante e ben nascosta.

Il problema esiste ed è stato portato alla luce, che che se ne dica e che che raglino i vari mantainers.

Il problema non e' portare bug: i bug nel kernel ci sono, vengono introdotti e vengono risolti continuamente. Il problema e' farlo intenzionalmente a scopo di ricerca, pensando al proprio tornaconto e non al fatto che quei bug potessero finire in migliaia di computer che diventano vulnerabili, perche' non e' scritto da nessuna parte che se metti il bug e dopo la correzione, nel frattempo la modifica malevola non venga utilizzata da qualche parte.

$merdavigliosaApplicazioneScrittaACDC

Nono sono l'unico a leggere le storie di Davide, allora..

Ma faceva cosi' schifo lavorare su un repository locale per poterlo sputtanare come si voleva? Se lo scopo era verificare il tool di analisi statica, bastava mettere le patch con i bachi nel repository locale, per poi far partire il tool. Non capisco che utilita' potesse avere andare a sperimentare col repository ufficiale...

No, l'obiettivo era quello di inserire vulnerabilità in mainline, dimostrando che il metodo di verifica delle patch è lasco e non stringente quanto dovrebbe.

La vulnerabilità non riguarda il repository o il codice in se, ma le procedure di accettazione delle patch, motivo per cui non c'era possibilità di farlo "in locale".

Il problema non e' portare bug: i bug nel kernel ci sono, vengono introdotti e vengono risolti continuamente. Il problema e' farlo intenzionalmente a scopo di ricerca, pensando al proprio tornaconto e non al fatto che quei bug potessero finire in migliaia di computer che diventano vulnerabili, perche' non e' scritto da nessuna parte che se metti il bug e dopo la correzione, nel frattempo la modifica malevola non venga utilizzata da qualche parte.

Sono d'accordo, infatti nessuno ha detto che è etico o moralmente giusto questo comportamento. Ma probabilmente era l'unico modo reale affinché fosse portato alla luce con la giusta attenzione.

Considerato che i mantainers tendono ad essere sempre abbastanza spocchiosi, non sarebbe bastato dirgli "guardate che ci potrebbe essere un problema".

Credo che solamente i talebani di linux non siano consci del fatto che la natura open del kernel sia una delle sue più grandi vulnerabilità e al tempo stesso il suo punto di forza.

Da quello che ho capito io questi hanno fatto casino solo per il semplice fatto di voler testare il loro programmino che genera codice di una qualche utilità.

Nono sono l'unico a leggere le storie di Davide, allora..

Direi di no :D
Potrei averle scritte io o chiunque altro lavori nell'IT quelle storie. Tutti han avuto a che fare con CL/UL/SL nella propria carriera IT. Nel caso in cui non vi fosse successo, al posto vostro inizierei a chiedermi sia io il CL/UL/SL di turno :asd:

Per conciliare le due cose bastava concordare ufficialmente il "penetration test" con un responsabile interno al Kernel definendo le "rules of engagement" e assicurandosi che le patch venissero bloccate prima del deployment finale.

A suo tempo io avevo sollevato la questione della responsabilità dei commit con la "Core Infrastructure Initiative Best Practices (https://www.coreinfrastructure.org/programs/best-practices-program/)" (di cui se non sbaglio anche il Kernel Linux fa parte) ma loro non avevano raccolto il suggerimento.

^THIS. Concordo al 100%.

Li dovrebbero cacciare. Ammesso che si possano fare test di questo genere sicuramente non li vai a fare nella release stable, mettendo a rischio la sicurezza informatica di sistemi in giro per il mondo.

io resto dell'idea che agli americani, qualsiasi cosa di troppo sicuro che loro non sappiano o possano bucare, non gli vada bene e sia lontano dai loro scopi di poter controllare ciò che gli pare.
stesso motivo per cui hanno bannato Huawei, probabilmente non sapevano bucarli e si son messi a dire che la roba cinese non è sicura.
(come pure il discorso che non prendano in considerazione di valutare lo Sputnik V solo perchè è russo)

stesso motivo per cui hanno bannato Huawei, probabilmente non sapevano bucarli e si son messi a dire che la roba cinese non è sicura.
(come pure il discorso che non prendano in considerazione di valutare lo Sputnik V solo perchè è russo)

Ammazza, hai un cugggino virologo ed uno nella NSA? :eek: :eek:

Devo dire che HWU si sta riempiendo di complottisti, almeno quelli anti 5g sono scappati a gambe levate. :stordita:

Li dovrebbero cacciare. Ammesso che si possano fare test di questo genere sicuramente non li vai a fare nella release stable, mettendo a rischio la sicurezza informatica di sistemi in giro per il mondo.

Anche perchè la versione stable solitamente è quella usata in ambienti di produzione che devono essere decisamente tranquilli e certificati...
Direi che l'esperimento fatto è proprio da idioti... anche se ipoteticamente vi fossero state delle motivazioni giuste quali quella di dimostrare l'inefficienza del processo di validazione delle patch (ma non era questo lo scopo se ho compreso bene l'articolo).

E' giusto che ci sia un controllo su quello che viene proposto come patch altrimenti qualche organizzazione o gruppo di cracker potrebbe inviare una patch contenente un bug che si può sfruttare per compromettere un sistema in futuro.

Mi spiace ma bisogna che qualcuno/qualcosa si occupi di verificare tutte le richieste altrimenti ci troveremo con un bel po' di malware nel kernel Linux nei prossimi anni ed è facile poi perdere la fiducia degli utenti che torneranno a Windows.

Direi che l'esperimento fatto è proprio da idioti... anche se ipoteticamente vi fossero state delle motivazioni giuste quali quella di dimostrare l'inefficienza del processo di validazione delle patch (ma non era questo lo scopo se ho compreso bene l'articolo).

Se non ho capito male lo scopo era testare un analizzatore statico, che poi siano venute fuori "falle" anche per la validazione delle patch è un altro discorso...che da una parte non dovrebbe accadere, dall'altra immagino sia impossibile controllare tutto e si vada anche un po' a fiducia di chi ti propone queste correzioni, fiducia che in questo caso è stata tradita...alla fine come dice giustamente enos76 bastava mettersi d'accordo, loro facevano tranquillamente i loro test e nei rilasci del kernel stabile non sarebbero mai arrivate queste correzioni potenzialmente dannose, ne sarebbero usciti tutti vincitori.

A parte l'idiozia del "ricercatore" che è palese, la cosa inquietante (sempre che abbia capito qualcosa, correggetemi se sbaglio) è che il gruppo di manutenzione non controlla le patch proposte prima di inserirle nei kernel ufficiali... o no?

Esattamente il contrario, dato che GKH gliele ha elencate tutte, indicando tutti i relativi bug.

No, l'obiettivo era quello di inserire vulnerabilità in mainline, dimostrando che il metodo di verifica delle patch è lasco e non stringente quanto dovrebbe.


Hanno sbagliato obiettivo allora. Dovevano scegliere FreeBSD https://www.phoronix.com/scan.php?page=news_item&px=FreeBSD-13.0-RC3-Released

I BSD mi stanno deludendo alla grande. E' già la seconda volta che i dev di FreeBSD si fanno trovare "impreparati".

Nono sono l'unico a leggere le storie di Davide, allora..Hai voglia... Ha più fan di quanti si creda. :D

Esattamente il contrario, dato che GKH gliele ha elencate tutte, indicando tutti i relativi bug.


"Non si tratta ovviamente di un'accusa campata per aria, ma di qualcosa di documentato, che fa riferimento a un documento di ricerca intitolato "Open Source Insecurity: Stealthily Introducing Vulnerabilities via Hypocrite Commits" e pubblicato a febbraio in cui i ricercatori dell'Università del Minnesota spiegano di aver intenzionalmente introdotto falle di sicurezza (nello specifico Use-After-Free) nel ramo principale del kernel Linux. Un atto a fini di ricerca, ma che non è andato giù a chi lavora quotidianamente per rendere il mondo open source sempre più sicuro e credibile.

Il problema è che dopo la pubblicazione del documento, i ricercatori della University of Minnesota hanno inviato un'altra ondata di patch creata automaticamente da un presunto tool di analisi statica. Il contenuto di questi commit si è rivelato senza valore."

Io capisco che se ne sono accorti solo DOPO che sia stato pubblicato l'articolo (mettendo in allarme i manutentori) che ai successivi invii di aggiornamenti ci hanno "guardato dentro" e hanno trovato codice inutile/dannoso... e quindi tutti gli aggiornamenti precedenti siano passati senza problemi. Ma potrebbe essere anche l'articolo poco preciso oltre alla la mia ottusità :P

Spero tu abbia ragione ed io torto :)

Per fare la verifica della permeabilità di eventuali patch malevole bastava introdurne 2 o 3, tracciarle e alla fine prima che venissero inserite definitivamente segnalare la cosa.
Non capisco questa cosa del tool automatico che spara a raffica supposte solo per il gusto di testare qualcosa che non ha alcun valore per il kernel Linux.
Anzi, fa perdere ai manutentori tempo inutilmente (e altrettanto ora che devono rivedere tutte le patch immesse).
Si parla del kernel di Linux, non dell'app open source usati da 4 ragazzini nella loro stanzetta che non avrà futuro.
Ci sta quindi l'incazzatura estrema con estremo rimedio al problema.

Il ricercatore si è fatto una bella fama...

Delle auto all'esterno ovvio.. non so perché abbia fatto questo esempio un po' contorto... però se non vado errato, e come tutti posso sbagliare, mi pare che è quanto abbia scritto.

Ma la parola "parcheggio" è sconosciuta?
Le traduzioni dall'inglese non devono essere letterali. Infatti si capisce subito quando inserisci un testo tradotto: sembra di sentire parlare un accademico della crusca che usa parole ed espressioni in disuso o ampollose con cui nessuna persona normale si esprimerebbe in italiano.
Quando sono coerenti. Talvolta invece sono completamente incomprensibili perché si traduce letteralmente modi di dire che non sono propri della nostra lingua.

Non sono uno sviluppatore, ma trovo certi passaggi inquietanti:

Queste patch sono state inviate come parte di un nuovo analizzatore statico che ho scritto e la sua sensibilità ovviamente non è eccezionale. Ho inviato patch nella speranza di ottenere dei feedback. Non siamo esperti nel kernel di Linux e fare ripetutamente queste affermazioni è disgustoso.

Prendendo per vera questa versione (che sappiamo bene essere del tutto falsa), mi chiedo: non sei esperto di kernel Linux, hai scritto un tool che sai già che funziona male, e lo testi "into the wild"? E dopo che ti hanno bannato hai pure la faccia tosta di prendertela? :muro:
Cioè, se sai che il tuo tool è una mer@a, fagli fare i commit e controllali tu, non chiedere ad altri di fare il tuo lavoro...

Da quello che ho capito il ban è avvenuto non tanto (o meglio, non solo) per il primo invio di patch, ma perché dopo aver pubblicato il risultato della ricerca hanno proseguito e fatto ulteriori commit massivi. Come dire: oltre al danno, anche la beffa.

Sulla scelta di eliminare tutti i vecchi contributi magari (probabilmente) sbaglio, ma comunque avrebbero dovuto ricontrollare tutte le modifiche introdotte, che magari portavano più bug di quelli che andavano a risolvere. A sto punto meglio non rischiare.

By(t)e

Direi di no :D
Potrei averle scritte io o chiunque altro lavori nell'IT quelle storie. Tutti han avuto a che fare con CL/UL/SL nella propria carriera IT. Nel caso in cui non vi fosse successo, al posto vostro inizierei a chiedermi sia io il CL/UL/SL di turno :asd:



^THIS. Concordo al 100%.
Quoto!!
Inoltre contate anche me come lettore! :D
Mi immedesimo molto in lui quando qualche mio CL manda TFU qualcosa :doh:

Quoto!!
Inoltre contate anche me come lettore! :D
Mi immedesimo molto in lui quando qualche mio CL manda TFU qualcosa :doh:

+1

By(t)e

Ad ogni modo io non credo nella bonta' di questo progetto.
Penso che dietro vi sia la NSA o qualche altra agenzia americana che ha voluto 'tastare' il terreno.
idem. ma non necessariamente usa...
DA un certo punto di vista la ricerca ha un valore non trascurabile: la capacitá della comunitá linux di individuare velocemente contributi malevoli é importante.
D'altro canto, mettere a repentaglio la sicurezza del software solo per fare un esperimento é quantomeno opinabile...
concordo.

Nono sono l'unico a leggere le storie di Davide, allora..
:D

Mi spiace ma bisogna che qualcuno/qualcosa si occupi di verificare tutte le richieste altrimenti ci troveremo con un bel po' di malware nel kernel Linux nei prossimi anni ed è facile poi perdere la fiducia degli utenti che torneranno a Windows.
dove il malware c'è sicuramente e nessuno può controllarlo? :p

cmq per fare i loro test potevano usare wikipedia, che è già piena di cazzate che nessuno controlla :D

Han ragione i maintainer del kernel, punto.

1. Gli sviluppatori non sono delle c@zzo di cavie da laboratorio. Il paper sul "proviamo a committare merda e vediamo la community come la prende" se lo potevano risparmiare.

2. Se vomiti una marea di commit generati dalla tua $merdavigliosaApplicazioneScrittaACDC e non li controlli o, peggio, non sei in grado di comprenderne la bontà, allora vai a zappare la terra e lascia perdere il kernel linux.

Esatto.

DA un certo punto di vista la ricerca ha un valore non trascurabile: la capacitá della comunitá linux di individuare velocemente contributi malevoli é importante.
D'altro canto, mettere a repentaglio la sicurezza del software solo per fare un esperimento é quantomeno opinabile...

Non volevano testare la community ma un caxxo di tool di analisi statica. Questi cialtroni erano assenti alle lezioni di etica della ricerca.


Secondo me il ban è pure poco.
Se uno taglia i freni delle auto, o scassina le porte di casa altrui, perché, per ricerca scientifica, vuol vedere quanto è facile farlo e dopo quanto i proprietari se ne accorgono... beh, non credo che se la cavi semplicemente con un "ban"...

Esattamente.

Ma faceva cosi' schifo lavorare su un repository locale per poterlo sputtanare come si voleva? Se lo scopo era verificare il tool di analisi statica, bastava mettere le patch con i bachi nel repository locale, per poi far partire il tool. Non capisco che utilita' potesse avere andare a sperimentare col repository ufficiale...

E anche questo è vero. Hanno voluto esagerare. I dati sono stati ottenuti in maniera non etica, spero che non gli accettino la pubblicazione. Sono dei cialtroni arroganti.

Non volevano testare la community ma un caxxo di tool di analisi statica. Questi cialtroni erano assenti alle lezioni di etica della ricerca.
cosa volessero veramente fare per me è abbastanza fumoso.
come detto, probabilmente "dietro" potrebbe esserci altro/i...

Non volevano testare la community ma un caxxo di tool di analisi statica. Questi cialtroni erano assenti alle lezioni di etica della ricerca.

Questo è quello che dice il tizio dell'università, probabilmente per pararsi il cul@, ma il sospetto è che sia una scusa bella e buona per coprire la bastardata.

In tutti i casi è una giustificazione del ca@@o, perché il tuo tool di merd@ lo testi tu, non lo fai testare alla community.

By(t)e

Questo è quello che dice il tizio dell'università, probabilmente per pararsi il cul@, ma il sospetto è che sia una scusa bella e buona per coprire la bastardata.

In tutti i casi è una giustificazione del ca@@o, perché il tuo tool di merd@ lo testi tu, non lo fai testare alla community.

By(t)e

Ma infatti tutta la situazione è poco chiara, compreso il motivo per cui una università debba fare una cosa simile...ok la ricerca, ok che vuoi testare il tuo analizzatore statico, ma come già ampiamente detto prima o avverti i manutentori del kernel della cosa o comunque lo puoi testare per cavoli tuoi...alla fine la ricerca poteva essere utile a tutti, così come il test dell'analizzatore, perché nascondere entrambe la cose...la scusa che siano nuovi poi fa ridere, se sei nuovo e non conosci le procedure le chiedi, non muore nessuno.