He truly makes you wonder what he really is
Bonus picture with his brother Titus
- Posts
- 1
- Comments
- 89
- Joined
- 3 yr. ago
- Posts
- 1
- Comments
- 89
- Joined
- 3 yr. ago
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...
- JumpDeleted
Permanently Deleted
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*)
If you don't have the rights to share that ROM then you likely don't want to share It.
ROM sites are required to not hold a ROM for more than 24hrs or 48hrs, and I believe they rotate their
URLsfiles in order tocircumventabide by that rule.Frankly, why bother at all? Why not link to a ROM website directly? Unless ONLY YOU have that ROM, then it's more of a risk than a feature.
With this setup, I'd build an emulator box / movie player HTPC.
If you want to upgrade something, I'm fairly certain that your GPU is not your bottleneck. Gen4 intel goes way back, and I noticed quite a lot the upgrade from my Gen6 to my Zen2, and back then I was running an RX 480.
That of course means changing CPU, Motherboard and RAM (goodbye DDR3).
The only issue with the 1060 is the VRAM, which pretty much only limits your resolution output - especially in games (as they may have more than one render buffer / frame buffer) - and the texture details in modern games.
Playing movies won't be affected at all, IMO.
In a HTPC like that, I wouldn't upgrade anything. It's too costly to change CPU, Mobo and RAM just for a HTPC "out of curiosity". I would most certainly at least try to settle with it, and evaluate its shortcomings on the fly. You'll always be able to upgrade it at a second time.
Maybe just double check your storage, a HTPC should run an SSD as you likely don't want to wait 2 minutes for it to boot.
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 echoingfilenames 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)oeval $(ls)?Evidenzio che
evalnon 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.
It only depends whether the app and its OS/kernel interface use a 32-bit value to store the time information.
32-bit architecture or OS has nothing to do with this bug, for example 16-bit architectures must've used 32-bit time, too (otherwise they'd be able to only count up to 32-65 seconds).
I am using bazzite for gamedev and it is AWESOME.
It is immutable but ships with distrobox and boxbuddy, which lets you easily create linux containers with mutable systems (i.e. I am currently developing on a fedora container with Qt Creator, for example) and you can install your packages in that terminal.
No chances of breaking your main OS.
I set up my instance like follows:
Boxbuddy -> New distrobox container -> Fedora -> Give it a name.
Wait for the installation (should be about 300MB IIRC).
In the start menu you will now be able to run your instance's terminal (search for your instance name).
sudo dnf install qt-creatorBack in boxbuddy, in my instance I selected "show installed gui applications", selected Qt Creator -> Add to applications menu.
Qt Creator then shows up in the start menu (search for either Qt Creator, or your instance name).
It will run in the container, but has full access to your home directory for development.
I could then install all my other required packages from the same terminal that I installed qt-creator from.
Easy peasy.
Disclaimer: Typing from my phone. The instructions may not be exactly like I said, but those are the steps.
No terminal magic is needed in Bazzite to make this work.
I'd understand if it wasn't a game developer, but this looks like a clear case of piggybacking.
Also, fuck gambling.
A Tor client of some sort. Not a VPN per se, but uses the same technique times 1000 to mask your location/ip as it goes through many more routers, thus you still depend on someone else's computers: their willingness to provide you a service (which is kind of a given in a Tor network) and their availability.
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!