Re: core dump on mingetty and getty
From: Michal Zalewski (lcamtuf@coredump.cx)Date: 12/03/01
- Previous message: KF: "Re: Can anyone verify a core dump on /sbin/mingetty"
- In reply to: KF: "Re: core dump on mingetty and getty"
- Next in thread: KF: "uugetty mgetty also..."
- Next in thread: Pedro Miller Rabinovitch: "Re: Can anyone verify a core dump on /sbin/mingetty"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Mon, 3 Dec 2001 17:20:33 -0500 (EST) From: Michal Zalewski <lcamtuf@coredump.cx> To: KF <dotslash@snosoft.com>
On Mon, 3 Dec 2001, KF wrote:
> Why do we care... because I am joe schmoe_cant_code_a_lick_of_c and I
> make retarded mistakes in my code. (Stupid examples follow).
> [...]
> setuid(0);
> setgid(0);
> runme[0] = argv[1];
> runme[1] = 0;
> execve("/sbin/getty", runme, 0);
> [...]
> For that matter...m4 is a userland non-privileged level program ...
> yet it led to a man exploit. Flames > /dev/null ... comments welcome.
If one codes something like that:
setuid(0); setgid(0);
snprintf(buf,sizeof(buf),"vi /some/dir/%s",argv[1]);
system(buf);
...this obviously can be exploited to edit /etc/passwd, but is this a
problem in vi? Would you like to see posts like that on VULN-DEV? Where to
draw the line between what is a "feature" and a "vulnerability" in
programs that are, after all, not really supposed to apply such checks?
Mingetty, pine, or any other program that is not designed to run in a
hostile environment should not be expected to implement security checks
without a reason - at best, segfaulting after 3984 AAAs might be a
functionality problem, not a security hole.
As soon as unprivileged code is used in a stupid and irresponsible way
('man' is one of best examples how things shouldn't be written), this is a
problem. This is a problem even if there is no buffer overflow in m4 - it
is sufficient for m4 to accept some environment variables or extra
parameters that make it do more than the author of our privileged
application expected - and all this is still a part of designed m4
functionality!
We really should not blame the author of this unprivileged code - no
matter if it is m4 or mingetty, no matter if it segfaults or simply
accepts OUTPUT_FILE environment variable. We should not start pointless
and endless threads about it (I am not talking about certain types of
vulnerabilities in unprivileged code - namely, all cases of faulty
interaction with a hostile environment, such as the net, /tmp directory,
process table, etc). But we certainly should start discussing all cases
where a privileged code uses unprivileged software in potentially
dangerous way. As this is VULN-DEV, we can start doing it before we know
whether it has any negative effects or not.
-- _____________________________________________________ Michal Zalewski [lcamtuf@bos.bindview.com] [security] [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: =-=> Did you know that clones never use mirrors? <=-= http://lcamtuf.coredump.cx/photo/
- Previous message: KF: "Re: Can anyone verify a core dump on /sbin/mingetty"
- In reply to: KF: "Re: core dump on mingetty and getty"
- Next in thread: KF: "uugetty mgetty also..."
- Next in thread: Pedro Miller Rabinovitch: "Re: Can anyone verify a core dump on /sbin/mingetty"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]