Buongiorno, Executive summary: l'intera questione si può riassumere in una mancanza di verificabilità _pragmatica_ di /alcuni/ file necessari durante le /varie/ fasi di compilazione (build phase), solitamente distribuiti dagli autori del software (upstream) attraverso le cosidette "release tarball" e solitamente usati dagli utilizzatori (downstream) per compilare il binario ed eventualmente distribuirlo.
Dopo l'introduzione, è il momento di addentrarci un pochino nelle questioni tecniche (_sistemistiche_) necessarie per una analisi efficace della situazione e di conseguenza ipotizzare una soluzione per _azzerare_ questa classe di attacchi: non sto esagerando, azzerare. Cercherò di essere sintetico al massimo ma certe cose non si possono semplificare senza complicarne irrimediabilmente la comprensione. Innanzi tutto, la pagina ufficiale di Lasse Collin in merito alla backdoor è questa: https://tukaani.org/xz-backdoor/ (1) ...ma non è necessario attendere che lui abbia tempo di scrivere l'articolo che ha in programma, sappiamo già abbastanza. Affinché quell'attacco funzionasse, sono state _indispensabili_ due condizioni: 1. sia il codice di injection (il trojan) che il codice della backdoor stessa (il cosiddetto payload) erano _molto_ nascosti: il trojan in tre (quattro?) script concatenati e offuscati (Stage 0..3), il payload in due files inseriti dagli attaccanti con lo scopo dichiarato di servire per i test del software, che normalmente fanno parte delle fasi di build. Questo è ben spiegato in «xz/liblzma: Bash-stage Obfuscation Explained» [2] --8<---------------cut here---------------start------------->8--- the bash part is split into three (four?) stages of interest, which I have named Stage 0 (that's the start code added in m4/build-to-host.m4) to Stage 2. I'll touch on the potential "Stage 3" as well, though I don't think it has fully materialized yet. Please also note that the obfuscated/encrypted stages and later binary backdoor are hidden in two test files: tests/files/bad-3-corrupt_lzma2.xz and tests/files/good-large_compressed.lzma. --8<---------------cut here---------------end--------------->8--- 2. il primo stadio (Stage 0) trojan era presente _solo_ dentro la release tarball rilasciata upstream, quello pubblicato nel repository git ufficiale (sempre upstream) era diverso. Questo è ben spiegato nelle "FAQ by Sam James" [3] citato in (1): --8<---------------cut here---------------start------------->8--- * The release tarballs upstream publishes don't have the same code that GitHub has. This is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf. The version of build-to-host.m4 in the release tarballs differs wildly from the upstream on GitHub. [...] TODO for this doc [...] * Explain dist tarballs, why we use them, what they do, link to autotools docs, etc * "Explaining the history of it would be very helpful I think. It also explains how a single person was able to insert code in an open source project that no one was able to peer review. It is pragmatically impossible, even if technically possible once you know the problem is there, to peer review a tarball prepared in this manner." --8<---------------cut here---------------end--------------->8--- Perché nessuno si è accorto che build-to-host.m4 presente nella "release tarball" differiva da quello in git? Perché build-to-host.m4 è uno dei diversi file autogenerati da autotools e autoconf e quei file non sono umanamente leggibili, sono sostanzialmente analoghi a quello che in gergo tecnico si chiamano /binary seeds/ [4], anche se scritti in linguaggio shell (credo bash). Al contrario, I file (sorgenti) usati da autotools e autoconf per autogenerare build-to-host.m4 e compagni sono decisamente più umani, si prestano quindi a poter essere verificati e sono ovviamente presenti sia nel VCS ufficiale che nelle "release tarball" ufficiali. La soluzione a questo /primo/ problema è facilissima, quindi: i "downstream consumer" devono semplicemente smetterla di essere _pigri_, perché «this is common in C projects so that downstream consumers don't need to remember how to run autotools and autoconf». Quindi i "downstream consumers" semplicemente devono ricordarsi come si usano autotools e autoconf e _usarli_ nelle loro fasi di build, senza scorciatoie. Rimane però il _vero_ problema: controllare che davvero la release tarball contenga esattamente lo stesso codice distribuito nel VCS e NON quello con _aggiunta_ una backdoor (che sia ben nascosta o no non fa differenza) è un lavoraccio e _pragmaticamente_ non lo possono fare le persone; andrebbe automatizzato ma non è possibile, perché le release tarball non sono riproducibili. [5] L'idea che sta raccogliendo più consensi nel progetto Guix - la distribuzione, quindi downstream - et al è quella che le release tarball siano /inemendabili/ dal punto di vista della riproducibilità [6], quindi stanno valutando come effettuare la transizione dai sorgenti presi dalle release tarball a quelli presi direttamente dal VCS, come già avviene per molti pacchetti i cui sorgenti sono disponibili via git. 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. Fine della seconda parte. Sto valutando una terza parte per illustrare cosa _non_ risolve questi problemi, ma non vorrei annoiare perché non sono sicurissimo sia on topic in questa lista e... ho la sindrome dell'impostore. Loving, 380° [1] credo che più del 90% di "upstream" usi qualche VCS (es. git, SVN, ecc.) per gestire il proprio codice. [2] https://gynvael.coldwind.pl/?lang=en&id=782 [3] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 [4] http://joyofsource.com/reduced-binary-seed-bootstrap.html [5] la riproducibilità del software è una caratteristica tecnica molto importante sulla quale qui mi tocca soprassedere per non ammazzare di noia chi legge, che se interessato saprà dove cercare [6] per approfondimenti sul perché e il percome si veda ad esempio questo thread nella mailing list guix-devel: https://yhetil.org/guix/8734s1mn5p....@xelera.eu/ -- 380° (Giovanni Biscuolo public alter ego) «Noi, incompetenti come siamo, non abbiamo alcun titolo per suggerire alcunché» Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>.
signature.asc
Description: PGP signature
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
