Le scuse non bastano, la pace tra l'Università del Minnesota e Linux passa da azioni ben precise

Le scuse non bastano, la pace tra l'Università del Minnesota e Linux passa da azioni ben precise

Le scuse dei ricercatori dell'Università del Minnesota non hanno impressionato i manutentori del kernel Linux che hanno chiesto all'ateneo, in modo formale, diverse azioni prima di poter anche solo parlare di ricucire i rapporti e accettare nuovi contributi.

di pubblicata il , alle 11:21 nel canale Sistemi Operativi
Linux
 

Scuse non accettate, almeno per ora. Il caso che ha investito il mondo Linux negli ultimi giorni, legato ai commit ipocriti inviati da tre ricercatori dell'Università del Minnesota (UMN), continua a far discutere. Come scritto in precedenza, i ricercatori dell'ateneo hanno inviato delle patch con vulnerabilità e/o prive di valore per l'integrazione nel kernel allo scopo di verificare, a fini di studio, la risposta da parte dei manutentori. Il tutto, ovviamente, all'insaputa della comunità con il rischio che nel kernel finisse del codice potenzialmente pericoloso.

Per il loro studio i tre ricercatori hanno individuato nel kernel Linux dei bug a bassa priorità facili da risolvere e hanno realizzato quelle che, in estrema sintesi, possiamo definire delle patch incomplete, creando delle "vulnerabilità immature", ossia potenziali problemi privi di una condizione per diventare reali. Così facendo hanno però elevato la pericolosità dei bug, al solo scopo di capire se sarebbero stati rilevati dai manutentori oppure no.

Quando questi ultimi hanno analizzato il codice e stavano per farlo passare alla fase di analisi successiva, i ricercatori (così dicono) hanno informato i mantainer delle problematiche e offerto delle patch complete e corrette per i problemi introdotti. Questo comportamento, unitamente al proseguo del successo di revisione che ha svelato le problematiche, ha sollevato le ire di chi si prende cura quotidianamente del prezioso kernel, in quanto non solo i ricercatori hanno messo a rischio la sicurezza del progetto, ma soprattutto hanno fatto perdere ai manutentori del tempo prezioso, rendendoli peraltro oggetti di studio, come fossero delle cavie.

Così si è arrivati alla decisione da parte del capo dei manutentori Greg Kroah-Hartman di rimuovere tutti i commit precedentemente inviati dall'Università e di bannare l'ateneo da eventuali contributi futuri. Dopo l'esplosione del dibattito nella comunità sulla vicenda, nelle scorse ore sono arrivate le scuse da parte dei ricercatori con una lettera aperta in cui provano a ricucire il rapporto con il mondo Linux e dove ammettono di aver compiuto diverse leggerezze, ma non in malafede.

Greg Kroah-Hartman non è apparso molto impressionato dall'ammissione di colpe. "Come sapete, la Linux Foundation e il Technical Advisory Board della Linux Foundation hanno inviato venerdì una lettera alla vostra Università delineando le azioni specifiche che devono essere svolte affinché il vostro gruppo e la vostra Università riguadagnino la fiducia della comunità del kernel Linux. Fino a quando queste azioni non saranno intraprese, non abbiamo altro da discutere su questo problema".

Zdnet ha ottenuto una copia della missiva. Mike Dolan, vicepresidente senior e direttore generale dei progetti della Linux Foundation, punta il dito sul processo di revisione dell'esperimento e sulla sua approvazione postuma, ma soprattutto ritiene non eticamente corretto fare ricerca sulle persone, in questo caso i manutentori.

"Incoraggiamo e accogliamo con favore la ricerca per migliorare la sicurezza e i suoi processi di revisione. Lo sviluppo del kernel Linux segue dei passaggi per rivedere il codice per prevenire difetti. Tuttavia, riteniamo che gli esperimenti sulle persone senza il loro consenso non siano etici e probabilmente implichino molte questioni legali. Le persone sono parte integrante del processo di revisione e sviluppo del software. Gli sviluppatori del kernel Linux non sono soggetti di test e non devono essere trattati come tali".

