Iljas Blag

You’ve got slow days and not so slow days. You can say today (hm, well yesterday) was one of those not so slow days. One rather interesting vulnerability got disclosed. A remote signal race in sendmail, which was (not surprsingly) discovered by Mark Dowd of the ISS X-Force. Undoubtably one of the smartest code auditors to walk the face of this earth. The Xforce advisory states that there’s a signal race condition in the timeout handlers, which under certain conditions might lead to stack or in some cases heap corruption. I haven’t looked at the particular vulnerability, but assuming its realistic to trigger the race and you get some flexibility to damage the stack this one could be relialibly exploited. The advisory also states that it’s not a single-shot, so if things don’t work out quite well you can just try again. This one is certainly interesting! Which brings me to another question, why is it that so many people are still using sendmail in 2006? Sendmail is one of those monsters that dates back from the 80’s. It should have died by now! It’s not like there aren’t any alternatives. One of them was even designed to look and feel like sendmail.

Another IE 0day got disclosed today (by the guys from Computer Terrorism (UK) :: Incident Response Centre ). It appears that this one ends up having a function pointer to point to (and I quote) ” very remote, non-existent memory location, causing IE to crash (DoS)”. The ones who discovered it go on to say that this one is very much exploitable and that they are sitting on a reliable exploit for it. I don’t doubt that for a second. My guess would be that they’re using skylined’s heap spraying method or something simular. It’s interesting that so many IE bugs still get found to this day. Because IMO pretty much all other browsers (with the exception of firefox) are WAY WORSE off then IE when it comes to being able to parse input correctly. I say this because I’ve spend a fair amount of time writing and testing browser fuzzers, and IE and Firefox are by far the one’s that can take the most crap before dieing. I’d like to take this opportunity to bark at safari, In pretty much all of my tests it came out the worst. Getting safari to segfault is trivial.

