
Jellyfish GPU Rootkit - badrabbit
https://github.com/nwork/jellyfish
======
Avery3R
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.

~~~
tinus_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.

~~~
baroffoos
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.

~~~
fulafel
Change the scenario to "download it and double click it, exploiting vuln in
file format handler" and it's correct.

~~~
baroffoos
At that point you may as well ban all user generated content since one user
might have an insecure OS

~~~
fulafel
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).

------
keyle
Last Commit 15 May 2015?

------
waldfee
> Can snoop on cpu host memory via DMA

That's why we have IOMMU

~~~
AstralStorm
You can probably still snoop on just GPU memory, scraping the screen. (Also
replacing.) Big security hole, as GPUs now have fast video encoders or enough
speed to OCR. Hope your driver set up framebuffer in a separated MMU area on
the card. (Not in Windows they don't.)

Hopefully this cannot jump MxGPU or GVTg or GRID barrier - GPU virtualization.

~~~
glisse
Modern GPUs (AMD, Intel and NVidia) have a per process page table so the worse
you can do is access memory mapped to the GPU for _your_ process. That is
assuming you can guess the virtual address of those, a wrong guess and the GPU
context for your process will hang and you loose everything (for the process).

So if IOMMU is disabled you would still have to be able to find a way to re-
program your process GPU page table which is not map in anyway to the process
(ie only accessible by the kernel driver).

So i say good luck to you sir.

------
basicplus2
What we need is a rootkit that the computer owner controls, a master of all
rootkits to prevent other rootkits gaining a foothold in the first place

~~~
Avery3R
Hardware debugger, you can JTAG intel boards with a cheap USB cable.

------
baybal2
Now, who put WebGL and WebCL into the browser? Just how many of GPU
instructions can be made to sneakily peek/write into host's memory?

P.S. Perfect, now Google disabled the option to turn off webgl in Chrome

~~~
badrabbit
I think browsers are sandboxed even for GPU access. But I am now curious if
persistent tracking can be done using GPU memory due to warm reboot
resilience.

~~~
fao_
> I think browsers are sandboxed even for GPU access. But I am now curious if
> persistent tracking can be done using GPU memory due to warm reboot
> resilience.

You probably seen this, but in case you haven't:
[https://arstechnica.com/information-
technology/2017/02/now-s...](https://arstechnica.com/information-
technology/2017/02/now-sites-can-fingerprint-you-online-even-when-you-use-
multiple-browsers/)

~~~
badrabbit
I have not heard of that specific technique. Thanks.

------
peter_d_sherman
All accelerated graphics cards (that is, all but the earliest, earliest
graphics cards) have had some form of a CPU (now called a GPU) and memory on
them... that is, they all can be thought of as miniature computers on your
computer...

Many of those CPUs were originally constrained to only run vendor-supplied
routines in vendor-supplied ROM on the graphics card -- those cards (assuming
we discount the potential of Nation-State tampering) would have been more-or-
less secure, by virtue of the fact that a PC supplied program couldn't
interact with the graphics card's CPU (GPU).

The most secure graphics card (aside from those early ones - Hercules MDA
anyone?) might be NO graphics card -- that is, you have a computer on the one
hand, and an RS-232 (or other) connection to a dumb terminal, on the other...

Benefit: Any data going to or from the dumb terminal, at least could be
captured and audited... And if you really wanted good auditing, you'd stay
away from cursor positioning routines, like ANSI/Curses/Termcap/etc, and use
straight text... but then of course you wouldn't be able to run cool programs
like text emacs...<g>

Anyway, this repository is more proof (Spectre, Meltdown, Foreshadow, etc.)
that that which is claimed to be secure -- might not be all that secure...
which is sad, but the state of our current reality...

~~~
theamk
Where do you see this? What you say is true in general, but this repo in
particular is nothing like that. It is operating entirely using vendor
providing APIs, an in particular it fully respecting process boundaries - the
GPU code is only alive as long as containing process is, and only has access
to the data that CPU part explicitly granted it.

Really, the only thing bad here is that some memory scan engines in
antiviruses cannot monitor this. But how many memory scanning Linux
antivirusesave you seen?

~~~
badrabbit
There is the warm reboot persistence aspect of it regarding gddr mem but yeah,
this isn't some earth shattering work.just an interesting way for malicious
code to be more evasive.

