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

[Redazione di Hardware Upg]

Link alla notizia: https://www.hwupgrade.it/news/sistem...ise_97262.html

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.

Click sul link per visualizzare la notizia.

[WarSide]

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.

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

[WarSide]

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.

[canislupus]

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

[Tasslehoff]

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.

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

[WarSide]

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

[NoNickName]

La famosa sicurezza dell'open source, dove uno sconosciuto studente può introdurre una vulnerabilità senza essere notato per più di un anno.

[Pino90]

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?

[WarSide]

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

[3000]

NoNIckName... sei venuto a renderti ridicolo? Guarda che non sei al bar

[zephyr83]

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.

mi sa che non hai letto bene la notizia. questa vicenda dimostra il contrario, che non è facile compromettere il kernel e chi se ne occupa ha rilevato questi tentativi. poi ovvio qualcosa a qualcuno può sempre sfuggire, un sistema sicuro al 100% non esiste . diciamo che la ricerca alla fine è servita a dimostrare l'efficacia di questo sistema, ma così hanno minato il rapporto di fiducia fra quell'università e la comunità Linux.

[dado1979]

Pessima università che creerà pessimi uomini, uomini che se ne fottono di tutto e di tutti pur di arrivare al proprio scopo.

[zephyr83]

Originariamente inviato da Pino90

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?

due possibili ipotesi, analfabetismo funzionale oppure "voglia di commentare senza aver letto la notiza"

[lollo9]

a me pare che se questo studio volesse far luce sui sistemi di code review, quality gate, annessi e connessi, ad un risultato ci sono comunque arrivati.

la code review ha funzionato talmente bene che oltre ad un revert si sono beccati pure un ban in faccia con relativo sputt...... in mondovisione.

ora gli tocca pubblicare questo tra gli outcome della ricerca

This reverts commit 0b8e125e213204508e1b3c4bdfe69713280b7abd.

Commits from @umn.edu addresses have been found to be submitted in "bad
faith" to try to test the kernel community's ability to review "known
malicious" changes.  The result of these submissions can be found in a
paper published at the 42nd IEEE Symposium on Security and Privacy
entitled, "Open Source Insecurity: Stealthily Introducing
Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
of Minnesota) and Kangjie Lu (University of Minnesota).

Because of this, all submissions from this group must be reverted from
the kernel tree and will need to be re-reviewed again to determine if
they actually are a valid fix.  Until that work is complete, remove this
change to ensure that no problems are being introduced into the
codebase.

non è che è arrivato un pincopallino qualunque a fare force push su master.

la linux foundation è inc..... per via del tempo perso a fare review, gate ecc. su codice o messo solo per fare volume, o per far finta di correggere bug, o per correggerne qualcuno alla carlona.
il tutto fatto scientemente senza informare nessuno

[cerbert]

Tralasciando i contributi di chi non completa la lettura di un articolo in lingua italiana ma commenta l'efficienza di revisori esperti su codice C/C++ il fatto che a me leggermente inquieta di queste scuse è che arrivano dai ricercatori ma non dal professore responsabile della ricerca, che avrebbe dovuto essere mentore e consigliere su come si conduce eticamente una ricerca che coinvolge persone.

Ci sono delle regole che dovrebbero essere ben note e sono:
1) i soggetti su cui avviene la sperimentazione devono essere volontari
2) i soggetti su cui avviene la sperimentazione devono essere informati di essere sottoposti ad esperimento anche se non vi sono rischi;
3) ai soggetti su cui avviene la sperimentazione deve essere SEMPRE proposta una qualche forma di riconoscimento per il tempo che concedono (che poi decidano di non riscuotere è una loro libera scelta, ma considerare gratuito il tempo altrui è, al minimo, maleducato)

Non regge la scusa "se avessero saputo, l'esperimento sarebbe stato falsato" ma è dimostrazione di una inesistente preparazione nel gruppo di ricerca su come si conduce un esperimento su persone.
Rispettate infatti le regole qui sopra (e altre a seconda della tipologia di esperimento) il VERO lavoro del ricercatore è predisporre l'esperimento in modo che la distorsione data dall'osservazione sia mitigata e misurabile. Normalmente si usano obiettivi "civetta", azioni surrogate, gruppi di controllo.
Se non sai fare questo non sei un ricercatore, sei solo un impiegato banconista che compila formulari.

Per questo spero che tra le azioni richieste all'Università del Minnesota la prima sia "obbligate i vostri ricercatori a dare ALMENO un esame di metodologie della ricerca sociale".

[pabloski]

Originariamente inviato da lollo9

la code review ha funzionato talmente bene che oltre ad un revert si sono beccati pure un ban in faccia con relativo sputt...... in mondovisione.

Esattamente. E vedo anche in questa discussione, che molta gente si limita a leggere i titoli.

Frasi tipo "La famosa sicurezza dell'open source, dove uno sconosciuto studente può introdurre una vulnerabilità senza essere notato per più di un anno" o "l'evidenza che sia stato tutto sommato semplice compromettere la sicurezza del kernel" mi lasciano perplesso.

Signori, il ban è avvenuto perchè i dev si sono accorti che quelle patch inserivano volutamente bug e vulnerabilità.

Se cercate una community lasca in fatto di code review, rivolgetevi a FreeBSD!

[Sp3cialFx]

le alternative sono due:

- o sono scemo che non so leggere l'italiano
- oppure ho letto la storia altrove (dove probabilmente l'ha letta l'autore dell'articolo - le testate serie riportano la fonte, sapete?) in cui viene specificata meglio la cronologia degli eventi.

I ricercatori hanno fatto in tempo a pubblicare i risultati raggiunti ("vulnerabilità immature" e patch per farle diventare vulnerabilità vere e proprie) al "42nd IEEE Symposium on Security and Privacy". A febbraio.

Settimana scorsa ( https://lkml.org/lkml/2021/4/21/454 ) è stato fatto il revert. Dopo 2 mesi. Ma soprattutto dopo 2 mesi DOPO CHE E' STATO RESO VOLONTARIAMENTE TUTTO PUBBLICO. Se aprite il link è tutto riportato lì (tranne che il simposio si è tenuto a febbraio. Quello è stato omesso).

Ora ditemi nuovamente come funziona bene la procedura e come i dev si siano accorti tempestivamente della cosa.

[Manolo De Agostini]

Ciao a tutti, ho fatto una modifica al testo per chiarire un passaggio che non era limpido. Da qui: https://www-users.cs.umn.edu/~kjlu/p...cations-hc.pdf

Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.

In pratica il codice buggato, o vulnerabile, non è finito nel kernel perché i ricercatori hanno "svelato il bluff". Tutto il resto rimane invece così com'è.