Keymapping vunerability (drivers/char/vt.c) (fwd)

[James S. <jsi...@ac...>]

---------- Forwarded message ----------
Date: Thu, 15 Jun 2000 23:10:25 +1000
From: Stephen Thorne <sjt...@oz...>
To: lin...@vg...
Cc: Herbert Xu <he...@go...>, 65...@bu...
Subject: Keymapping vunerability (drivers/char/vt.c)

G'day

The basis to this security vunerability is extremely simple.
As it stands, any user who owns a tty can remap the keyboard
for the entire system. I consider this to be a security risk.

Consider the following situation.

Nefarius person gains access to a tty (can't be telnet, must
be a bona fide tty) and type the following

theseus:~$ loadkeys
string F55 = "\nfoobar\n"
keycode 69 = F55
theseus:~$

Then, a legitimate user logs into the system, and when that
person goes to use the numlock (in this example, to type
a student number)

theseus:~$ finger s
finger: s: no such user.
theseus:~$
theseus:~$ foobar

not only can something as blatantly obvious as this be
achieved, but other, more carnivorous commands can be used
for example, replace foobar with
\necho keycode 101 = F1 F1 F1 F1 F1 F1 F1 F1 F1 |loadkeys\n Nrm -rf /\n

i.e. disable control break, then procede to erase the
entire system.

An.... unusal reason way for someone to use numlock to say the
least.

Attached is a diff that will cause the kernel to check for
superuser permissions before allowing someone to change
the scancode->keycode mappings, key strings or the
keymappings.

Steve.