This brings me to hdm’s Hamachi (http://metasploit.com/users/hdm/tools/hamachi/hamachi.html) Which is a small dhtml fuzzer. It would appear that opera, safari, omniweb and konquerer seem to break on it. Firefox (both 1.0.7 and 1.5.x on linux) didn’t die on it. I don’t know about IE. I think people have barely scratched the surface when it comes to browser fuzzing (or adleast what has been publicly reported about it).

… I don’t think so !!!! Obviously I’m talking about macosX.

It has tons of stability issues. The thing that currently annoys me most is that extensive usage of the official bittorent client causes almost constant kernel panics. THIS IS HORRIBLE, MODERN UNICES SHOULDN’T PANIC ON NORMAL USAGE !! I haven’t looked yet at what caused it, but If I had to guess I’d say its somewhere in the mach code.

So another VERY annoy issue. When I start fuzzing safari with something that doesn’t instantly break it It tends to have memory leaks, and lots of it. Now I can live with that, after all, which browser doesnt have tons of memory leaks? What really gets me is that that memory SHOULD get freed once you exit safari, AND IT DOESN’T ! my box ends up being dogslow and I need a reboot, ONCE AGAIN, IN MODERN UNICES THIS ISN’T SUPPOSED TO HAPPEN, WHEN A PROCESS CALLS exit() THE KERNEL SHOULD FREE ALL IT’S MEMORY !!!!!!

During the summerschool Max also blogged about this:
http://blogs.23.nu/disLEXia/stories/9929/

it’s no big secret that scanf is/was a function that causes a lot of bufferoverflows. Ofcourse, no one makes trivial overflows with scanf anymore (Hm, well some people still do, http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/games/sail/pl_main.c?rev=1.16&content-type=text/plain, me and max reported that one > 1 year ago btw)

but there are 2 more subtle things you can do wrong with the scanf() familiy of functions. First, some people insist on fixing a bufferoverflow caused by *scanf by changing the format string from %s to %s (%128s for example). The problem here is often that people still cause an off-by-one. See that length will be the amount of bytes copied and AFTER that a 0byte will ALWAYS get appended.
for example:
void f() {
char b[4];
scanf(”%4s”, b);
return;
}
would be an exploitable off-by-one caused by abuse of *scanf().

the other thing that might go wrong when scanf is used improperly, is that of using uninitialised variables.
When the string being scanned isnt “compatible” with the format string nothing will be copied. This might lead to unintialised integers and strings. Which might later lead to information leaks and buffer overflows. You can check the return value of the *scanf functions to see how many variables got written to.

update:
just ran into another scanf bug which is kinda interesting. basicly the code I was looking at was trying to parse a UUID and did the following:
if (sscanf( (unsigned char *)uuid_string,
“%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x”,
(unsigned int *)&uuid->time_low,
(unsigned int *)&uuid->time_mid,
(unsigned int *)&uuid->time_hi,
(unsigned int *)&uuid->clock_seq[0],
(unsigned int *)&uuid->clock_seq[1],
(unsigned int *)&uuid->node[0],
(unsigned int *)&uuid->node[1],
(unsigned int *)&uuid->node[2],
(unsigned int *)&uuid->node[3],
(unsigned int *)&uuid->node[4],
(unsigned int *)&uuid->node[5]) != 11) { …. }

the UUID struct looks like:
struct rpc_uuid {
uint32_t time_low;
uint16_t time_mid;
uint16_t time_hi;
uint8_t clock_seq[2];
uint8_t node[6];
};

this will cause memory corruption. the %02x format specifier will write 0×000000XX to space that can only hold a single byte. I’m sure there are simular bugs like this out there.

http://www.hcw.be/hcwcs/p.asp?p=G3096
http://www.amazon.com/gp/product/032124544X/sr=8-1/qid=1142610631/ref=sr_1_1/103-0059377-2258253?%5Fencoding=UTF8

Mind you that 1 euro is worth 1.20 dollars right now, so that’s bout 60 dollars for the book when I buy it in a local bookstore here, compared to 22 dollars on amazon in the us. Even with the shipping (which is like 9 dollar) it’s still half the price !

The only books I buy in europe are really cheap 2nd hand books. You get ripped off big time for anything else.
edit: Oh, and ofcourse dutch books :) you don’t generally find those on amazon :)

http://www.emergentchaos.com/archives/2006/03/private_thoughts_on_blue.html
http://blogs.msdn.com/michael_howard/archive/2006/03/10/548894.aspx
http://blogs.23.nu/disLEXia/stories/9716/

Those who know me know I love fuzzing. It makes bug hunting very easy and is oh-so-very-effective. The term fuzzing is used to input random data and then wait till something breaks comes from research done at the university of Wisconsin back in 1990. The guys who did that research also wrote a landmark paper about it ( ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf )
if you haven’t read it already, you shoud read it right now, it’s worth it.
The original fuzz testing was done to see how reliable unix untilities are. What’s fascinating is that a lot of the results described in that paper tend to be security related (they also talk about security when discussing buffer overflows).

I love that paper, because it identifies some really interesting bug classes. Now some might think that it’s no big deal since we’re well aware of those, but really, who was aware of them back in 1990 ? I sure wasn’t (then again I was in elementry school back then).
A quick rundown of those classes:
- buffer overflows
- no return values checked (I love those bugs, so subtle)
- formatstring bugs ! (tho they didn’t call it that in the paper, more on this a bit later)
- wrong error handling
- signedness issues
- signal race condition

the only ones really missing there are integer overflows and file races, and you’d have pretty much everything that goes wrong with c code.

About the format string bugs there. They obviously didn’t research that all the way down to the %n you can use to write to arbitrary memory locations, but who cares, they weren’t looking for security bug classes anyways.
Formatstring bugs really aren’t all that new. If you read “The C programming language” 2nd edition you’ll also see a warning there for formatstring bugs (again, back in 1988 the term “formatstring bug” wasn’t coined yet, but they did give a code example of it and litteraly said “it’s not safe”). Honestly I think back in the early 90’s some select group of people were aware of the grueling security effects of formatstring bugs. If I’d have to guess I’d say that the guys from 8lgm knew about it.

