Ciao 380, grazie per aver speso il tempo di scrivere questa ottima disanima: sei un ottimo divulgatore! Aggiungo solo qualche considerazione: Il 13 Aprile 2024 17:45:54 CEST, "380°" ha scritto:
Perché build-to-host.m4 è uno dei diversi file autogenerati da autotools e autoconf e quei file non sono umanamente leggibili, [...]
La soluzione a questo /primo/ problema è facilissima, quindi: i "downstream consumer" devono semplicemente smetterla di essere _pigri_
Ovvero smettere di usare la procedura ``` ./configure ... make make install ``` Giusto per chiarire la complessità della "soluzione facilissima" a chiunque abbia mai scaricato e compilato un tar.gz Direi che questo è un caso da manuale di soluzione semplice tutt'altro che facile. :-)
Usando direttamente il codice preso dal VCS upstream si azzererebbero le possibilità di riuscire a nascondere un trojan (tipo build-to-host.m4) in grado di sovvertire il processo di build e fargli installare la backdoor a sua volta nascosta in file binari camuffati da file necessari per i test.
Purtroppo non basta lontanamente. Leggi questo bell'esperimento mentale di Vegard Nossum <https://www.openwall.com/lists/oss-security/2024/04/17/3> Cito solo la conclusione a seguito di 6 possibili mitigazioni (tutt'altro che facili) dell'attacco che Nossum ha ideato: ``` Even if we did all of this, it would of course still not be enough. The underlying problem is having things that are unreadable or unreviewable -- binary files, inscrutable code (whether shell scripts, makefiles, m4 code, or, in some cases, Perl code). ``` Conclusione comunque parziale: più in generale se un qualunque software (kernel, libreria, script di build...) non può essere compreso interamente (in un tempo ragionevole) qualunque sistema cibernetico che ne dipenda è vulnerabile e probabilmente già compromesso. Il problema è la complessità. Aggiungere complessità non lo risolverà, potrà solo nasconderlo. Giacomo