Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
On Sat, Oct 15, 2005 at 06:03:31PM +0200, Rudolf Polzer wrote: > Package: linux-image-2.6.12-1-powerpc > Version: 2.6.12-10 > Severity: critical > Tags: security > Justification: root security hole > > > The non-suid command "loadkeys" can be used by any local user having > console access. It does not just apply to the current virtual console > but to all virtual consoles and its effect persists even after logout. > > A proof of concept would be (^V, ^C etc. refer to key presses on the > console): > > loadkeys > keycode 15 = F23 > string F23 = "^V^C^V^Mecho hello world^V^M" > ^D > > Then log out and let root login (in a computer pool, you can usually get > an admin to log on as root on a console somehow). The next time he'll > press TAB to complete a file name, he instead will run the shell > command. > > Of course, the shell command could be more evil, e.g. add a line to > /etc/passwd, clear the screen to make it less obvious, sync and write > stuff to /dev/mem to cause a kernel crash so that most people would not > suspect anything but a hardware fault. A demo exploit adding a line to > the password file, clearing the screen and logging out exists in form of > a shell script. > > As a solution, I propose that the loadkeys command (or more exactly, the > kernel interface it uses) should be restricted to root and instead one > could add a suid wrapper for loadkeys that only allows the system-wide > keymaps to be loaded. The old behaviour could still be made selectable > using a procfs file. > > If the last modification time of the manual page of loadkeys is true, > this bug exists in the Linux kernel at least since 1997. However, the > BUGS section of the manpage does not hint that the loadkeys command > can even be used as a root compromise and not just for stuff like > unbinding all keys. > > Plus, it might be good to have a way to disable chvt for non-root users. > Using chvt, a malicious user could do the same thing in an X session: > remap Backspace to another key, handle Ctrl-Alt-Backspace by chvt 1; > chvt 7 (so the video mode switches) and showing a fake login manager on > the X display. If chvt were not possible for mere mortals, the admin > would be able to disable all possible video mode switching caused by X > applications (like xrandr, xvidmode, dpms) in the xorg.conf file so that > he finally knows: if Ctrl-Alt-Backspace caused video mode switching, the > resulting login screen is genuine. > > Another solution would be a keymap-invariant non-remappable "zap" key > combination with the functionality of Alt-SysRq-K - but on an X screen, > it should tell the X server to exit instead of kill -9ing it so that the > video mode gets restored. And it should be able to make a kernel support > it without adding all of the other "Magic SysRq Key" features. Of > course, it should lock the keymap until the user tells the system to > unlock it again. > > Or, even better: a "root login key". That is, something unremappable > that causes a new VT to be created with a login prompt for root - and > while this VT is active, the keymap should be locked to the system-wide > standard keymap. Ideally, that "root login key" should also work from X > and maybe even when the X server has crashed. Hi, I recently received the following message through the debian Bug tracker. http://bugs.debian.org/334113 In a nuthsell it raises concernes about the effects of giving users access to VT ioctls and outlines a potential attack using loadkeys to execute commands as root. I took a very brief look over it, and the concern does seem valid to me. Most of the VT ioctls are only garded by the following permissions, the ioctl in question, which I believe is KDSKBSENT, is no exception: drivers/char/vt_ioctl.c: vt_ioctl(): line 377 /* * To have permissions to do most of the vt ioctls, we either * have * to be the owner of the tty, or have CAP_SYS_TTY_CONFIG. */ perm = 0; if (current->signal->tty == tty || capable(CAP_SYS_TTY_CONFIG)) perm = 1; A simple fix for this might be just checking for capable(CAP_SYS_TTY_CONFIG) in do_kdgkb_ioctl(), which effects KDSKBSENT. This more restrictive approach is probably appropriate for many of the other ioctls that set VT parameters. However, the changes will still affect all consoles and be persistant after the user logs out of the console. It would seem more logical to have the state apply only to the current console, and only for the duration of the session. The latter could be handled in user-space if the ioctls were privelaged. But I suspect adding the former might be somewhat difficult. The same kind of issue also seems to be relevant to many of the other VT ioctls. I'm not really familiar enough with the code to comment more, though I am happy to code-up ideas if people can point me in the right direction. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscri
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Horms <[EMAIL PROTECTED]> writes: >> Then log out and let root login (in a computer pool, you can usually get >> an admin to log on as root on a console somehow). The next time he'll >> press TAB to complete a file name, he instead will run the shell >> command. Why doesn't the intruder just simulate login process (printing "login: " and "Password:")? That's known and used for ages. The root user (and any other user) should press the SAK key before attempting login. It should a) reset terminal to a sane state, b) terminate and/or disconnect all processes from current tty. Alternatively, he/she should hw-reset/power-cycle the terminal, if possible (say, with serial/X-terminal). OTOH I don't know why ordinary users should be allowed to change key bindings. BTW: Not sure about Linux consoles, but in general ESCape sequences can redefine key bindings as well. That's why SAK/reset is so important. -- Krzysztof Halasa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo: > Horms <[EMAIL PROTECTED]> writes: > > >> Then log out and let root login (in a computer pool, you can usually get > >> an admin to log on as root on a console somehow). The next time he'll > >> press TAB to complete a file name, he instead will run the shell > >> command. > > Why doesn't the intruder just simulate login process (printing "login: " > and "Password:")? That's known and used for ages. > > The root user (and any other user) should press the SAK key before > attempting login. It should a) reset terminal to a sane state, > b) terminate and/or disconnect all processes from current tty. That does not help against the loadkeys issue if the attacking user is still logged in on another virtual console. Even when tty1 is active, a user owning tty6 can use loadkeys. Plus, the Linux SAK does not reset the keyboard mapping. And SAK does not reset the video mode, so when pressed on X, the terminal video mode is garbled until reboot (maybe it works fine with some framebuffer drivers, but with the stock VGA text console, it doesn't). X comes back up fine, but when pressing Ctrl-Alt-F1, X will restore the video mode it saw on startup - which is the mode of the previous X server the SAK has killed. > Alternatively, he/she should hw-reset/power-cycle the terminal, > if possible (say, with serial/X-terminal). Well, sometimes you have problems that powercycling would "hide" so you can't track them down if you powercycle the whole computer every time. > OTOH I don't know why ordinary users should be allowed to change key > bindings. For using foreign languages and keyboard mappings. But for that a suid wrapper around loadkeys would suffice - most distributions include more than enough keyboard mapping files already. > BTW: Not sure about Linux consoles, but in general ESCape sequences > can redefine key bindings as well. That's why SAK/reset is so important. If man console_codes is correct, they can't.
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Rudolf Polzer <[EMAIL PROTECTED]> writes: > That does not help against the loadkeys issue if the attacking user is still > logged in on another virtual console. Even when tty1 is active, a user owning > tty6 can use loadkeys. Sure. The problem is that mappings are shared between VCs but anyway it's solved by disabling user changes. I don't think there is a solution here, easier than hardware reset. As for "server" machines (not simple terminals), physical locking is critical. > Well, sometimes you have problems that powercycling would "hide" so you can't > track them down if you powercycle the whole computer every time. In security-sensitive instalation, you simply don't expose the computers to non-admins. > For using foreign languages and keyboard mappings. Hope they don't change the keys in the process. Anyway, most people don't need that nor they need suid-wrapper. BTW: there are similar problems with serial access: users can play with termio(s) settings (especially CLOCAL flag) and fake login/password requests. Unless the getty programs are fixed, you don't want to connect dial-in modems to a machine with user accounts. Not a kernel thing, though - Linux has termios locking for 10+ yrs. -- Krzysztof Halasa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo: > Rudolf Polzer <[EMAIL PROTECTED]> writes: > > That does not help against the loadkeys issue if the attacking user is still > > logged in on another virtual console. Even when tty1 is active, a user > > owning > > tty6 can use loadkeys. > > Sure. The problem is that mappings are shared between VCs but anyway > it's solved by disabling user changes. > I don't think there is a solution here, easier than hardware reset. > As for "server" machines (not simple terminals), physical locking is > critical. Of course it is. However, pool computers like in this case are neither servers nor terminals. If they were terminals, we would need about 30 servers to handle the load of 100 active students. So they are workstation installations that do most of the work locally. > > Well, sometimes you have problems that powercycling would "hide" so you > > can't > > track them down if you powercycle the whole computer every time. > > In security-sensitive instalation, you simply don't expose the computers > to non-admins. Well, in this case the issue is on pool computers for students. Students SHOULD be able to access the computers, but not as root. Currently our workaround is "only su(do) from a ssh session on a 'trusted' computer". > > For using foreign languages and keyboard mappings. > > Hope they don't change the keys in the process. They HAVE to do that, this is the very point of switching the keyboard layout from German to US, to UK, to French or to whatever. > Anyway, most people don't need that nor they need suid-wrapper. Many people here need that, but it's ok for them if it works only in X11 (most of these users don't even know that text consoles exist). However, Xorg and XFree86 have about the same problem: you can remap Ctrl-Alt-Backspace. So it would be good if the SAK also worked there which would require it to set a "sane" video mode.
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Rudolf Polzer <[EMAIL PROTECTED]> writes: > However, pool computers like in this case are neither servers nor terminals. > If they were terminals, we would need about 30 servers to handle the load of > 100 active students. So they are workstation installations that do most of > the > work locally. Ok. So they are exposed to known attacks with quite high probability. This might be acceptable (as they are student machines) but not secure. >> Hope they don't change the keys in the process. > > They HAVE to do that, Well, I meant physical keys to match them to loaded keymaps :-) > Many people here need that, but it's ok for them if it works only in X11 > (most > of these users don't even know that text consoles exist). I see. X11 is another story, though. > However, Xorg and XFree86 have about the same problem: you can remap > Ctrl-Alt-Backspace. So it would be good if the SAK also worked there which > would require it to set a "sane" video mode. I assume that one can notice that Ctrl-Alt-Backspace doesn't work, and stop there. I think SAK/X11 video mode issue is possible to fix, though. -- Krzysztof Halasa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo: > Rudolf Polzer <[EMAIL PROTECTED]> writes: > > However, pool computers like in this case are neither servers nor > > terminals. If they were terminals, we would need about 30 servers to > > handle the load of 100 active students. So they are workstation > > installations that do most of the work locally. > > Ok. So they are exposed to known attacks with quite high probability. Which others? Are there other places that assume only trusted users can access the console? > >> Hope they don't change the keys in the process. > > > > They HAVE to do that, > > Well, I meant physical keys to match them to loaded keymaps :-) ;) > > However, Xorg and XFree86 have about the same problem: you can remap > > Ctrl-Alt-Backspace. So it would be good if the SAK also worked there which > > would require it to set a "sane" video mode. > > I assume that one can notice that Ctrl-Alt-Backspace doesn't work, > and stop there. Not if a malicious X program does "chvt 1; chvt 7" when Ctrl-Alt-Backspace is pressed. > I think SAK/X11 video mode issue is possible to fix, though. It would require a video driver that can actually reset the video mode. Framebuffer drivers usually can do that. For the standard VGA text mode, at least savetextmode/restoretextmode from svgalib don't work on the graphics cards I have.
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Rudolf Polzer <[EMAIL PROTECTED]> writes: >> Ok. So they are exposed to known attacks with quite high probability. > > Which others? Are there other places that assume only trusted users can > access > the console? Probably: BIOS booting, messing with computer cases (are the computers in locked room and only kbds/monitors/mouses are accessible?), sniffing keyboard cables (all other passwords if not root's), physical damage to the computer hardware (some kind of DoS). Still, may be adequate for student room. >> I assume that one can notice that Ctrl-Alt-Backspace doesn't work, >> and stop there. > > Not if a malicious X program does "chvt 1; chvt 7" when Ctrl-Alt-Backspace is > pressed. With correct timing, possibly. Depends on how the graphics driver starts and switches from text mode. There might be noticeable differences. > It would require a video driver that can actually reset the video mode. > Framebuffer drivers usually can do that. For the standard VGA text mode, at > least savetextmode/restoretextmode from svgalib don't work on the graphics > cards I have. I think Xserver could terminate gracefully. But it would require changes to kernel SAK handling I think - not sure if it's worth it, given other threats. Another idea: if the machines are ACPI-enabled and have "soft-power" buttons, one can make use of acpid. -- Krzysztof Halasa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo: > Rudolf Polzer <[EMAIL PROTECTED]> writes: > > >> Ok. So they are exposed to known attacks with quite high probability. > > > > Which others? Are there other places that assume only trusted users can > > access > > the console? > > Probably: BIOS booting, Locked. And these boards don't even have the wide-spread "boot from USB even if system boot up sequence states otherwise" bug. Probably just because they do not support booting from USB, though. > messing with computer cases (are the computers in locked room and only > kbds/monitors/mouses are accessible?), Not locked, but that would be an option - others would notice it if you did anything weird, however. > sniffing keyboard cables (all other passwords if not root's), That's the only thing that might actually work - an inductive device wrapped around the keyboard cable. But I've never seen those available ready to buy. > physical damage to the computer hardware (some kind of DoS). Not interesting. Well, once someone stole a mouse. A dirty old PS/2 mouse with a ball. Who would steal such a mouse? > Still, may be adequate for student room. Right, especially since people would not mess with the hardware. If there are 20 students in a room, would you really do something strange? For example, nobody even tries to watch porn in these rooms. > >> I assume that one can notice that Ctrl-Alt-Backspace doesn't work, > >> and stop there. > > > > Not if a malicious X program does "chvt 1; chvt 7" when Ctrl-Alt-Backspace > > is > > pressed. > > With correct timing, possibly. Depends on how the graphics driver starts > and switches from text mode. There might be noticeable differences. There might be a difference, yes - but there's also a difference in timing if the system has background load. So nothing to rely upon. Plus we have CRTs that just get black for some time with some clicking noise - and these CRTs need quite a long time to start showing a picture after changing the video mode. > > It would require a video driver that can actually reset the video mode. > > Framebuffer drivers usually can do that. For the standard VGA text mode, at > > least savetextmode/restoretextmode from svgalib don't work on the graphics > > cards I have. > > I think Xserver could terminate gracefully. But it would require changes > to kernel SAK handling I think - not sure if it's worth it, given other > threats. > > Another idea: if the machines are ACPI-enabled and have "soft-power" > buttons, one can make use of acpid. Yes, good idea, but we already are using it for soft reboot. If people start using the idea of remapping backspace so others can't kill their screen saver (and then keep logged on idle for days - a quite typical "DoS" here), the power button will most probably be remapped from "shutdown -r now" to "/etc/init.d/kdm restart". We usually don't want to kill some professor's pine (ugh, they want us to install it) in that case, but rebooting would do that too.
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Rudolf Polzer <[EMAIL PROTECTED]> writes: > That's the only thing that might actually work - an inductive device wrapped > around the keyboard cable. But I've never seen those available ready to buy. There are simpler designs - it's just a serial line, right? A simple "dongle" can send data from the keyboard to a notebook. With luck two wires would do (using parallel port for sampling data). Anyway I wouldn't count on people's reaction when they see someone doing something unusual. -- Krzysztof Halasa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Scripsis, quam aut quem »Krzysztof Halasa« appellare soleo: > Rudolf Polzer <[EMAIL PROTECTED]> writes: > > That's the only thing that might actually work - an inductive device wrapped > > around the keyboard cable. But I've never seen those available ready to buy. > > There are simpler designs - it's just a serial line, right? A simple > "dongle" can send data from the keyboard to a notebook. With luck two > wires would do (using parallel port for sampling data). We use a PS/2 port, so without a reboot, this would not work. IIRC 2.6 kernels with keyboard support compiled into the kernel cannot be forced to re-detect the keyboard when the line was interrupted (which is a big problem with old KVM switches). Of course, with USB keyboards this approach would work. And if it weren't for the typical nvidia driver problems, we wouldn't allow students to reboot the computers using the power button and let it restart the X server instead.
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
On Tue, 18 Oct 2005, Krzysztof Halasa wrote: OTOH I don't know why ordinary users should be allowed to change key bindings. I like to load a custom keymap to swap ctrl and caps-lock. I'd like to keep that ability, but I'd much prefer if it didn't affect all VTs, and if it didn't persist past the end of my session. regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 64A2FF6A Fortune: Don't worry if you're a kleptomaniac; you can always take something for it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Rudolf Polzer <[EMAIL PROTECTED]> writes: > We use a PS/2 port, so without a reboot, this would not work. IIRC 2.6 > kernels > with keyboard support compiled into the kernel cannot be forced to re-detect > the keyboard when the line was interrupted (which is a big problem with > old KVM > switches). Must have been a different problem, just tried and the keyboard works fine. But of course one can connect the "dongle" before rebooting. Dead keyboard can force reboot as well, can't it? > Of course, with USB keyboards this approach would work. Would be less trivial. -- Krzysztof Halasa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334113: kernel allows loadkeys to be used by any user, allowing for local root compromise
Paul Jakma wrote: On Tue, 18 Oct 2005, Krzysztof Halasa wrote: OTOH I don't know why ordinary users should be allowed to change key bindings. I like to load a custom keymap to swap ctrl and caps-lock. I'd like to keep that ability, but I'd much prefer if it didn't affect all VTs, and if it didn't persist past the end of my session. I believe in security, no matter how inconvenient, but it would be desirable to allow the user to reload the keymap, and the character set as well, only for the session in use. The solution would seem to lie in having an unchanging SAK key, and on exit from a session absolutely reset everything. Clearly this would take some rethinking and a fair amount of work, so the right thing to do is use capabilities to block misuse until/unless convenience can be made secure. Key mapping as a whole sucks, you have the map you get in a vt, which is ignored by X which maps its own, except when an X app remaps it yet again locally. Lots of room for both evil and stupidity. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]