Hm, bit of a rant there about formatstring bugs, but my point was that that paper is so amazingly cool. READ IT !

strlcpy() is a string copy replacement for strcpy() and strncpy() designed by the OpenBSD guys. If you haven’t
heard about it I suggest you read:
http://www.usenix.org/events/usenix99/full_papers/millert/millert.pdf

The thing with strlcpy() is that it’s not a silver bullet either.
And moreover you shouldn’t always mindlessly replace
strncpy() with strlcpy().

In order to explain, lets look at some of the differences between strncpy() and strlcpy(). strncpy() takes as last argument the number of characters to copy, if it encounters a 0byte before it has copied that much characters it pads with 0bytes, If however it doesn’t come across a 0byte before it reaches this amount it won’t 0terminate the buffer.

strlcpy() works a bit different. First off it does not pad with 0bytes. Second if the amount of data te copy is not 0 it always 0terminates.

so strlcpy() was made to prevent some fuckups made with strncpy() (for examples, see: http://www.phrack.org/phrack/56/p56-0×0e).

strlcpy() however doesn’t pad the buffer with the total
size.This might be problematic when the entire buffer is outputted to the user. Leading to an information leak.
A nice example of this is a recently fixed bug in the OpenBSD kernel:
net/if.c:
if_clone_list(struct if_clonereq *ifcr)
{
char outbuf[IFNAMSIZ], *dst;
…
strlcpy(outbuf, ifc->ifc_name, IFNAMSIZ);
error = copyout(outbuf, dst, IFNAMSIZ);
if (error)
break;
}

return (error);
}
Pretty obvious that some uninitialised data from the stack
gets leaked here. (check http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/if.c.diff?r1=1.141&r2=1.142&f=h for the fix).

other issues with strlcpy() that it shares with strncpy() (and most other copy functions that take a length value to copy) is messing up the length value passed to it.
and the fact that strlcpy() doesn’t 0terminate when the
length passed to it is 0 (I realise this is very rare and will
only occur in weird corner cases, but hey, that’s where most bugs happen :)

I’m not arguing here that strncpy() is better then strlcpy()
or visa versa. I’m just saying that you should think about which function you should use before mindlessly using strlcpy().

http://ilja.netric.org/ is down. It has been since late last week. We’re moving to another datacenter. I had hoped it’d be up already, but apparently its not. Anyway, it will be up again at some point (hopefully still this week.)

SVG stands for scalable vector graphics. It’s an image format designed by W3C. Basicly It’s an XML file describing a graphics file.

I’ve been toying with this a little bit. It seems that Firefix 1.5 and opera 8 support it, support for safari is in the works, dunnow bout IE but I’d guess it will/does support it aswell.

Besides the regular parsing hell with these kinds of things (you know, buffer overflows, double free’s, NULL pointers, heap corruption, ….) There are 2 other things which I think will contribute to its security nightmare.

First, It’s possible to embed a hyperlink and javascript INSIDE the graphics file. it has cross site scripting written all over it. If SVG gets widely accepted you might be able to upload an .svg as an avatar on forums, upload .SVG files to online shops, or send it to someone who has webmail, incidentally, also the places where XSS really hurts.

Secondly, as with pretty much all XML crap, there are major information leaks. All the tools that generate SVG files embed stuff like paths and usernames inside SVG files, which might tell you the path of where the svg file is stored on the webserver, on what kinda box it was created (windows, unix), usernames, ….

“Among expert programmers the Apple API is regarded as rock solid and 94.86% total secure. It’s closest competitor is OpenBSD which is around 89.52% internet secure according to popular calculations.”

How I hate mac fanboys ….