Ciao,

Certamente, posso concordare che il problema risiede nell’uso disinvolto di eval.
Anzi:
Il problema risiederebbe nell’uso disinvolto di eval.
E l’articolo cosa dice?

No executable permission required initially just unpacking or listing the archive contents in a script is enough to trigger infection.

Chiaramente una informazione falsa o come minimo fuorviante, in quanto PROPRIO NELL’ARTICOLO hanno unpackato il file RAR e hanno listato i nomi dei file estratti senza avere effetti collaterali:

https://www.trellix.com/en-us/img/newsroom/stories/fireless-threat-of-vshell-3.jpg

Anything that expands filenames and processes them using eval, echo, printf, or logging can accidentally execute such a filename-payload"

Anche questa affermazione è molto fuorviante.
Dai miei test, nè echo, nè printf, nè for, nè il pipe redirection (>“$file”) hanno triggerato l’exploit.

the attacker turns a simple file listing operation into an automatic malware execution trigger.

Altrettanto fuorviante.

This technique abuses a very common and dangerous pattern in many Linux shell scripts: evaluating or echoing filenames without sanitization.

Ok, tiriamo una riga su “echoing filenames without sanitization” perchè abbiamo determinato che non c’entra una emerita:

This technique abuses a very common and dangerous pattern in many Linux shell scripts: evaluating or echoing filenames without sanitization.

OK, Il problema risiederebbe nell’uso disinvolto di eval.

Però su una cosa io non concordo: da quando in qua è “very common” fare “evaluating filenames without sanitization”? Negli ultimi …8-10 anni… ho visto sempre e solo degli utilizzi di backticks, che non sono soggetti a questo problema (testato e verificato).

Certo, eval è una operazione intrinsecamente non sicura, e questo lo si sa da decenni, così come è risaputo che in C anche system() è una operazione intrinsecamente non sicura.
Infatti esistono svariati modi per sanificare il contenuto di eval (printf %q, backticks…), così come esistono anche per system (anche se in C il tema è più complesso) e, su tutte le shell più utilizzate, oramai non è neanche più necessario usare eval in quanto esistono abbastanza alternative che non necessitano di una sanificazione manuale degli input.

Però secondo l’articolo, “evaluating filenames without sanitization” è “very common”.
Il problema è che tutti gli esempi che sono stati mostrati sono sintetici, puramente a dimostrazione di una falla di sicurezza che si trova però all’interno dello script stesso.
Dunque rinnovo la mia domanda in generale: Qualcuno ha qualche esempio di uno script che realmente triggera questo exploit?

Infine ritorno alla tua osservazione, che trovo comunque corretta:

eval di un comando, costruito dinamicamente che, contiene una variabile che fa riferimento a quel nome file, senza un corretto escaping

Però intanto devi avere uno script fallato (perchè, a parere mio, è lo script che funzionalmente è la tua falla di sicurezza, non la presenza di un file con un nome “strambo”), poi devi far sì che operi nella stessa cartella in cui hai estratto tale file, proveniente da una mail di phishing, con questo RAR che hai volontariamente aperto ed estratto; e qui io mi dispiace ma rigioco la carta “minchione”.

Oltretutto, se questo exploit è triggerato dall’estrazione di un file RAR arrivato da una mail non sollecitata, da un mittente sconosciuto, allora che differenza ci sarebbe tra questo attacco ed il fare doppio-click sul file VBS nella tipica mail che probabilmente tutti abbiamo ricevuto e che ti vuole installare un keylogger su Windows? Anche in quel caso avresti aperto il file VBS senza pensarci mentre che facevi la survey?

Le uniche informazioni concretamente utili che ho trovato nell’articolo sono riferite ad un virus per Linux scritto in Go che si maschera dietro al nome kworker/0:2.