When X is started via startx, the user who started it can easily kill it by sending SIGKILL to the X server. The result is an unusable system that can only be rebooted via ssh or a hard reset. Steps to reproduce: 1) Log in as a normal, unprivileged user 2) startx 3) killall -KILL X Result: The system doesn't respond to keystrokes or mouse movements any longer There are two possible solutions: 1) Don't install /usr/bin/Xorg with the setuid bit enabled. 2) X should set its "real uid" by doing setreuid(0, -1) before it initializes the hardware. I've tested this with x11-base/xorg-x11-6.8.2-r6. I report this as a security issue, because it _is_ a security problem (DoS) if a computer is used by more than one person.
marking this as INVALID, if you can run X you can already lock the keyboard.
(In reply to comment #1) > marking this as INVALID, if you can run X you can already lock the keyboard. What do you mean by "lock the keyboard"? How can this be done without proper permissions? Ok, you could steal it, but that's not the point. What if someone kills the X server accidentally? I think at least ctrl-alt-backspace is always working in X (if it's not disabled in /etc/X11/xorg.conf). And in the virtual consoles you have alt+fx to switch to another virtual console... Of course this only helps if you have a virtual console that only root can use...
As for me, if you have physical local access to the computer, you can already shut down it, or at least unplug the power supply wire. If this issue is remotely exploitable (or via SSH), then it is a security issue. Otherwise not. If it was, the power button would already be a security issue. Oh yes, maybe the screen and the keyboard are far from the box, and the box is in a secure area, but this is rather rare. Maybe it is an X-system bug, but not a security issue.
mrsteven: login on a console and run showkey, you will see what i mean.
@Travis Ormandy: Ah, thanks. But I think this is also a problem. An unprivileged process should not be able to lock up the system by changing the keyboard mode and, for example, being stuck in an endless loop. There's a reason why /usr/bin/loadkeys fails when being called by an unprivileged user. And startx can be called over ssh, so this is also exploitable via ssh. At least it is a problem if X isn't already running.
mrsteven, I just talked with spyderous, gentoos maintainer of X. He generally agrees with us that this is invalid, but recommended that you should consider to file this bug upstream. Kind regards, DerCorny
Ok, then I'll bug the Xorg folks... I've already posted a question to the kernel mailing list about that KDSKBMODE ioctl (which is used by showkey). Let's see what the kernel developers will say...
