5

From what I understand /dev/fb0 holds information of data displayed on the screen.
Isn't it a security issue that I can read from it as an unpriviledged user? Doesn't this mean any application can spy on the screen?

Also, is there a similar issue on other operating systems?

  • When someone is able to execute code on your machine you're basically done for. Building fences behind the main perimeter would do nothing except annoying those who try to develop a simple screenshot script – BlueWizard Feb 21 '18 at 5:52
  • 1
    What if a malicious party gained access to an application generally considered benign, e.g. Firefox? Now millions of users would be at risk. It's not realistic to assume any user is aware of all the code running on their machine. – Markonius Feb 21 '18 at 7:45
  • @MackThax is correct. Defense in depth is very important in all of information security. There's a reason systems have multiple layers of privilege separation with isolation between userspace and kernelspace and even isolation within userspace (MAC, DAC, ACL, etc) and don't simply run everything under ring 0. – forest Feb 21 '18 at 8:08
  • @MackThax yeah you're right – BlueWizard Feb 27 '18 at 5:39
2

Hah, interesting. I just tested this on a console and you're right:

unprivileged $ echo "ABABABABABAB" > /dev/fb0

(writes a few pixels into the upper left corner of the screen)

unprivileged $ dd if=/dev/fb0 of=read_fb.dat bs=12 count=1
unprivileged $ cat read_fb.dat
ABABABABABAB

So an unprivileged user can write into and read from the framebuffer. It didn't work under my X server because I haven't configured it to use the framebuffer, but it might work if I changed my configuration (then again, since X has no isolation to speak of and an application can listen in on any another (including mouse movements and key strokes), this doesn't really add anything to the attack surface if you're running under X - Wayland should make this better).

So if I managed to get an unsuspecting user to run a program which read the screen, I could get his plans for world domination (or the parts of it which are visible on the screen, anyway):

$ cat my-secret-plan-for-world-domination.txt
$ ...
$ program-which-reads-screen

Or even worse:

unprivileged $ sudo /bin/bash
root $ output-some-privileged-information-to-screen
root $ exit
unprivileged $ program-which-reads-screen

But if you think about this, this really isn't very surprising, because every time you take a screenshot, you're doing the same (on Linux, a quick search reveals fbgrab which takes a screenshot using the framebuffer). So I'd say that any operating system that lets you install programs that are able to take full-screen screenshots has the same issues.

The thing to be aware of, I think, is that someone could install a screen recorder without your knowledge, which would then record your whole session, even if you're not running under X and not expecting it. It's the pendant to a keylogging scenario.

In Qubes OS, the framebuffer is handled by the dom0, so I'd assume that the other vms cannot get access to the whole screen, but just to the part of it that displays their windows. This still means that applications running in the same VM can spy on each other, but not on output generated in another VM, and only a dom0 process could record the whole screen.

  • FWIW, having /dev/fb0 mode readable/writable by your user is not strictly required. You can easily change your udev rules or your user's groups or whatever your distro uses and limit access without changing much. Of course, even if it's not readable, various other TTY-related files can still give away the contents of individual virtual terminals... – forest Feb 21 '18 at 6:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.