sì, cavolo, hai ragione 😅
Sto proprio cotto 🤣🤣🤣

Ora ho corretto 🙏

Ah! Sì! Ricordo! Vabbé tanto SEO è morto, finalmente e definitivente, quindi liberi tutti!

Edit: non bastava aggiungere il rel="nofollow" ai link esterni?

@prealpinux

Credo che qui il problema risieda in primis nella presentazione dell'articolo:

Questo sembra un semplice advisory, come per dire, "ehi, attenzione, stanno girando mail pericolose anche per sistemi Linux".

Però il titolo mi risulta invece fuorviante:

"Una email di phishing può prendere il controllo del tuo sistema Linux senza aprire il file, questo trucco sfugge alle scansioni Antivirus"

Questa affermazione è priva di fonti: nell'articolo non viene menzionato nessun sistema che ha subito danni da questo attacco o nessun antivirus che abbia mal detezionato questo fantomatico exploit, oltretutto le condizioni perché questo attacco possa veramente avvenire mi sembrano poco concrete:

Intanto devi aver ricevuto questa mail con file RAR (fin qui OK) ed aver aperto ed estratto il file sul tuo disco (e qui già sei un minchione perché a differenza di quello che viene detto nell'articolo, questa operazione non la fai "mentre sei distratto a compilare la survey").

Poi devi avere "una shell a rischio" (quali?), cioè una che esegue i file mentre fai un ls (ma ls non è un eseguibile, cioè che non c'entra nulla con le shell? E da che mondo e mondo esiste una shell che esegue un file mentre li itera?)

Poi devi avere eseguito uno dei comandi a rischio in questa shell (però teniamo a mente: sei un minchione che ha fatto una survey da una mail malevola che ha estratto un RAR, ma comunque fosse hai aperto il terminale nella cartella dove hai estratto il tuo RAR ed hai fatto questo fantomatico ls che magicamente è diventato parte della tua shell)

Invece in seguito alla menzione che viene usato io_uring per evitare gli Antivirus... vergogna a chi dichiara che il proprio antivirus sia aggiornato se non monitora anche queste system calls (sarei però curioso di capire di quale Antivirus si stesse parlando, dato che misteriosamente non ne viene menzionato nemmeno uno).

Viene inoltre menzionato che il nome del file è apparentemente illegale (cioè?) ma il tuo semplicissimo estrattore di file RAR è tranquillamente in grado di creare questo file... smentendo la prima affermazione. Teniamo a mente che i filesystem Linux sono sempre stati molto permissivi con i nomi dei file e non ci vedo nulla di strano che qualcuno provi a farci degli exploit.

Se poi davvero esistesse questo exploit, la mail come mezzo di trasmissione (o il fatto che si parli di un file RAR) sarebbe irrilevante: basterebbe un file scaricato, o ricevuto tramite chessò Discord, negli ultimi 20 anni, anche zip, tar, sotto gzip o xz...

Sinceramente mi suona molto di un articolo farlocco, destinato solo a produrre spauracchio nei confronti dei sistemi Linux.

Poi per evitare di raccontare un sacco di cazzate ho anche fatto la prova del nove: ho creato un file malevolo (tramite shell, nulla di così "illegale" come viene menzionato nell'articolo), e non ho trovato il modo di farne eseguire lo script presente nel nome del file.

Ho provato ls (che effettivamente è /usr/bin/ls quindi vergogna agli autori che vogliono far credere che ls sia un comando della shell), ls -la, for file in *, find.

Ho provato a fare cat [TAB] e il nome del file è stato correttamente sanitizzato dalla mia shell di default (bash), e l'output di cat era corretto.

Insomma, un articolo da buttare nel cestino dell'immondizia.

@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.

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"

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?

Gli hacker affermano di aver venduto milioni di credenziali PayPal, ma gli esperti sospettano un gioco scorretto
Il set di dati presumibilmente include password, e-mail e URL per attacchi automatizzati
Gli esperti affermano che il campione trapelato è troppo piccolo per confermarne l'autenticità e il suo basso prezzo mette in dubbio la sua legittimità

@informatica