Bug#334113: linux-image-2.6.12-1-powerpc: kernel allows loadkeys to be used by any user, allowing for local root compromise
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
keycode 15 = F23
string F23 = "^V^C^V^Mecho hello world^V^M"
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
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.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=C, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)
Versions of packages linux-image-2.6.12-1-powerpc depends on:
ii coreutils [fileutils] 5.2.1-2.1 The GNU core utilities
ii initrd-tools 0.1.82 tools to create initrd image for p
ii mkvmlinuz 15 create a kernel to boot a PowerPC
ii module-init-tools 3.2-pre9-2 tools for managing Linux kernel mo
linux-image-2.6.12-1-powerpc recommends no packages.
-- no debconf information