Re: core dump on mingetty and getty

[Michal Zalewski <lcamtuf () coredump cx>]

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/