Re:Jellyfish GPU Rootkit
by Avery3R on Monday November 11, 2019 @06:26PM
(#21510041)
I wouldn't really call this a rootkit, it seems more like a function instrumenter. To me it looks like the hooks are not persistent and require the LD_PRELOAD environment variable to be set to function, which is very easily detectable. The only cool thing here is storing the log data in GPU memory instead of the system RAM. The actual hook logic is also still running on the CPU.
[ Parent
| on HN ]
It’s like the ‘you can store a virus in a jpeg and running it just requires this decoder’ “scare” from a decade back.
MS07-052: Code execution results in code execution
That's very interesting but I have to disagree with the response. The vuln might be used iirc to bypass signature verification of the PE? It might also possibly be used to evade sandbox analysis of malware, AV heuristics and ML based approaches might also be thrown off guard.
But yes, It would have been a lot more interesting if there are cases where the executable is attacker controlled and the exploit would end up running code as the privileged parent process or some other user that has more rights.
Re:Jellyfish GPU Rootkit
by satanspastaroll on Tuesday November 12, 2019 @06:59AM
(#21513405)
Modifying the binary should change it's digital signature, making it invalid in the first place. Running unsigned code is running arbitrary code
No,what I meant was the header containing the signature does not get included in PE sig verification, since sig/certs are part of the header to begin with, or at least large parts of the header are not included. I vaguely remember bypass techniques that depended on this.
Don't joke. I have had security people report my stuff is insecure because there is a document upload feature and a user could upload a virus and name it virus.png and then a user could download it and rename it to virus.exe and run it.
Change the scenario to "download it and double click it, exploiting vuln in file format handler" and it's correct.
At that point you may as well ban all user generated content since one user might have an insecure OS
Well, security engineering is about tradeoffs and managing risk, you won't get far outlawing all sources of risk. The smart way to handle attachments is to scrub them somehow (re-encode, pdf2pdf etc).
That is actually a serious issue especially if you allow unicode and RTL override in the file name. Always validate input file type.
That's plausible and could have been implemented, by exploiting RCE vulnerabilities in jpeg decoder libraries.
Re:Jellyfish GPU Rootkit
by snagglegaggle on Monday November 11, 2019 @08:39PM
(#21510757)
Right -- I was excited that someone had figured out how to exploit the GPU to load unsigned code.
They also made another small project to hide executables in GPU memory on Windows: https://github.com/nwork/WIN_JELLY
I also don’t think it would work as-is on macOS due to two-level namespacing…
Even with the actual hook logic running on the CPU, this prevents a large amount of possible detection from various filesystem/workingmem vectors...
But the hook's .so file still has to be loaded from filesystem, so it should be still detectable?
And even if "hook logic" runs on the GPU, the actual function calls still have plenty of CPU parts. Check out rootkit/kit.c -- it is just plain old LD_PRELOAD rootkit, with a ton of calls running on CPU. Workingmem detector should have no problems matching this code.