Secondo Dolan, lo studio ha anche "sprecato il loro prezioso tempo e messo a rischio i miliardi di persone in tutto il mondo che dipendono dai loro risultati. […] Le conseguenze sono anche amplificate perché le modifiche al kernel di Linux vengono recepite da molti altri progetti a valle che si basano sul suo codice di base".

La Linux Foundation chiede quindi di "fornire al pubblico, in modo rapido, tutte le informazioni necessarie per identificare tutte le proposte di codice vulnerabile noto, legato a qualsiasi esperimento dell'UMN. Le informazioni dovrebbero includere il nome di ogni software a cui sono destinate, le informazioni sui commit, il presunto nome del proponente, indirizzo email, data/ora, oggetto e/o codice, in modo che tutti gli sviluppatori possano identificare rapidamente tali proposte e potenzialmente intraprendere azioni correttive per tali esperimenti".

Dolan ha concluso chiedendo che il documento fosse ritirato "dalla pubblicazione formale e dalla presentazione", in quanto si tratta di un lavoro in cui delle persone sono state oggetto di sperimentazione "senza il loro previo consenso. Lasciare le informazioni su Internet va bene, poiché sono per lo più già pubbliche, ma non dovrebbero esserci crediti di ricerca per un tale lavoro".

33 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
WarSide27 Aprile 2021, 11:43 #1
Serve una punizione esemplare per l'uni, i professori, i ricercatori e gli studenti che si sono prestati a mettere in piedi questa cosa. In questo modo si evita che la stessa idea venga in mente a qualcun altro.

Un bel ban di 10 anni all'uni, 10 ai professori, 7 anni ai ricercatori/dottorandi coinvolti e 3/5 anni agli studenti imbeccati dal/dai prof per portare avanti lo studio.
Sp3cialFx27 Aprile 2021, 11:54 #2
Ci sono due questioni distinte:
- le questioni etiche legate alle modalità svolte dalla ricerca, sulle quali non credo di avere sensibilità / competenze per entrare nel merito quindi passo oltre
- l'evidenza che sia stato tutto sommato semplice compromettere la sicurezza del kernel

I due aspetti dovrebbero andare trattati entrambi; così ho l'impressione che si voglia risolvere tutto facendo un ban generalizzato e per il resto continuando così. A me pare gravissimo, in particolar modo in un contesto di continui cyberattacchi anche di altissimo livello su più fronti (dalle fake news all'ingegneria sociale ai classici attacchi hacker), che il kernel possa essere compromesso da singoli contributori senza particolari difficoltà.
Pensare che un kernel sia sicuro quando compromettere un contributore è sufficiente per compromettere l'intero progetto è del tutto ridicolo.
E onestamente dopo aver visto buchi clamorosi (come quello di OpenSSL) pensavo che si sarebbero stabilite delle procedure un po' più serie, e invece no. Se i manutentori sono occupati a fare altro, e non ci sono controlli incrociati sul codice che viene committato, forse è ora di dedicarsi meno a implementare nuove cose e concentrarsi di più su procedure e sicurezza.
WarSide27 Aprile 2021, 12:02 #3
Originariamente inviato da: Sp3cialFx
Ci sono due questioni distinte:
- le questioni etiche legate alle modalità svolte dalla ricerca, sulle quali non credo di avere sensibilità / competenze per entrare nel merito quindi passo oltre
- l'evidenza che sia stato tutto sommato semplice compromettere la sicurezza del kernel

