Systemd 230 Opens Up A New Graphics Vulnerability & FBDEV Still Should Die
A change made in the recent release of systemd 230 makes it easy for rogue user processes to be able to spy on your desktop, assuming a few conditions are met.
If you are using FBDEV, such as with Wayland's Weston FBDEV back-end, other user processes can now read from the frame-buffer device. The change in systemd is, "Framebuffer devices (/dev/fb*) and 3D printers and scanners (devices tagged with ID_MAKER_TOOL) are now tagged with 'uaccess' and are available to logged in users."
Now with the frame-buffer devices being available to logged-in users, other processes can more easily fetch the contents of the FBDEV frame-buffer. Of course, systemd isn't entirely at fault since FBDEV isn't secure and for years has been a call for killing FBDEV in the kernel, but has yet to be deprecated in the kernel.
Daniel Vetter, the Intel DRM driver maintainer, confirmed this systemd 230 change does have an adverse impact on FBDEV:
If you are using FBDEV, such as with Wayland's Weston FBDEV back-end, other user processes can now read from the frame-buffer device. The change in systemd is, "Framebuffer devices (/dev/fb*) and 3D printers and scanners (devices tagged with ID_MAKER_TOOL) are now tagged with 'uaccess' and are available to logged in users."
Now with the frame-buffer devices being available to logged-in users, other processes can more easily fetch the contents of the FBDEV frame-buffer. Of course, systemd isn't entirely at fault since FBDEV isn't secure and for years has been a call for killing FBDEV in the kernel, but has yet to be deprecated in the kernel.
Daniel Vetter, the Intel DRM driver maintainer, confirmed this systemd 230 change does have an adverse impact on FBDEV:
Yeah, if both weston and your screen grabber uses native fbdev API you canIf you are using Weston's DRM back-end, the situation is more secure than FBDEV. There's been calls to stop making FBDEV drivers besides the call to deprecate FBDEV, but no firm action taken yet in the kernel. At least though more ARM SoC vendors are now focusing on producing DRM/KMS drivers than FBDEV.
now screenshot your desktop. And since fbdev has no concept of "current owner of the display hw" like the drm master, I think this is not fixable. At least not just in userspace. Also even with native KMS compositors fbdev still doesn't have the concept of ownership, which is why it doesn't bother clearing it's buffer before KMS takes over. I agree that this should be reverted or at least hidden better.
Also, can we just burn down fbdev please ;-)
-Daniel
32 Comments