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. -- 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, [EMAIL PROTECTED] (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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]