Iljas Blag

kernel heap overflows are easy as pie
(translated tho)

I normally don’t blog about these kind of things, but this is just too hilarious.

So 28 people escaped out of a prison in Dendermonde. Let me say that again TWENTY-EIGHT !

How did they do it ? Apparently it was all planned by 2 guys who broke the lock on their door, then continued to threaten 3 guards with 1 knife and glass from a broken mirror. took their keys and locked them up. Next they freed 26 of their inmates, and proceeded to the outer prison walls, where they -and get this- tied some blankets together to make a rope and used that to climb the wall. This is not a lucky Luke cartoon mind you, this is real life! after which they climbed down on a phonebooth.

un-fucking-believable.

The “rope” they made to escape

The phonebooth after 28 people jumped on it.

My prediction is that for the next prison break in Belgium someone will make a small tunnel under the prison walls.

Just read some of it’s code. Holy crap, too many reads beyond the end of a buffer bugs.

So I ran into fefe’s slides on writing small and fast software, they’re pretty nice, there’s some good advice in there. you can get them at: http://www.fefe.de/dietlibc/diet.pdf

There’s one part in there that I don’t really agree with. He encourages people to use alloca (or that’s what it seems like anyway). imo this is a mistake.
alloca really stinks ! basicly for 2 reasons:

most implementations don’t detect stack overflow, and hence your allocation can just crash and burn when you call alloca (the alloca on windows does btw, and it raises an exception).

More dangerously, if you have an unbounded alloca (which you really should never have !) you’re pretty much owned. Since (on most implementations) you can cause the stack pointer to int overflow. see http://felinemenace.org/papers/p63-0×0e_Shifting_the_Stack_Pointer.txt for more details.
or go see my ruxcon talk

for those still not convinced the linux alloca manpage states:
“The alloca() function returns a pointer to the beginning of the allocated space. If the allocation causes stack overflow, program behaviour is undefined. “,
“The inlined code often consists of a single instruction adjusting the stack pointer, and does not check for stack overflow. Thus, there is no NULL error return. ” and
“The alloca() function is machine and compiler dependent. On many systems its implementation is buggy. Its use is discouraged. ”

Don’t ever use it !

http://lists.grok.org.uk/pipermail/full-disclosure/2006-August/048891.html

holy crap, I can’t believe they fucked that up !

http://des.blog.linpro.no/2006/01/17/but-it-works/
the last part is evil !

Wow, so it seems I’ve been mainting this blog on and off for about a year now. Amazing, I never imagined I would.

a lot of people seem to inproperly use readlink().
basicly readlink() reads where a link points to.
the function with its arguments is:
readlink(link, buf, len);
readlink() never 0-terminates by itself, so you have to do it by yourself. People often seem to forget this, leading to infoleaks or sometimes memory corruption.
another thing people like to do is:
len = readlink(link, buf, sizeof(buf));
buf[len] = ”;
there are 2 problems here, readlink() can return -1 if it fails and hence causing an off-by-one underflow, so always check the readlink return value. The other problem that can occur is that readlink returns how many byted got written to the buffer, in this case it can write up to sizeof(buf) bytes. if it does you basicly end up doing:
buf[sizeof(buf)] = ”; which is an off-by-one overflow.

“Historically, the default path for the execlp() and execvp() functions was “:/bin:/usr/bin”. This was changed to place the current directory last to enhance system security”

from the freebsd execvp() manpage. And ofcourse noone can ever make execve() arbitrarily fail ….

So I was going through the wwdc talk list, and stumbled across “Designing for Security”. It starts off with:
“Mac OS X is the first mass-market operating system built from the ground up with security in mind.”
HAHA, I don’t think so.