> none of these applications is s[ug]id, so these overflows can not be
> exploited to gain privilige.
Depends how they get used. When some people say "privilige", they almost
always mean root. I do not -- I mean any other credentials which I should
not be able to gain.
The two examples I will give are (1) Would a buffer overflow in tar be
an issue if a remotely fetch tar file could turn into a trojan horse,
and (2) if I was on the same machine as you and I was able to subvert
your behaviour and get your UID because you were running some program
at the time..
Either of these cases is an issue.
In the same way, a lot of /tmp race attacks can be used to just trash
people's .login files. That's something which careful code would not
permit -- the credential based system should not be permitting that.
> about the symlink attack on elvis-2.0:
>
> /* unix/osprg.c */
> char id_osprg[] = "$Id: osprg.c,v 2.9 1996/05/23 00:03:51 steve Exp $";
> #define TMPDIR (o_directory ? tochar8(o_directory) : "/tmp")
> static char tempfname[100]; /* name of temp file */
>
> /* create a temporary file for feeding the program's stdin*/
> sprintf(tempfname, "%s/elvis%d.tmp", TMPDIR, (int)getpid());
> writefd = open(tempfname, O_WRONLY|O_CREAT|O_EXCL, 0600);
> if (writefd < 0)
> {
> msg(MSG_ERROR, "can't make temporary file");
> free(command);
> return False;
> }
>
> it's not vulnerable
No -- this is vulnerable. Two issues:
If I fill /tmp with 30,000 files called /tmp/elvis#.tmp, then I have a
localhost denial of service attack against all users who are trying to
legitimately use the system. If I know what your pid is, I only need
to create one file. You cannot get through this function.
The second issue is an obvious potential user-controlled buffer overflow.
It bears repeating: You never know when something gets run with
priveledge. All code eventually can get run that way. You'd be
amazed at what people call in scripts.
> > There are many more but im too tired to document them, if you have any
> > questions, I can be reached at hdmooreat_private
>
> if some of them can really be used to gain more priviliges on the machine or
> result in a denial-of-service, email them to securityat_private please
Hmm. He just did, and you missed the point.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:14:56 PDT