@paoloredaelli

> @informapirata @informatica
>
> @quoll
> "Su quali shell esiste questa falla?"

Apparentemente, quelle dove esiste il comando 'eval' per interpretare una stringa.

trellix.com/blogs/research/the…

Ciao!
C.

Ma di cosa stiamo parlando? "A seemingly benign operation" quando faccio eval su un input non sanificato?

Ma quale diavolo sarebbe un utilizzo pratico e costruttivo di fare eval $(echo $f) o eval $(ls) ?

Evidenzio che eval non apre un file con il programma di default (per quello si userebbe xdg-open), bensì esegue una stringa contenente comandi shell.

Dunque cosa ci si aspetta di utile da un eval mydocument.txt ?

Edit: Per non evidenziare che NESSUNA SHELL di default fa eval di filename. Per rientrare in questa falla devi aver eseguito uno script che VOLONTARIAMENTE esegue eval su dei filename.

Ma se scrivo un articolo su un file nominato "rm -rf ~" divento un ricercatore?

Ciao!

>
> Edit: Per non evidenziare che NESSUNA SHELL di default fa eval di filename. Per rientrare in questa falla devi aver eseguito uno script che VOLONTARIAMENTE esegue eval su dei filename.

Magari: "eval di un comando, costruito dinamicamente che, contiene una variabile che fa riferimento a quel nome file, senza un corretto escaping". E già non mi pare così impossibile. Ovviamente il problema è l'uso disinvolto di eval (forse sono stato ambiguo nel mio messaggio prima, ma intendevo questo), ma — da tempo — mi sto rassegnando all'idea che il numero di errori in un codice, di qualunque genere, sia sempre sottostimato indipendentemente dalla stima! 😁

Ciao!
C.

EDIT: aggiunto "senza un corretto escaping"

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:

trellix.com/en-us/img/newsroom…

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.

@sgh
>
> Ciao,

Ciao!

>
> Certamente, posso concordare che il problema risiede nell’uso disinvolto di eval.
>
> Anzi:
>
> Il problema _*risiederebbe*_ nell’uso disinvolto di eval.

[…]

> Dunque rinnovo la mia domanda in generale: Qualcuno ha qualche esempio di uno script che realmente triggera questo exploit?

Direi di sì, lo avevo trovato ieri, ma era già conosciuto. 😀

bugs-devel.debian.org/cgi-bin/…

Per il resto mi trovo complessivamente d'accordo. Mi pare che parzialmente: "mi occupo sicurezza" vada letta come: "mi occupo di marketing". 😁

Ciao!
C.