I due aspetti dovrebbero andare trattati entrambi; così ho l'impressione che si voglia risolvere tutto facendo un ban generalizzato e per il resto continuando così. A me pare gravissimo, in particolar modo in un contesto di continui cyberattacchi anche di altissimo livello su più fronti (dalle fake news all'ingegneria sociale ai classici attacchi hacker), che il kernel possa essere compromesso da singoli contributori senza particolari difficoltà.
Pensare che un kernel sia sicuro quando compromettere un contributore è sufficiente per compromettere l'intero progetto è del tutto ridicolo.
E onestamente dopo aver visto buchi clamorosi (come quello di OpenSSL) pensavo che si sarebbero stabilite delle procedure un po' più serie, e invece no. Se i manutentori sono occupati a fare altro, e non ci sono controlli incrociati sul codice che viene committato, forse è ora di dedicarsi meno a implementare nuove cose e concentrarsi di più su procedure e sicurezza.


Nessuno pensa che il kernel sia sicuro e o che magicamente diventi più sicuro bannando questi tizi. Qui la questione è tutta di metodo.

Non è che io domani mi sveglio e decido di fare pen test all'ecommerce della tua azienda perché così mi gira. Certe cose vanno concertate tra le parti.

Vuoi vedere quale sia il grado di affidabilità delle code review che vengono fatte sul kernel? Parli con il mnt del kernel, LO AVVISI della cosa e, se ti viene dato l'assenso, procedi con test. Questo fa si che codice buggato non finisca in prod.

Allo stesso modo, se io eseguo un pen test al tuo ecommerce, non è che, se becco un SQL exploit, vado e rado al suolo il tuo DB, ti auto a rimetterlo in piedi e poi mi aspetto che ti bastino le mie scuse per chiudere la questione.
canislupus27 Aprile 2021, 12:05 #4
Originariamente inviato da: WarSide
Nessuno pensa che il kernel sia sicuro e o che magicamente diventi più sicuro bannando questi tizi. Qui la questione è tutta di metodo.

Non è che io domani mi sveglio e decido di fare pen test all'ecommerce della tua azienda perché così mi gira. Certe cose vanno concertate tra le parti.

Vuoi vedere quale sia il grado di affidabilità delle code review che vengono fatte sul kernel? Parli con il mnt del kernel, LO AVVISI della cosa e, se ti viene dato l'assenso, procedi con test. Questo fa si che codice buggato non finisca in prod.

Allo stesso modo, se io eseguo un pen test al tuo ecommerce, non è che, se becco un SQL exploit, vado e rado al suolo il tuo DB, ti auto a rimetterlo in piedi e poi mi aspetto che ti bastino le mie scuse per chiudere la questione.


+1
Tasslehoff27 Aprile 2021, 12:06 #5
Originariamente inviato da: Sp3cialFx
Ci sono due questioni distinte:
- le questioni etiche legate alle modalità svolte dalla ricerca, sulle quali non credo di avere sensibilità / competenze per entrare nel merito quindi passo oltre
- l'evidenza che sia stato tutto sommato semplice compromettere la sicurezza del kernel
SNIP
Correggetemi se sbaglio, ma a quanto mi è parso di capire nessuno dei commit incriminati è finito in una stable del kernel, quindi non vedo questa grande semplicità nel compromettere la sicurezza del kernel.

Aggiungiamo anche che stiamo parlando di quello che è probabilmente è il più mastodontico progetto collaborativo che sia mai esistito nella storia dell'informatica, non credo esista un solo progetto (sia esso open o closed source) che sia lontanamente paragonabile al kernel per numero di persone coinvolte, il volume di commit e conseguentemente l'attività di merge.
Sp3cialFx27 Aprile 2021, 12:21 #6
Si ma se vi dico che sul metodo non discuto, non discutete sul metodo. Vi ho già detto che avete ragione.

Continuo a trovare terribilmente grave che sia così facile arrivare a una compromissione nel caso in cui un singolo collaboratore agisca in modo malevolo. Poi si, non è arrivato allo stable ma perché è venuto fuori tutto il casino... il buffer overflow di OpenSSL in stable c'è arrivato eccome e nessuno se n'è accorto.

