Secure testing team - Mar 2006 - kernel allows loadkeys to be used by any user, allowing for local root compromise

Rudolf Polzer <debian-ne@durchnull.de> 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

Scripsis, quam aut quem ?Krzysztof Halasa? appellare
soleo:
> Rudolf Polzer <debian-ne@durchnull.de> 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.

Scripsis, quam aut quem ?Krzysztof Halasa? appellare
soleo:
> Rudolf Polzer <debian-ne@durchnull.de> 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.

Scripsis, quam aut quem ?Krzysztof Halasa? appellare
soleo:
> Horms <horms@verge.net.au> 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.

On Mon, Oct 17, 2005 at 11:52:11PM -0700, Andrew Morton
wrote:
> Horms <horms@verge.net.au> wrote:
> >
> > 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.
> 
> I briefly discussed this with Alan and he agreed that that''s a
reasonable
> approach.
Thanks, thats pretty much what I had in mind. Though I would expect
some minor breakage, at least for people who expect nonsetuid loadkeys
to work. But then again, that is the whole point.
> I''ll stick the below in -mm, see what breaks.
> 
> --- devel/drivers/char/vt_ioctl.c~setkeys-needs-root	2005-10-17
23:50:37.000000000 -0700
> +++ devel-akpm/drivers/char/vt_ioctl.c	2005-10-17 23:51:43.000000000 -0700
> @@ -192,6 +192,9 @@ do_kdgkb_ioctl(int cmd, struct kbsentry 
>  	int i, j, k;
>  	int ret;
>  
> +	if (!capable(CAP_SYS_TTY_CONFIG))
> +		return -EPERM;
> +
>  	kbs = kmalloc(sizeof(*kbs), GFP_KERNEL);
>  	if (!kbs) {
>  		ret = -ENOMEM;
> _
-- 
Horms

Horms <horms@verge.net.au> wrote:
>
> 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.
I briefly discussed this with Alan and he agreed that that''s a
reasonable
approach.

I''ll stick the below in -mm, see what breaks.

--- devel/drivers/char/vt_ioctl.c~setkeys-needs-root	2005-10-17
23:50:37.000000000 -0700
+++ devel-akpm/drivers/char/vt_ioctl.c	2005-10-17 23:51:43.000000000 -0700
@@ -192,6 +192,9 @@ do_kdgkb_ioctl(int cmd, struct kbsentry 
 	int i, j, k;
 	int ret;
 
+	if (!capable(CAP_SYS_TTY_CONFIG))
+		return -EPERM;
+
 	kbs = kmalloc(sizeof(*kbs), GFP_KERNEL);
 	if (!kbs) {
 		ret = -ENOMEM;
_

Rudolf Polzer <debian-ne@durchnull.de> 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

Scripsis, quam aut quem ?Krzysztof Halasa? appellare
soleo:
> Rudolf Polzer <debian-ne@durchnull.de> 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.

Rudolf Polzer <debian-ne@durchnull.de> 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

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	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Don''t worry if you''re a kleptomaniac; you can always take
something for it.

Krzysztof Halasa wrote:
> Why doesn''t the intruder just simulate login process (printing
"login: "
> and "Password:")? That''s known and used for ages.
Well, you can configure a single vty to only allow logins from admins.
Then you avoid the fake login problem, but not the loadkeys problem
(since that affects all vtys)

Horms <horms@verge.net.au> 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

Rudolf Polzer <debian-ne@durchnull.de> 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

Horms wrote:
> > 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.
This has been assigned CAN-2005-3257.

Cheers,
        Moritz

Rudolf Polzer <debian-ne@durchnull.de> 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

Scripsis, quam aut quem ?Krzysztof Halasa? appellare
soleo:
> Rudolf Polzer <debian-ne@durchnull.de> 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.

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

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