Yeah, I had to pay, I don’t think there’s a way around that but I didn’t mind.

Yeah, there was nothing about language in it, but I took it anyway just for the sake of it.

Wish I could take an official one, purely out of curiosity.

Just took a test out of curiosity, but the result screen is much different.

Disclaimer: Don’t take too much of the score for granted, the test isn’t that comprehensive, and just by knowing basic math and intermediate logic you may reach a similar score.

Yeah, I don’t think what I suggested should do anything at all in this specific case…

Can you verify if Jellyfin is remuxing without transcoding? I.e. changing container but without touching the frame/audio data.

I believe while you playback it should say in the administration panel, in the card that represents the active session you have this issue in.

Remux and transcode happen on disk, unless you manually set the temporary path to a decently sized tmpfs partition.

I solved a similar issue doing exactly what I just wrote: tmpfs (can’t recall what its name is under Docker) and set the transcoding path accordingly. I also had to tweak the transcode files’ lifetime:

• Limit trancode checked
• Remove segments checked
• Limit after: 30
• Segment lifetime: 1800

This has done wonders for me for both on-the-fly remux and transcodes, but I had to reserve a beefy tmpfs (I think I have like 8GB set right now).

Very cool critters indeed!

Oops, in spite of writing it in the alt text, I just realized that it’s not really clear, Pepper and Titus are two domesticated ferrets!

He truly makes you wonder what he really is

Bonus picture with his brother Titus

The source tarball is always autogenerated from the git repository state at the release point’s commit.

Are you using the docker version or the manual installation version? (After using the manually installed version for a while, I suggest the docker one as upgrades are much less painful)

I only had the demo of it and I just kept going up the hill and building up as much speed as possible, only to then let myself go OOB - for hours and hours.

Ah… Lovely memories of a brainless kid just messing around with his computer…

Prey 2017.

Such an underrated game on its own.

The ambient is so immersive to me, both indoors and outdoors, so many details, being able to interact with so many objects in so many ways, even the Looking Glass, I just wish it lasted much more… the ending was however quite disappointing in all aspects, especially from the story perspective and in the “I wanted more” perspective.

It’s just the fact that, at some point, if you want a faster computer, you’re bound to have DDR5.

AMD 5000 is fast, but how does it compare to last gen? Is there a 5000 CPU that can get the same score as a high end 9000 CPU?

What if you have a homelab server to upgrade but find out you need more PCIe lanes?

Other than that, yeah, you don’t need DDR5, but DDR4 is slowly going out of production and is also rising in price… so you’re screwed either way.

Small improvement: Allow for spaces near the Equal sign in the regex (i.e. Port\s*=\s*)

That would basically give out my wanking schedule to the processor…

I used to love it, but wiki.js 2.0’s editor is very unfriendly to non-tech users. 3.0 could’ve been the solution, but after waiting over and over for wiki.js 3.0 to release, after being years late on their schedule and with less and less blog posts (the last blog post about 3.0 is two years old!!) we chose to migrate to Bookstack.

Honestly, given that they should be purely compressing data, I would suppose that none of the formats you mentioned has ECC recovery nor builtin checksums (but I might be very mistaken on this). I think I only saw this within WinRAR, but also try other GUI tools like 7zip and check its features for anything that looks like what you need, if the formats support ECC then surely 7zip will offer you this option.

I just wanted to point out, no matter what someone else might say, if you were to split your data onto multiple compressed files, the chances of a bit rotting deleting your entire library are much lower, i.e. try to make it so that only small chunks of your data is lost in case something catastrophic happens.

However, if one of your filesystem-relevant bits rot, you may be in for a much longer recovery session.

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.

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?

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.