1·
12 days agoMa 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,
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?
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
Anche questa affermazione è molto fuorviante.
Dai miei test, nè echo, nè printf, nè for, nè il pipe redirection (>“$file”) hanno triggerato l’exploit.
Altrettanto fuorviante.
Ok, tiriamo una riga su “echoing filenames without sanitization” perchè abbiamo determinato che non c’entra una emerita:
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:
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.