Poi se "nessuno pensa che il kernel sia sicuro" ok, però ripeto nuovamente dovrebbe rispettare degli standard di sicurezza consoni agli scenari del 2021;
la situazione oggi è grave, gli attacchi "state sponsored" sono all'ordine del giorno e chi trae beneficio a metterci i bastoni tra le ruote ha ben capito che è molto più efficace agire su questo piano, anche perché può agire sostanzialmente indisturbato (se fai saltare per aria la gente ti ritrovi tutto il mondo contro, qui invece non se ne accorge nessuno se non i diretti interessati).

Temo però che come al solito certe dinamiche si comprenderanno nella loro interezza solamente a distanza di parecchi anni.
WarSide27 Aprile 2021, 12:35 #7
Originariamente inviato da: Sp3cialFx
Si ma se vi dico che sul metodo non discuto, non discutete sul metodo. Vi ho già detto che avete ragione.

Continuo a trovare terribilmente grave che sia così facile arrivare a una compromissione nel caso in cui un singolo collaboratore agisca in modo malevolo. Poi si, non è arrivato allo stable ma perché è venuto fuori tutto il casino... il buffer overflow di OpenSSL in stable c'è arrivato eccome e nessuno se n'è accorto.

Poi se "nessuno pensa che il kernel sia sicuro" ok, però ripeto nuovamente dovrebbe rispettare degli standard di sicurezza consoni agli scenari del 2021;
la situazione oggi è grave, gli attacchi "state sponsored" sono all'ordine del giorno e chi trae beneficio a metterci i bastoni tra le ruote ha ben capito che è molto più efficace agire su questo piano, anche perché può agire sostanzialmente indisturbato (se fai saltare per aria la gente ti ritrovi tutto il mondo contro, qui invece non se ne accorge nessuno se non i diretti interessati).

Temo però che come al solito certe dinamiche si comprenderanno nella loro interezza solamente a distanza di parecchi anni.


La verità è che ci sono sempre meno persone con gli attributi che possano sul serio lavorare sul kernel. Ci sono progetti enormi (vedi OpenSSL) dove si farebbe prima a riscrivere tutto e cestinare la roba vecchia dato il debito tecnologico presente.

Lavorare in assembly/C/C++ è diventato di nicchia. La maggior parte dei dev fa 4 minchiate in js/html/css con un corso di 1-2 anni e porta a casa ottimi stipendi, chi glielo fa fare di lavorare col C/assembly per implementare driver, il kernel o software "noiosi" come openssl?

Inoltre, la community che ruota attorno a Linux/OSS nel tempo:
- si è divisa (il csx avrà preso ispirazione da lì
- è passata sempre più in mano a grosse multinazionali (RH/IBM, microsoft, etc)
- si è ricamata l'immagine di "covo di nerd morti di figa e omofobici".

Le grosse aziende hanno tutto da guadagnarci se vengono frequentemente rilasciate patch a bug di sicurezza, perché ti vendono l'assistenza tecnica. Dal sw non ci ricavano granché.
NoNickName27 Aprile 2021, 12:42 #8
La famosa sicurezza dell'open source, dove uno sconosciuto studente può introdurre una vulnerabilità senza essere notato per più di un anno.
Pino9027 Aprile 2021, 12:57 #9
A chi parla di buchi si sicurezza si potrebbe dire di tacere visto che il processo di review ha funzionato alla perfezione: nessuna patch è arrivata in mainline e i revisori esperti hanno colto le falle di sicurezza. Di che state parlando esattamente?
WarSide27 Aprile 2021, 13:01 #10
Originariamente inviato da: NoNickName
La famosa sicurezza dell'open source, dove uno sconosciuto studente può introdurre una vulnerabilità senza essere notato per più di un anno.


La famosa sicurezza del closed source, dove uno sconosciuto dipendente può introdurre una vulnerabilità senza essere notato dai colleghi e senza che persone esterne possano revisionare il codice e far notare che c'è un problema.
Gli unici a notare la vulnerabilità sono coloro che ci lucrano su con exploit & Co.

Eh si, viva il closed source e la security through obscurity

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