/*
* HOLY FUCK. so pretty much everything in windows is a GUID,
* buy they don’t have any standard API’s to deal with GUID’s.
* for converting GUID’s to strings I had to use some api from
* ObjBase (all ugly com crap). it has no api to covert strings
* to GUID’s however.
*
* so I look on msdn, and after a long search I find http://msdn.microsoft.com/en-us/library/bb776431(VS.85).aspx
* which is GUIDFromString(), this is hidden in shell32.dll.
* so I try to use it, but the code simply won’t link. I go back to
* that msdn page and see the following at the end of the page: ”
* remarks:
*    This function is not declared in a header or exported by name from a .dll file.
*    It must be loaded from Shell32.dll as ordinal 703 for GUIDFromStringA and ordinal 704 for GUIDFromStringW.
*
*    It can also be accessed from Shlwapi.dll as ordinal 269 for GUIDFromStringA and ordinal 270 for GUIDFromStringW.”
*
* ARE YOU KIDDING ME ??? so I spend an hour or so, trying to
* find api’s to import functions by ordinal, rather than by name
* it turns out there is no GetProcAddress() equivalent for
* ordinals. SON OF A BITCH !!!
*
* so I’m just going to write my own GUIDFromString() api’s
*/

man, this really pissed me off.  not that converting back and forth from a string to a GUID is hard, it’s just that they should have a decent set of api’s for this, and they simply don’t. (atleast not for C code).

edit:

after rereading the GetProcAddress() manpage, it turns out you can specify an ordinal value, if you pass it’s value along as the namepointer effectively encoding the value in a pointer *PUKE*.

and then for all your ioctl’s you’d just check if current->pid is in the trusted list.

This is a horrible kludge !!
All of this works fine, until the procces that opened the device unexpectedly dies.
now there is a dangling pid in the trusted list. all an attacker would have to do is spawn off new processes until you end up with the pid that’s in the trusted list.
and _BAM_ the attacker gets to issues ioctl’s on a device he really shouldn’t get to issues ioctl’s on.

don’t think apps do this ? let’s look at BestCrypt (http://www.jetico.com/).
here’s it’s open callback:
static int bc_open(struct inode *inode, struct file *file)
{
…
if (capable(CAP_SYS_ADMIN)) {
bc_add_pid(current->pid);
}
return 0;
}

it’s ioctl handler looks like:
static int bc_ioctl(struct inode *inode, struct file *file, u_int cmd, u_long arg)
{
…
switch (cmd) {

BC_HANDLER(”get_info”, BC_GET_INFO, bc_get_info(bc, (struct bc_info*) arg));
BC_HANDLER(”set_fd “, BC_SET_FD, bc_set_fd (bc, bdev, (struct bc_file64 *) arg));
BC_HANDLER(”clr_fd “, BC_CLR_FD, bc_clr_fd (bc, bdev, inode));
BC_HANDLER(”lock_dev”, BC_LOCK_DEV, bc_lock_dev(bc, inode->i_rdev, 1));
BC_HANDLER(”ulck_dev”, BC_UNLOCK_DEV, bc_lock_dev(bc, inode->i_rdev, 0));
BC_HANDLER(”frc_ulck”, BC_FORCE_UNLOCK, bc_force_unlock(bc, bdev, inode->i_rdev));
BC_HANDLER(”get_priv”, BC_GET_PRIV, bc_get_priv(arg));
BC_HANDLER(”hdio_geo”, HDIO_GETGEO, hdio_getgeo(bc, (struct hd_geometry *) arg));
BC_HANDLER(”vrfy_alg”, BC_VERIFY_ALG, bc_vrfy_alg((struct bc_alg*) arg));
BC_HANDLER(”make_key”, BC_MAKE_KEY, bc_make_key((struct bc_key*) arg));
BC_HANDLER(”free_key”, BC_FREE_KEY, bc_free_key((struct bc_key*) arg));
BC_HANDLER(”encr_blk”, BC_ENCRYPT_BLOCK, bc_process ((struct bc_block*) arg, BC_ENCRYPT_BLOCK));
BC_HANDLER(”decr_blk”, BC_DECRYPT_BLOCK, bc_process ((struct bc_block*) arg, BC_DECRYPT_BLOCK));
}
…
}

BC_HANDLER is an ugly macro that looks like:
#define BC_HANDLER(dbg, x, y) case (x): /*printk(dbg “\n”); */\
error = (y); \
break;
all of the functions used there looks like:
static int some_function(struct bc_device *bc, struct block_device *bdev, struct bc_file64 *arg) {
… variable declaration …
if (bc_find_pid_safe(current->pid) pid) >= 0) {
current->cap_effective |= (1<<CAP_SYS_ADMIN)|(1<<CAP_CHOWN)|(1<<CAP_DAC_OVERRIDE)|(1<euid = 0;
} else {
return -EPERM;
}

if (arg)
bc_del_pid(current->pid);
return 0;
}

yea, isn’t that great ?
Oh, and here’s the kicker, BestCrypt comes with an suid root application that’ll open the device for you ! (which means you can just kill it once it’s opened the device).
These kind of fuckup’s don’t limit themself to linux. I’ve seen similar screwups in windows drivers.

main(argc, argv)
int argc;
char *argv[];
{
…
signal(SIGHUP, finish);
signal(SIGINT, finish);
signal(SIGQUIT, finish);
signal(SIGTERM, finish);
signal(SIGSEGV, finish);
#ifdef SIGBUS
signal(SIGBUS, finish);
#endif
…
}
finish() looks like:
static void finish(sig)
int sig;
{
/* Only call this routine after tty_getmode() has been called */
/* The tty_reset() call flushes the tty’s input buffers. */
if ( tty_reset(0) pw_name, upper_tty);
if ( pw && bottomok && lower_tty[0] )
(void) delutmp(pw->pw_name, lower_tty);
(void) replace_me();

if ( sig )
printf(”Exiting due to signal: %d\n”, sig);
exit(sig);
}

lots of signal unsafe stuff happening there end_vt100() for example does:
void end_vt100()
{
int i;

if ( ! setup_vt100 )
return;

/* Clear any old setup */
lastwin=(-1);
for ( i=0; i<upper.rows; ++i )
(void) free(upper.videomem[i]);
(void) free(upper.videomem);
(void) free(upper.tabstops);
for ( i=0; i<lower.rows; ++i )
(void) free(lower.videomem[i]);
(void) free(lower.videomem);
(void) free(lower.tabstops);
setup_vt100=0;
…
}

isn’t that hilarious ?

xchat_hook_server(ph, “PRIVMSG”, XCHAT_PRI_NORM, decrypt_incoming, 0);
xchat_hook_server(ph, “NOTICE”, XCHAT_PRI_NORM, notice_received, 0);
xchat_hook_server(ph, “TOPIC”, XCHAT_PRI_NORM, decrypt_incoming, 0);
xchat_hook_server(ph, “NICK”, XCHAT_PRI_NORM, nick_changed, 0);
xchat_hook_server(ph, “332″, XCHAT_PRI_NORM, decrypt_topic_332, 0);

so let’s look at all of those.

int decrypt_incoming(char *word[], char *word_eol[], void *userdata)
{
unsigned char *msg_ptr, contactName[100]=”", from_nick[50], msg_event[100]=”",

psyNetwork[12];
…
if(word[1][0] == ‘:’) ExtractRnick(from_nick, word[1]);
…
}

here’s what ExtractRnick() does:

int ExtractRnick(char *Rnick, char *incoming_msg)
{
int k=0;

if(*incoming_msg == ‘:’) incoming_msg++;

while(*incoming_msg!=’!’ && *incoming_msg!=0) {
Rnick[k]=*incoming_msg;
incoming_msg++;
k++;
}
Rnick[k]=0;

if (*Rnick < ‘0′) return FALSE;
else return TRUE;
}

you can clearly see the stacksmash here (word[1] comes from the network !). the other 3 functions are just as horrible:

int notice_received(char *word[], char *word_eol[], void *userdata)
{
unsigned int i;
unsigned char hisPubKey[300], contactName[25]=”", from_nick[25]=”";
…
if(ExtractRnick(from_nick, word[1])==0) return XCHAT_EAT_NONE;
…
}

int nick_changed(char *word[], char *word_eol[], void *userdata)
{
unsigned char contactName[100]=”", theKey[500]=”", ini_nicktracker[10];
…
if( *ini_nicktracker==’0′ || *ini_nicktracker==’N’ || *ini_nicktracker==’n’ ||
(ExtractRnick(contactName, word[1])==0) ||
(stricmp(contactName, word[3]+1)==0))
return XCHAT_EAT_NONE;
…
}

int decrypt_topic_332(char *word[], char *word_eol[], void *userdata)
{
unsigned char contactName[100]=”";
…
strcpy(contactName, word[4]);
…
}

yes, that last one is an actual strcpy() stacksmash. The 90’s called, they want their bugs back :-p

I’m sure you’ve already read it by now, but it’s no longer just me blagging here. Which is probably a good thing, I’m rather busy right now and have very little time to blag.

You’ve seen her – that annoying kid – following Ilja around like some lost puppy, babbling inanely about you’re not sure what. If you must blame someone, blame prdelka. She (being me, Bitty) now has full guestblagging rights to this blag ;)

(No, I’m not consistantly making the same tyop. Check the title of this blag. It’s definitely a blag. Blogs are so old meme. Memes are so old meme, too.)

Anyways, we all know I never have anything useful to add to a conversation, so I’ll just get going now before Ilja realizes his terrible mistake and revokes my posting privileges. Mostly, I’m here so his RSS feed of new posts doesn’t look so pathetically lonely…

~Bitty

So, euh, happy new year to those 2 people that read my blog (even tho it’s more then a week late). I guess it’s customary to make predictions for 2007, however, I’m not going to do that. When people do that, they’re either safe bets or total bullshit !, I won’t participate in that.

Since I haven’t blogged in a while this blogpost will be a mix of things I wanted to blog about in the past 3 weeks.

I guess I’ll start of with my “report” on 23c3. Man was that awesome ! It was my 5th c3 congress (in a row). And as usual, it rocked ! getting drunk, sleep deprived, socializing and wachting talks for 4 days. 2 of those talks were even mine.

I did an IT security standup comedy together with fefe. we basicly bashed pretty much everyone (but it was not evenly divided, apple got a lot of the bashing). Ofcourse any kind of it related bashing has to include Joerg Schilling. Fefe had this great schilly joke. How many schilly’s does it take to screw in a light bulb ? None, it’s not his fault the light is off ! Anyways, the feedback we got on it wasn’t all bad, although apparently people couldn’t hear me all that well, fefe, who was standing right next to me could hear me just fine, so there must have been something wrong with the microphone. I guess we didn’t entirely go up in flames as we expected we would.

I also gave a talk that I called “Unusual bugs”, at 11:30 in the morning on the 4th (and last) day. That was painful ! (although apparently some people in the us got up at 5:30 in the morning to watch the stream :( which is way more painful). Regardless of the fact it was that early a fair amount of people still showed up (go figure). I talked about exploiting NULL pointer derefs, some issues with alloca(), recursive stack overflow, problems with regex’s and some other stuff. the slides are online if you want to see them (ilja.netric.org/files/Unusual%20bugs%2023c3.pdf). All in all I’d say that talk went pretty well. I got some awesome feedback on it, and people have told me about some related things I didn’t know yet. I also did an demo with an 0day OpenBSD kernel bug. Apparently OpenBSD exploits are easy crowd pleasers, I wonder why. Somewhere in my talk (during the regex thing) I talked about the ^ sign, and not knowing it’s name I called it the hat sign, untill Fabienne was kind enough to tell me it’s called the caret sign. I was told I should submit that talk to cansec aswell, so I did, let’s wait and see if they’ll accept it.

Anyways, 23c3 was just great ! I met up with Gadi Evron btw (you know, the guy that owns the fuzzing mailing list) He’s quite cool. I also ended up seeing his talk about fuzzing the corporate world. It was pretty cool, it wasn’t really a technical talk tho, he talked more about how we can introduce fuzzing in the corporate world. What made the talk so great is the way Gadi does it. He pretty much forces audience participation upon you. Remember this, if you ever go see his talk, and you don’t want to get handed the mike to answer some questions, go sit in the back! if you like that kind of presenting, then I would highly recommend seeing any future talk by Gadi.

I also saw Joanna’s talk. It was good, as you can expect from her, however, I was a little bit disapointed that it wasn’t more technical (which you usually expect from her). At some point someone disagreed with something she said (I can’t quite remember what) and sort of a discussion took place between him and Joanna, at the end someone in the audience yelled “Objection, speculation” and she moved on. Somewhere near the end of her talk she said something security related about NetBSD and I could barely hold my laughter.

So I also attended fefe’s bignum talk, which was interesting. Not that I have any interest in _EVER_ writing bignum code, but he did some benchmarks aswell, to see if how faster certain things work compared to other. I was shocked to see his “div” benchmarks, I knew division is slow, but I had no idea it was this slow. In the end he remarked that a lot of the actions you need for bignum code are actually by definition slow, coz that’s how people design their crypto stuff, the slower it is by design, the better. (so for those who don’t know, you usually only use bignum code for crypto stuff).

Ofcourse I also saw Kaminsky’s talk! the man is an awesome entertainer! If you’ve never seen any of his talks then you should definatly go see one of them when you have the chance, even if you’re not interested in any of the topics he’ll cover, you’ll still like his talks, trust me.

and so, after 23c3 I spend 8 hours in the car, getting back home, yea that was really fun ….

So one of the things I noticed after my unusual bugs talk, the OpenBSD guys fix bugs _FAST_. I mean really fast ! bugfix and announcement within a few days. Not many vendors can pull that off. While preparing the OpenBSD exploit for my talk, I also noticed that if you mmap with MAP_ANON, your fd has to be set to -1 (on BSD), why in the hell is that ? it gets ignored anyways. that tiny piece of code that checks for -1 in that case is just bloat, would be great if someone just removed that. In linux this is not the case btw, the kernel will just ignore the fd in that case (as it should !).

A few days ago fefe told me about these inotify syscalls in the linux kernel. Basicly you use them so you can get informed automatically about any change to any file. I quickly looked at the code that does it and stumbled on some small security bug. Basicly, what you do is, you call inotify_init() to get an fd to an inotify event queue. then using that fd you can add or remove watch points. There are limits set to how many of those watch points and fd’s you can get (I believe you can change them in /proc as root) and there’s a race condition in the code that checks if you’re over the limit, and increasing the count of how many you already have:
asmlinkage long sys_inotify_init(void)
{
…
user = get_uid(current->user);
if (unlikely(atomic_read(&user->inotify_devs) >=
inotify_max_user_instances)) {
ret = -EMFILE;
goto out_free_uid;
}
… a whole bunch of stuff …
atomic_inc(&user->inotify_devs);
…
}
So it checks it, then does a whole bunch of stuff, and only after that changes the count of how many you have. So you could race this and call inotify_init() a bunch of times and basicly go over the limit you’re supposed to have. Ofcourse I reported this to security@kernel.org, but they don’t seem to care about this at all. I even got a mail back from torvalds himself saying “we simply don’t care whether the limit is exceeded _exactly_, or if somebody can come in and exceed it just a little bit.”, WTF ? yea I know the skies aren’t falling, but this is a bug and simply needs fixing! And I wonder how they define “a little bit”, my guess is, if you spend some time figureing things out, you could probably greatly exceed the limit. the code to add inotify watches suffers from the same race.

Recently I’ve had some success with manual fuzzing, I didn’t really want to blog about this, coz it’s pretty lame, but fuck, manual fuzzing can be pretty effcient. So euh, what you basicly do is look at some binary file in a hex editor, change some values, and see what happens. Things really _SHOULDNT_ break on this, but they do. it’s pretty sad really. Anyways, I usually use the 010 hex editor for this (it also has some templates that support certain files, like wav, avi, zip, …). You should give it a try sometimes, chances are you’ll find some nice 0day with it.

When reading some stuff on wikipedia I also ran into the irony mark, I’m so going to use that! it’s basicly a reversed question mark.

I also released a unix ioctl fuzzer a few days ago, if you’d like to give it a try you can download it here. It works (somewhat) on Open-, Net-, FreeBSD and linux. I also have a somewhat hacked up version for osx, which I’ll release at some point. It’s been quite effective, I found the OpenBSD kernel bug with it for example. somewhat simular, I’ve started working on a sysctl fuzzer, we’ll see how that goes.

A cool blog you should definatly check out is bitty’s blog, she was also kind enough to make my cool 23c3 slides.

another blog you should read, is the art of software security assesment’s blog, from the guys who made THE code auditing bible !

And another blog related announcement, another bug of the month kinda thing. Month of the apple bugs. Some seem to think these kind of things are a mistake, I on the other hand will sit back, relax, eat some popcorn, and ejoy the show. And if it tickles my funnybone, I’ll laugh !

I also ran into this idefense advisory. What’s so funny about this one is that the vedor simply won’t fix the bug: “QUALCOMM will not be addressing this issue with a software patch and instead recommends that administrators block access to the affected port from untrusted sources at the network level.” WTF ??? this is a heap overflow in what looks like a supported product, how can you (as a vendor) refuse to fix it ???

Last, but not least, I was going over some BSD syscalls and saw the revoke() syscall. I’d never heard of this one before, apparently it takes a pathname as input and invalidates _ANY_ fd on the system to that path (assuming you either own the file or are root). Somehow I think there’s gotta be some security bugs related to this. How can there not be ? Suids for example don’t get written with the idea that open fd’s they have all the sudden get invalidated, without any kind of notice. anyways, I still need to dig into this one, expect some funny results from this at some point.

Edit: More proof that I’m an idiot, the advisory I linked to wasn’t idefense it was zdi, yea, think I should take that reading 101 class again.

without giving ANY predefined value for how much is too much. that is just craptastic !

yes, that’s a hardcoded off-by-one! from what I can see it *looks like* the way they’re using it doesn’t allow for exploitation (although I could be wrong and missing something) but I can certainly imagine this being exploitable in the right circumstances.

anyways, you can find the podcast at:
http://zdpub.vo.llnwd.net/o2/eWeek/onsecurity12042006.mp3

Apparenlty stefan esser is no longer part of the php security team.
“Last night I finally retired from the PHP Security Response Team [...] For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available”

So am I to understand we’ll be getting some php 0day from him ? Read about it here

Bruce has a point !

I wonder what their excuse is (and it’s just that, an excuse, THERE IS NO JUST REASON WHY YOU WOULD DO THIS!)

I’m shocked !
I tested this on FreeBSD and NetBSD aswell and they don’t seem to allow it (thank god!, or else I would have ranted some more on NetBSD :).

So, in conclusion, if an unprivileged user can arbitrarily cause a kernel panic, then that is a security bug!

Anyone besides me that thinks this is a dumb idea ?
Btw, in case you didnt know, it’s possible to have shell commands in your .gdbinit file.
Anyways, next time I’m on a shellserver you can bet I’ll have an evil .gdbinit file in /tmp.

if (size < NI_MAXHOST &&
sscanf(params, “http://%[^/]%c”, http_host, &ch) == 2 &&
ch == ‘/’)

params can be up to 4096 bytes and is usercontrolled, MYBUFSIZ is 1024 and NI_MAXHOST is 1025 !!

This is the funniest bounds check fuckup i’ve seen in a while.

I rest my case.

not knowing exactly all the features of strftime I looked in the manpage and read the following:
“The strftime() function returns the number of characters placed in the array s, not including the terminating null byte, provided the string, including the terminating null byte, fits. Otherwise, it returns 0, and the contents of the array is undefined. (Thus at least since libc 4.4.4; very old versions of libc, such as libc 4.4.1, would return max if the array was too small.)”

Obviously that line of code is wrong. as it turns out “modified” gets written back to the user, so this piece of code could leak information, or possible cause a segfault when an unmapped page gets hit (since it’s assumed it’s a 0-terminated string).

is it really that hard to always and consistently check return values ?

also, I just saw that there are “scream awards” on tv, wtf ??? people are giving away awards for everything these days. If only there were slacker awards, I’d win every single one of them.

I recently saw this movie “stormbreaker” it totally sux !! don’t spend money on it, hell don’t even spend bandwidth on it, it’s not worth it.

This brings me to close() which isn’t as busted as fclose() but suffers from the same usage problem. Almost noone ever checks it’s return value, and yet, according to POSIX it can fail. The manpage says the following about it:
“ERRORS

EBADF
fd isn’t a valid open file descriptor.
EINTR
The close() call was interrupted by a signal.
EIO
An I/O error occurred.”

so it could for example get interrupted by a signal, and leave the fd open. The linux manpage goes on and states:
“Not checking the return value of close is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.”

People should seriously start checking the return value of calls like close(). Not doing so could lead to fd leaks, and placed in the right context those can be a huge security issue.

glib also has it’s own “basic types”
you know, gint, guint, gboolean, gconstpointer ( _YES_, gconstpointer, coz that really makes it look nicer , also, see http://www.kuro5hin.org/story/2003/8/12/231143/644 ).

g_strdup_printf(), wtf is wrong with asprintf() ?

I could go on and on, but I won’t.

Some claim that it’s usefull for portable code, I disagree. We all know portable code looks ugly from time to time, there is no need to obfuscate it even further !

Also, I think they missed a useless function:
g_lib_sucks_big_hairy_monkey_balls_like_sweet_chocolate_candy()

A while ago I was reading some glib code (and I’m still sort of sane, I wonder how I pulled that off) and spotted some interesting code:

#define g_new(struct_type, n_structs) \
((struct_type *) g_malloc (((gsize) sizeof (struct_type)) * ((gsize) (n_structs))))
#define g_new0(struct_type, n_structs) \
((struct_type *) g_malloc0 (((gsize) sizeof (struct_type)) * ((gsize) (n_structs))))
#define g_renew(struct_type, mem, n_structs) \
((struct_type *) g_realloc ((mem), ((gsize) sizeof (struct_type)) * ((gsize) (n_structs))))

#define g_try_new(struct_type, n_structs) \
((struct_type *) g_try_malloc (((gsize) sizeof (struct_type)) * ((gsize) (n_structs))))
#define g_try_new0(struct_type, n_structs) \
((struct_type *) g_try_malloc0 (((gsize) sizeof (struct_type)) * ((gsize) (n_structs))))
#define g_try_renew(struct_type, mem, n_structs) \
((struct_type *) g_try_realloc ((mem), ((gsize) sizeof (struct_type)) * ((gsize) (n_structs))))

can you say integer overflow ? I did report this to the glib people, never got a response (the copypast is from the latest version)

ofcourse they also have alloca wrappers:

#define g_alloca(size) alloca (size)
#define g_newa(struct_type, n_structs) ((struct_type*) g_alloca (sizeof (struct_type) * (gsize) (n_structs)))

Because alloca() is so secure !!1!. yea, g_newa() also has an overflow, I’m shocked I tell you, shocked !

I can’t take people who use glib serious, I tried, I failed. If you’re a programmer and feel you must use glib then maybe it’s time to look for a new profession.

static void cmd_loop(server_rec *server, conn_t *c) {
static long cmd_buf_size = -1;
config_rec *id = NULL;
char buf[PR_TUNABLE_BUFFER_SIZE] = {”};
…
if (pr_netio_telnet_gets(buf, sizeof(buf)-1, session.c->instrm,
session.c->outstrm) == NULL) {
…
}
if (cmd_buf_size == -1) {
long *buf_size = get_param_ptr(main_server->conf,
“CommandBufferSize”, FALSE);

if (buf_size == NULL || *buf_size sizeof(buf)) {
pr_log_pri(PR_LOG_WARNING, “Invalid CommandBufferSize size given. ”
“Resetting to 512.”);
cmd_buf_size = 512;
}
}

buf[cmd_buf_size - 1] = ”;
….

if CommandBufferSize is set, and it’s set to something reasonable (go figure) it causes an off-by-two underflow. (for those who don’t get it, cmd_buf_size remains -1 and hence the following happens buf[-1 -1] = ”; and for those who failed elementary school math’s that’s buf[-2] = ”;).
I also reported some other bugs in proftpd, including some readlink() off-by-one’s in the ls code (3 of them to be exact), one of them I think has potential:

static int nlstdir(cmd_rec *cmd, const char *dir) {
char **list, *p, *f,
file[PR_TUNABLE_PATH_MAX + 1] = {”};
…
if ((i = pr_fsio_readlink(p, file, sizeof(file))) > 0) {
file[i] = ”;
f = file;
…
}

I blogged about readlink abuse before, but for those who don’t see it, readlink() returns how many bytes it copied and doesn’t 0-terminate. so if it copied sizeof(file) bytes, that’s what it’ll return. So sizeof(file) gets used as an index to file, and hence causes an off-by-one. Depending on the compiler being used there’s a possibility you smash right into the saved frame pointer.

I also found a bunch of other off-by-a-one’s and off-by-a-few’s (like their “secure” strcpy code I blogged about earlier) but exploitation of them seems unlikely.

The carefull reader might have seen that all the crap I’m talking about are off-by-one’s and off- by-a-few’s and they would be right. ProFTPD is off-by-one paradise !!

len = read(source, buffer, sizeof(buffer));

In case you were wondering this is why gaim is gay.

if (xd->rxlen) {
unsigned char *tmp = g_memdup(xd->rxqueue + 4, xd->rxlen);
g_free(xd->rxqueue);
xd->rxqueue = tmp;
}

because advancing a pointer by 4 is too much of a hassle.

} else if (!strncmp(cur, “PING “, 5)) {
if (notice) { /* reply */
/* TODO: Should this read in the timestamp as a double? */
sscanf(cur, “PING %lu”, &timestamp);
gc = gaim_account_get_connection(irc->account);
if (!gc)
return NULL;
buf = g_strdup_printf(_(”Reply time from %s: %lu seconds”), from, time(NULL) – timestamp);
gaim_notify_info(gc, _(”PONG”), _(”CTCP PING reply”), buf);
g_free(buf);
return NULL;
}

yea ctcp ping infoleaks !!1!

/* Note that this is NOT correct w.r.t. multiple CTCPs in one
* message and low-level quoting … but if you want that crap,
* use a real IRC client. */

That sure shows you’re confident in your own code.

omfg, that code is unbelievable.

for more details on this bug see:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-keysign.c?rev=1.11&content-type=text/x-cvsweb-markup
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/ssh-keysign.c.diff?r1=1.10&r2=1.11&f=h
and
http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/ssh/ssh-keysign/ssh-keysign.c

Obviously I reported this to sun, and got the following email from them:
”
Thanks for getting in touch to report this issue. It doesn’t look like
this would impose any sort of security risk; for example a Denial of
Service (DoS) condition doesn’t appear to be possible. We have logged the
following bug for this issue:

6489555 ssh-keysign:valid_request() may SEGV dereferencing uninitialized pointer

For issues which don’t relate to security vulnerabilities you can log bugs
via:

http://bugs.opensolaris.org/

However for any issue which appears to be a potential security
vulnerability then security-alert@sun.com is the best point of contact.
Thanks again!
”

Ofcourse free(uninit_ptr) are non exploitable bugs, with the solaris heap being hardended and all ().

I’m going to have to go with incompetence here !

I couldn’t have said it better myself. It’s kindof weird, but he’s totally right, there isn’t really a structured process behind finding vulnerabilities.

This scares me a little.

:) I didnt really get permission to quote this, but it was too good not to !

I’ve been unfortunate enough to read some adobe parsing code, and I’ve never seen anything more horrifying in my life!

I think this is a mistake that’ll come back to bite them in the ass !

you can find more info about it here:
http://www.hecker.org/mozilla/adobe-mozilla-and-tamarin
http://www.mozilla.org/projects/tamarin/

A little update: I took a quick peek at some of the code that got uploaded (http://lxr.mozilla.org/mozilla/source/js/tamarin/, for those that are interested), it seems alloca is used A LOT throughout the code. Not really a good idea.

and you know uncyclopedia is always right !1!!

one of the most common mistakes with making your own string copy functions is that of forgetting that someone might call it with a length of 0, and you end up with an off-by-one overflow or underflow.

Let me demonstrate with ProFTPD code:

/* “safe” strncpy, saves room for at end of dest, and refuses to copy
* more than “n” bytes.
*/
char *sstrncpy(char *dest, const char *src, size_t n) {
register char *d = dest;

if (!dest)
return NULL;

if (src && *src) {
for (; *src && n > 1; n–)
*d++ = *src++;
}

*d = ”;

return dest;
}

if len is 0 in this case you still end up with *d = ”; and hence cause an off-by-one overflow.

So please, refrain from building your own string copy functions, coz you WILL fuck up !

Why am I not surprised ?

I wonder what kernel memory looks like :)

Update:
NetBSD ptrace() information leak :)
see ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2006-025.txt.asc

“Officials at an elementary school south of Boston have banned kids from playing tag, touch football and any other unsupervised chase game during recess for fear they’ll get hurt and hold the school liable.”

they go on to say:
“Recess is “a time when accidents can happen,” said Willett Elementary School Principal Gaylene Heppe, who approved the ban.”

You get a captain obvious award for that one (yea, that’s right, I stole the captain obvious awards thing from fefe !)

This is INSANE. Especially for this occasion I made an insane-o-meter in ms paint (YES, ms paint !)

from the webpage:
“As you might imagine, we are upset at Windows for not being more hardy against such viruses, and even more upset with ourselves for not catching it.”

So they fucked up and try to blame it on microsoft.

That’s just grrrrrrrreat !

if(something);{
blah blah blah
}

yea, this stands out now, but it might not if you put it in between a few thousand lines of code !

urandom_read() is a direct read() hook that get’s called from vfs_read() (which in turn gets called from sys_read()). The bug here is pretty obvious. There is size_t truncation here:
i = min_t(int, nbytes, EXTRACT_SIZE);

At this point I was thinking “WTF ? this is wrong, how can this be in /dev/urandom code !!!!”. I remembered that there are some range checks in vfs_read() and hence I looked in vfs_read():

/*
* rw_verify_area doesn’t like huge counts. We limit
* them to something that fits in “int” so that others
* won’t have to do range checks all the time.
*/
#define MAX_RW_COUNT (INT_MAX & PAGE_CACHE_MASK)

int rw_verify_area(int read_write, struct file *file, loff_t *ppos, size_t count)
{
…
loff_t pos;

if (unlikely((ssize_t) count < 0))
goto Einval;
pos = *ppos;
if (unlikely((pos < 0) || (loff_t) (pos + count) MAX_RW_COUNT ? MAX_RW_COUNT : count;

Einval:
return -EINVAL;
}

ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
ssize_t ret;
…
ret = rw_verify_area(READ, file, pos, count);
if (ret >= 0) {
count = ret;
…
ret = file->f_op->read(file, buf, count, pos);
…
}
return ret;
}

(actually I was told about this code by linus torvalds himself, after I reported a ppc specific bug in /proc. I believe his (almost) exact words were (I lost the email) “We added this code in 2.6. to prevent integer abuse in read/write hooks, I believe it got backported to 2.4 aswell”. And it did get backported to 2.4, I checked. The reason I stumbled on this bug (it’s in src/arch/ppc/kernel/htab.c proc_dol2crvec() btw, bonus points for whoever can spot signedness issue) because of a capture the flag game at HITB bahrain last year. The game got pretty boring so we decided to own one of the organisers laptop (hi Dhillon !) WITH PERMISSION! He was using an iBook with some linux distro on it, and using the 2.6.10 kernel at the time. That kernel didn’t have the range checks yet and hence the proc_dol2crvec quickly gave us read access to most kernel memory. We eventually ended up rooting it because of that bug. Which brings me to my point, that all of these horrible read/write bugs in drivers were in fact exploitable (and were exploited) on linux prior to just adding the range checking code in rw_verify_area and hence should still have gotten fixed !.)

Hm, wandered off there for a bit, let’s get back to the code in rw_verify_area(). What it basicly does is check for:
- size not negative
- offset nog negative
- size + offset not negative
and then TRUNCATES size_t -> signed integer, see the code comment.

This is shocking imo! But done for security reasons, which is certainly a noble thing. But this hides horrible bugs. So in fact it does the opposite. It sends out a message that “It’s ok to write crappy kernel code, we’ve got code in place to mitigate”. Anyone who ever looked at some of the drivers in the linux kernel knows there is a huge pile of low quality code in there, and a lot of copypasting is done (let’s call it infecting other code with low quality code). So even if you have crappy code that’s covered by the range checks and truncation in rw_verify_area() and vfs_read() someone might copypast your code in some place where’s it’s not covered by these range checks and you’ve got a big fat security hole on your hands. Not to mention that there might be another codepath to read() hooks in drivers thru some ioctls (where it doesn’t go thru vfs_read()).

What this means in reality is that on systems where sizeof(size_t) > sizeof(int) (mostly 64 bit architectures) that you only get to read or write at most 2 gigabytes of data (in a single call to read() or write()), even though you might want to read or write more then that. Which is INSANE! There is no need for this. Obviously you could try to make a case for this and state that you should do this in a loop of 2gig reads or write’s at a time. But this is kind of silly. Because it adds a needless loop (there is already such a loop in place in the kernel most of the time, in the /dev/urandom case for example) and more importantly it adds syscall overhead !

I’m sure by now some people are going “But you could use mmap, USE MMAP !” NO, you can’t. Hm, well, not always. See, there are non-regular files out there that don’t let you mmap. /dev/urandom for example, or /proc/pid/mem (Zalewksi++). But wait, it get’s worse, write() is covered by the same restrictions as read() in rw_verify_area() and therefor you can only write 2 gigs at a time. Not something you really want (thanks fefe).

I bet there are apps out there that actually break on this! there have to be, with all the crap that people put out there there’s gotta be 1 or 2 applications that go up in flames because of this!

if you want to add some range checks, then check if the count given is int truncation. It breaks functionality !

edit:
another one
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/sys_generic.c.diff?r1=1.150&r2=1.151&f=h

“Prevent IOC_IN with zero size argument (this is only supported
if backward copatibility options are present) from attempting
to free memory that wasn’t allocated. This is an old bug, and
previously it would attempt to free a null pointer. I noticed
this bug when working on the previous revision, but forgot to
fix it.

Security: local DoS
Reported by: Peter Holm
MFC after: 3 days”

free(uninit_ptr);
that’s not just a DoS :)

asprintf is basicly very simular to sprintf and snprintf, but unlike those 2 calls it dynamically allocates memory and hence the programmer doesn’t have to worry about boundschecking. Programmers seem to misunderstand that and think that they’re in the clear if they just use asprintf. Nothing could be further from the truth. See, there’s a corner case. What if malloc (which it uses internally) fails ?

Before I go into that, let’s first see how asprintf works:
int asprintf(char **strp, char *fmt, …)
Basicly you give it a pointer to a pointer as first argument and then a formatstring with some arguments.

so what if asprintf fails ? It returns -1. However, the content of strp upon failure is “undefined” according to the linux manpage. the OpenBSD manpage says the following about it:
“The asprintf() and vasprintf() functions [...] If sufficient space cannot be allocated, these functions will return -1. The value of ret in this situation is implementation-dependent (on OpenBSD, ret will be set to the null pointer, but this behavior should not be relied upon).”

in reality, all the BSD’s set strp to NULL and the glibc implementation (used on most linux distributions) will not change it.

So in linux this makes it interesting for exploitation. Suppose one uses asprintf() and forgets to check the return value (which is very common btw, but more on that later). it leaves strp uninitialized. in most cases strp will be on the stack. Meaning that it’s realistic to assume a user has control over this uninitialized variable (more on this can be found at http://www.felinemenace.org/papers/UBehavior.zip and http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Flake.pdf) . So depending on what the application does next with this pointer it might be exploitable. Common scenario’s are passing this pointer to free() at some point (so you don’t get a memory leak) or for example having it point to some path that’ll get used in chmod/chown/open/rename/…. Definatly not a good thing to have. Often (even when asprintf() is used correctly) people tend to forget to free() memory obtained with asprintf(). Sometimes people also incorrectly handle asprintf failure. Since everyone seems to be looking at google code search for vulnerable example’s I did the exact same thing and quickly spotted a nice example of incorrect failure handling:
static char *
gen_dbsuffix(char *db_name, char *sfx)
{
char *dbsuffix;

if (sfx == NULL)
sfx = “.ok”;

asprintf (&dbsuffix, “%s%s”, db_name, sfx);
if (dbsuffix == NULL) {
fprintf (stderr, “gen_dbsuffix: out of memory\n”);
exit(1);
}
return dbsuffix;
}
that’s in MIT kerberos btw. Spotting the error should be obvious (considering what I just said about asprintf). While doing these google code searches I found out that the following abuse asprintf in one way or another:
- gnu radius
- heimdal kerberos
- samba (I’m shocked I tell you !)
- glibc’s pt_chown
- mailutils
- gnu sasl
- MIT kerberos

rsync used to have a nasty bug related to asprintf aswell, but that one recently got fixed.

edit: 2 things I forgat to mention, the first being, that last time I checked dietlibc has simular behavior to glibc’s (with regard to asprintf failing). The 2nd that using asprintf in return into libc exploits can be very usefull, since you get to allocate memory, And put data on it, without needing to check any registers.

2nd edit: It seems I made a terrible mistake. fefe just emailed me and told me dietlibc’s asprintf has always set strp to NULL on failure. I do apolgise for this. Must have confused it with something else.

http://www.nytimes.com/2006/09/25/nyregion/25courts.html?ex=1159761600&en=c46719645257c30c&ei=5065&partner=MYWAY

I’m shocked horriefied and disgusted by this.

one of many shocking things in there:
“I just follow my own common sense,” Mr. Buckley, in an interview, said of his 13 years on the bench. “And the hell with the law.”

words fail me to describe how much this disturbes me !

via fefe: http://blog.fefe.de/?ts=bbe49d57

But that’s besides the point. There was a post made to the dailydave mailinglist titled “Does Fuzzing Really work?” http://lists.immunitysec.com/pipermail/dailydave/2006-September/003551.html in Which Aviram Jenik states the following:
“There’s a lot of talk lately on whether fuzzing can actually be used to find
vulnerabilities – and more importantly, reliably rule out the existence of
unknown vulnerabilities. … our experience shows it can.”

They’re wrong. They base this on a bunch of numbers they got from their own fuzzer (I’m guessing Aviram is one of the people that works on the fuzzer). Some of those numbers are:
“The FTP protocol has 310 “scenarios” of
valid FTP sessions. If you try to overflow each time a different part of the
command in every scenario you get a little over 12M attack combinations. If
you use some of our nifty beSTORM 2.0 optimizations you get to 70,679 attack
vectors.
…
FTP is too simple you say? With more complex protocols like SIP you have
>15,000 scenarios and something like 40,680,459 attack vectors after
optimizations”

See, their numbers are wrong. I don’t know the exact numbers either. No one knows. They’re only testing what they have tests for (duh !). But one of the things I figured out when I started to play with fuzzers is that if you take any given fuzzer and make some changes (add a test for a length of 0 in a certain protocol for example) (and hence, change the numbers) you find new 0day. So their numbers are incomplete. For example, In their http tests I’m sure they have code that generates url’s. But they probably forgat something. Does it also generate ipv6 urls? if so, does it also generate ipv6 url’s with “%”? (http://[::1]%eth0/ for example). maybe the network device name parser has a trivial stacksmash. Does it have a list of all url scheme’s that might be usefull to fuzz for 1 particular http(-alike) daemon? What about incorrectly formed encoded url’s. http://isec.pl/vulnerabilities/isec-0020-mozilla.txt for example. I don’t know of any fuzzer out there that efficiently fuzzes these kinds of bugs except for my own . I once wrote a url fuzzer that does all of these things any many more things, it was pretty big, but more to the point, I’m sure I forgat something.

“Sounds scary at first, but a SIP server capable of handling
500 requests per second would take only 22 hours to test, …”

Assuming their number are complete (which they’re not !) this means you can test all possible combinations that matter in 22 hours, how nice. However, in reality you know there are things you missed. So to compensate for this, one of the things I like to do is every once in a while substitute 1 thing I’m fuzzing with something random and do this in an endless loop. Some people seem to think this is useless (Arrogantly assuming their numbers are complete), but that’s not true. I’ve had success with this in the past. Finding bugs after days or even weeks. Where the trigger is something I totally didn’t anticipate. A nice example here is a bug in the linux tcp/ip stack that dave jones found with isic earlier this year: http://kernelslacker.livejournal.com/35361.html

quoting even more:
“My point is to those people who mock fuzzers – you either tried the wrong
kind, or you tried them a long time ago. I’m not saying that buffer overflows
are suddenly obsolete (don’t delete that ZERT bookmark just yet!). But
nowadays there is no reason for an FTP server to come out with buffer
overflows; there’s just no excuse.”

If their numbers aren’t complete there might be fuzzable things they’re not fuzzing, and hence there is an excuse. But let’s assume they’re testing all that they can test. Even then there are still issues that might not have been caught by their fuzzer. for example, earlier this year ISS x-force released an advisory for a remote signal race in sendmail (discovered by Mark Dowd). This one would be a bitch to fuzz, and I can’t think of a way to do it in an efficient manner.

Then again. Maybe this was all just to advertise their new fuzzer.

A couple of hours ago I was reading through the openbsd 3.9 -> 4.0 changes. One of them stated “Fix signal races in ping(8)”. So I looked at OpenBSD’s ping.c and there was indeed a fix for a signal race. I figured, let’s check NetBSD, since they still have a lot of shared code, there might be simular races in NetBSD’s ping code.

And thus, I go to NetBSD’s cvsweb and look at ping.c and while reading it I though to myself “well, this is odd, there is no socket() and privdrop before argument parsing” (and some people might already see where I’m going with this). socket() was indeed after argument parsing, but I couldn’t see the privdrop code. So I search for setuid, seteuid, setreuid, setresuid. NOTHING !, absolutely NOTHING. Do my eyes deceive me ? I must have missed something, it cannot be this bad !

I must have spend an hour digging through their code,
looking for the missing privdrop. thinking to myself “maybe it’s abstracted away in some ugly and nasty way, or maybe it’s in some library code”. But I found nothing that indicated any of that. Then it sort of hit me, THERE IS NO PRIVDROP IN NetBSD’S PING IMPLEMENTATION.

Still in disbelieve I decided I needed to test this, so I recompile NetBSD’s ping from source and add the following right before it exits:
printf(”euid: %u\n”, geteuid());

the output I got:
ping -c 1 127.0.0.1
PING localhost (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.065 ms

—-localhost PING statistics—-
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.065/0.065/0.065/0.000 ms
euid: 0

I am Shocked and horrified. You’d expect this kind of glitches from apple (who added a privdrop to ping and traceroute about a year ago !) but from NetBSD ? It’s 2006 for fucks sake !! I compared with OpenBSD and FreeBSD, both added a privdrop OVER A DECADE AGO !

I decided to look at NetBSD’s traceroute aswell, after all, who knows, they might be consistent in not having privdrop code. They did mildly better in traceroute. There was a privdrop, AFTER argument parsing.

Ofcourse, you could argue that you don’t need a privdrop, as long as you don’t have any [security] bugs. But euh, you know, I mentioned these signal race conditions earlier …

as a final note, I went through all of the ping.c commit messages for NetBSD and some of them stated something about an overrun and some fd_set overflows, but I couldn’t find anything about this in their advisories.

on linux (hm, well, glibc on linux) what ttyname() does is return the link used in /proc/self/fd.

which leads to interesting problems. you can have /proc/self/fd point to pretty much anything you want.
it can contain “..”, it can itself be a symlink, ….

So be really carefull when using it (in a suid for example) or avoid it all together and use something else.

It’s in dutch !
basicly, this is a small piece of some tv show called “vips” where they interview this woman who is one of the 22 finalists of the “Miss Belgian Earth” contest.
They ask here what the qualities are of such a Miss.
Here response: “sweet, spontaneous and smart”.
So the interviewer asks her: “what’s the square root of 25 ?” and she responds: “Don’t do this, really, don’t ! This isn’t fair, they’re always out to get me” clearly showing she doesn’t know the answer. The interviewer asks her if she’s better in languages to which she responds: “no, not good at that either”.

I don’t know if I’m more shocked at the lack of basic mathematical skills this person posseses, or the fact that that particular tv station actually decided to put this on the air.

“Not checking the return value of close is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota. ” — linux close

“When successful, these functions [(v)asprintf] return the number of bytes printed, just like sprintf(3). If memory allocation wasn’t possible, or some other error occurs, these functions will return -1, and the contents of strp is undefined. ” — linux asprintf

“An fd_set is a fixed size buffer. Executing FD_CLR or FD_SET with a value of fd that is negative or is equal to or larger than FD_SETSIZE will result in undefined behavior.” – linux select

“If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively lock the mutex results in undefined behavior. Attempting to unlock the mutex if it was not locked by the calling thread results in undefined behavior. Attempting to unlock the mutex if it is not locked results in undefined behavior.” — linux pthread_creat_mutex

“Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs” — linux malloc

“provide the additional specifiers q and a as well as an additional behaviour of the L and l specifiers. The latter may be considered to be a bug, as it changes the behaviour of specifiers defined in ANSI X3.159-1989″ — linux scanf

“If there is no next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), random errors will occur.” — netbsd varargs

“All data associated with an ELF descriptor remain allocated until elf_end() terminates the descriptor’s last activation. After the descriptors have been terminated, the storage is released; attempting to reference such data gives undefined behavior. Consequently, a program that deals with multiple input (or output) files must keep the ELF descriptors active until it finishes with them.” — sun libelf

“Upon successful completion 0 is returned. Otherwise, EOF is returned and the global variable errno is set to indicate the error. In either case any further access (including another call to fclose()) to the stream results in undefined behaviour.” — linux fclose

“The routine handler must be very careful, since processing elsewhere was interrupted at some arbitrary point. POSIX has the concept of “safe function”. If a signal interrupts an unsafe function, and handler calls an unsafe function, then the behavior is undefined.” — linux signal

Feel free to contribute some in the comments.

“Another bug in the su command exists in some System V ports where if su was unable to open the password file (”etc/passwd”), it would grant root access (without checking the reason for the failure). I guess the programming can tell that something is wrong and grants access so someone can fix things. The security problem occurs when when su is executed with a full file descriptor table; this will force su to fail its open request on the password file.”

This isn’t as unlikely as you’d think:
http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/games/dm/Attic/dm.c?rev=1.9&content-type=text/plain&hideattic=0

I wonder what would happen if read_config() can’t open the config file ….

edit:
the FreeBSD and OpenBSD write program have (the OpenBSD guys fixed it) a simular issue. If it can’t open the utmp file it allows one to write to any file the tty group is allowed to write to.
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/write/write.c.diff?r1=1.23&r2=1.24&f=h

linux shadow utils (su, login, passwd, chfn, chsh) will happely continue working if it can’t open its configuration file. So this would for example allow one to change his or her shell (chsh) or gecos (chfn) without needing to authenticate.

that’s from postfix. Apparently it’s more important to exit with some meaningfull explenation then to prevent any kind of memory allocation in a signal handler (this is from the timeout watchdog it smtpd !)

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.

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 !

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

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

Since I indepentantly discovered this bug about 2 years ago, let me fill you in on the details, the minix ftpd implements site crc, which basicly gives you the crc32 of a file. The first bug (or feature, whatever) is that you can call that without logging in. The 2nd and totally idiotic bug is that it does the following:
system(”/bin/crc32 “);
This falls in the “I can’t believe they fucked it up” category.

I have it from reliable sources that ALL 3 minix boxes on the internet got compromised this way.

Back to the tenex password hack tho, I’ve been thinking about this. I think you can also use it on hashes. Suppose you have a program like passwd, and have some nice rainbow tables at your disposal, you could use the tenex password hack to figure out the hash, and hence get the password (since you’re already using these rainbow tables :)).

OpenBSD’s getcwd implementation used to contain a double free(). Actually it was a double closedir(), which is just a wrapper for free(). The funny thing about that bug is that it was introduced when fixing a memory leak:
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/gen/getcwd.c.diff?r1=1.2&r2=1.3&f=h

NetBSD used to have this leak aswell, however it appears as if the OpenBSD guys never told them about it (I think back then they weren’t really talking to each other). The NetBSD guys accidentally fixed that memory leak the exact same way the OpenBSD guys fixed the double free(), replacing the libc getcwd() implementation with a systemcall.

Here’s a little tip for people who are forced to make advisories, if an attacker can corrupt memory, assume it’s exploitable!, what happens if you dont ?
http://www.securityfocus.com/archive/1/394315/30/0/threaded
http://www.securityfocus.com/archive/1/394413/30/0/threaded
http://www.securityfocus.com/archive/1/394318/30/0/threaded

When I read that I was like “Hold on a minute, so you’re telling me I can put a file -of which I control large chunks- anywhere on the system, and this is just a DoS ?”. I didn’t actually investigate this is detail, since I had more important things to do, but here’s What I was thinking, have a symlink to /etc/ld.so.preload, then coredump to that symlink (assuming that codepath in the kernel follows symlinks). Last time I checked the gnu dynamic linker is very flexible about that file. basicly it’ll just go line by line till it finds a lib that works. I don’t know is this will acutally work, but I’m sure it’s something like that.

Then, this morning I read the dailydave mailing list and saw: http://lists.immunitysec.com/pipermail/dailydave/2006-July/003293.html

So the immunitysec guys made an exploit for it, and refering to Paul Starzetz. Later today I ran into http://www.securityfocus.com/archive/1/439610, where Paul states it really is exploitable.

He makes another good point in that post: ” really wonder why in the recent past there is a tendence to declare such things as “denial of service” etc – while they are perfect root backdoors / vulns”

That’s been annoying me a little bit lately, and it’s not just the linux kernel guys, A lot of people have been downplaying bugs (either knowingly -lying- or not -incompetence-). It’s even worse then that. When (some) people don’t realize something is exploitable, they tend not to fix it. Although they usually acknowledge it’s some sort of coding bug. For example, a few weeks ago I mailed some linux vendors regarding a bug is passwd, namely not checking the return value of setuid(). Someone mailed me back stating: “You know, we don’t know if this is actually exploitable, and I don’t want to go fix all of these bugs, So if you can’t provide me with a ./hackroot exploit, I won’t fix it”. Honestly, I think this is unacceptable, Wether or not a bug is exploitable it’s still a bug, so JUST FIX THE DAMN BUG! more often then not bugs turn out to be exploitable.

- BuGless AKA Stephen R. van den Berg (procmail)
- Greg A. “Don’t worry though — it’s definitely not exploitable” Woods (smail 3)
- Philip Hazel (exim)
- Matt Wright (formmail, wwwboards)
- Rasmus Lerdorf (php)

One of the things I ran across was that their realloc implementation will never resize to something smaller. While technically this isn’t a violation of the c standard it’s still pretty retarded.

One other surprising thing I found was that their calloc code in older versions fuckedup boundschecking for 64-bit: http://cvs.opendarwin.org/cgi-bin/cvsweb.cgi/Libc/gen/malloc.c?rev=1.1.1.1&content-type=text/x-cvsweb-markup&cvsroot=apple

#define MAX_ALLOCATION 0xc0000000 // beyond this, assume a programming error
…
void *malloc_zone_calloc(malloc_zone_t *zone, size_t num_items, size_t size) {
void *ptr;
if (malloc_check_start && (malloc_check_counter++ >= malloc_check_start)) {
internal_check();
}
if (((unsigned)num_items >= MAX_ALLOCATION) || ((unsigned)size >= MAX_ALLOCATION) || ((long long)size * num_items >= (long long) MAX_ALLOCATION)) {
/* Probably a programming error */
fprintf(stderr, “*** malloc_zone_calloc[%d]: arguments too large: %d,%d\n”, getpid(), (unsigned)num_items, (unsigned)size);
return NULL;
}
ptr = zone->calloc(zone, num_items, size);
if (malloc_logger) malloc_logger(MALLOC_LOG_TYPE_ALLOCATE | MALLOC_LOG_TYPE_HAS_ZONE | MALLOC_LOG_TYPE_CLEARED, (unsigned)zone, num_items * size, 0, (unsigned)ptr, 0);
return ptr;
}

Incase you don’t spot the bug here, size_t is 64 bit (on 64-bit machines), but a cast to unsigned means unsigned int which is 32 bits long !!! hence there can be truncation later on !

in new versions they just removed the boundscheck, I kid you not, you just can’t make this stuff up.

In the older versions malloc and the like had the same flawed lengthcheck which doesn’t make sense at all !!!! you shouldn’t do boundschecking on the length at this level. the app that uses malloc should do it. The only thing you might want to check for is int overflow. Speaking of this limitation, the OpenBSD kernel memory allocator has very simular behavior, but only even more retarded:

void *
malloc(unsigned long size, int type, int flags)
{
struct kmembuckets *kbp;
struct kmemusage *kup;
struct freelist *freep;
long indx, npg, allocsize;
int s;
caddr_t va, cp, savedlist;
… some debug crap …
if (size > 65535 * PAGE_SIZE)
panic(”malloc: allocation too large”);
…
}

for those who can’t read c code, what this means is, if you tell malloc to allocate a really big chunck it will instead kernel panic. bug or feature ? I guess it was ok to do this in 1975, but It’s 2006 for fucks sake. ofcourse netbsd suffers from the same bug/feature. Not too long ago you could trigger this from the ELF loading code and I believe there are still some obsd drivers that allow you to trigger it.

In light of the whole calloc fuckup I started doing some googling, since I remember an advisory being published about this several years ago. http://cert.uni-stuttgart.de/advisories/calloc.php. Someone made the connection with fread and fwrite and it turns out they also contain a simular int overflow. since the osx guys stole fread/fwrite from FreeBSD, I checked fbsd and it appeared to have this int overflow. Then I figured I’d check openbsd which also has this int overflow. What’s somewhat more worrysome is that obsd’s fread and fwrite are NOT thread-safe especially since obsd recently got a whole new threading implementation: http://www.openbsd.org/papers/eurobsd2005/tedu-rthreads.pdf. I figured I’d check the obsd manpage for fread and fwrite and see if they mention that it’s not thread-safe. but they didn’t, infact, their fread and fwrite manpage hasn’t been update since 1994 !!!! It should come as no surprise that netbsd has the same int overflow issue. I didn’t even try to check glibc, I still want to hold on to my sanity for a while :)

SMALL UPDATE: There is some discussion on the netbsd current-users mailing list about this. Some seem to have misinterpreted my posting. The osx and NetBSD userland allocator have pretty much nothing in common and I wasn’t hinting towards that. But the (older version of) osx userland allocator and NetBSD/OpenBSD kernel allocator have 1 thing in common, namely a check like
if (size > something) bailout;
which imo doesn’t make sense at all especially if “bailout” is a kernel panic ! The other thing I mentioned about NetBSD was an int overflow in their fread and fwrite implementation. I made no other statements about NetBSD.

I’m sure most have heard the theory that if you do that it dies. So I went to my lab and did some experiments. Turns out that it does effectively die. Although, I did not try it with water but with beer, I wonder if that makes a difference.

So I go to lenovo.com and order my brand new thinkpad x60 laptop. And since I want it to be here fast I said I want 2-day shipping. AND THE FUCKING ESTIMATED TIME TO SHIP IS THE 14TH OF THIS FUCKING MONTH !!!

HOW LONG DOES IT TAKE TO ASSEMBLE A FREAKING LAPTOP ???? 2 WEEKS ? WTF ARE THESE GUYS DOING ?

Needed to get that off my chest, I feel better now.

A while ago I’ve spend some time looking into regex evasion myself. Although not looking for oddities in the regex implementation itself, but instead looking for weaknesses in the regex itself.

For example, if you have: /^\d$/ that would only match numbers (0-9). Or so you would think, the $-sign will also match a next line. A potential attack vector here would be where the inputted data gets written to a line-based file. Where all the sudden you get next line injection.

After some googling I found out that this kind of regex evasion is used sometimes with some ids’s, there is a nice post about this on the snort forum: http://www.snort.org/archive-3-1353.html

The Redteam people think that we haven’t seen the last of these kind of attacks and I believe they are right.

Basicly, what I did was look for a filesystems that have userland utils that allowed me to make an empty partion in a file instead of a device. I think I ended up fuzzing ext2/3, reiserfs, xfs,jfs and fat12.

Then used mangle.c in a loop with the loopback device and sat back till something happened:

EVERYTHING BLEW UP WITHIN SECONDS !!!

when I say blow up, I mean full kernel panic or atleast very scary oopses.

The only exception is fat12. It didn’t break. not at all, nothing, I couldn’t even get it to printk() some debug crap. My guess is this is because a) fat12 is a really trivial fs and b) floppies are so unreliable that whatever corruption you can ever have with fat12 already happened at some point in the past and has been dealt with.

I remember emailing Hans Reiser about some of this stuff, but never got a reply. Several months later there was an interesting thread on lkml:
http://lkml.org/lkml/2006/2/19/138

If you know of more people to be on this list, please make a comment.

As for the fuckedup layout of the previous post, I am aware of it and will fix it at some point (yes, I am a slacker ….).

page 10:
Page 10 covers a list of usefull books to read in addition. There is however no mention of “writing secure code 2nd edition” by Michael Howard and David LeBlanc. While the book is somewhat windows centric it is one of the best books out there
regarding secure coding, and a lot of whats mentioned there can be applied to unix aswell.The book does get mentioned later on when they cover threat modeling, but it deserves more credit imho.

page 14:
No platform is immune:
“So far, Mac OS X has not fallen prey to any major, automated attack like the MyDoom virus. There are several reasons for this. One is that Mac OS X is based on open source software such as BSD; many hackers have searched this software over the years looking for security vulnerabilities, so that not many vulnerabilities remain. Another is that the default installation of Mac OS X turns off all networking services that might be used to exploit vulnerabilities. Also, the email and internet clients used most commonly on Mac OS X do not have privileged access to the operating system and are less vulnerable to attack than those used on some other common operating systems. Finally, Apple has an active program of reviewing the operating system and applications for security vulnerabilities and issues downloadable security updates frequently.”

The fact that something is opensource software and that it has been audited before is no guarantee whatsoever that it’s more secure then a commercial equivalent. There has been a lot of disscusion around this, and people have concluded that it can have the potential to be more secure but it doesn’t have to be. In this particular case they use BSD as an example. Every once in a while I audit BSD code, and there is nothing magically secure about it, plenty of security bugs in there to go around.

So OSX turns off all network deamons by default. But the firewall is off by default last time I checked, there is dhcp parsing code IN THE FUCKING KERNEL, and it does send out an recieve mdns constantly.

So the email client, browser, and other utils don’t run as root. So if you own them you don’t instantly own the box. That’s what local root exploits are for, it’s a very common 2-step thing! I know this is defense in depth, but I wouldn’t go so far as to brag about it, it might bite you in the ass later.

The Idea that apple’s browser and email client are less vulnerable to attack then others is total bullcrap. In fact, the opposite is true. When I did browser fuzzing safari was ALWAYS the first to break. It’s simply not up to par with IE and Firefox when it comes to parsing input !

I guess “frequent” is a relative term, as sometimes 3 or 4 months go by without a single security update
only to get followed up by a MONSTER security update (40+ vulns fixed in 1 update). Also “frequent”
doesn’t say anything about consistency, it would be nice to have something like patch tuesday for osx.

page 19:
Types of vulnerabilities:
“There are two ways in which heap overflows are exploited: First, the attacker tries to find other data
on the heap worth overwriting. Much of the data on the heap is generated internally by the program
rather than copied from user input. For example, an attacker who hacks into a phone company’s billing system might be able to set a flag indicating that a bill has been paid. Or, by overwriting a temporarily stored user name, an attacker might be able to log into a program with administrator privileges. This is known as a non-control-data attack.

Second, objects allocated on the heap in many languages, such as C++ and Objective-C, include tables of function pointers. By exploiting a buffer overflow to change such a pointer, an attacker might be able to substitute their own data or to execute their own routine.”

This is somewhat short on information. Specifically it doesn’t explicitly mention messing with heap metadata. Which is what most heap exploits out there do. And this is very much possible with the osx memory allocator, infact there was a phrack paper about it: http://www.phrack.org/phrack/63/p63-0×05_OSX_Heap_Exploitation_Technqiues.txt

page 24:
Types of vulnerabilities: social engineering.

While social engineering is certainly a security issue, It has NOTHING whatsoever to do with secure coding guidelines. Social engineering is also mentioned on page 66 and 67.

page 36:
There is a list of insecure functions and then the more secure equivalent of these functions that should get used. Unfortunatly, some of these more secure functions have some known issues that one should be aware of, they are however not mentioned. More specifically I’m talking about snprintf and fgets. Also it fails to mention the scanf* functions, which I believe should really be in there.

I blogged about snprintf abuse earlier:
http://blogs.23.nu/ilja/stories/10508/

With fgets, it is very common to overwrite the \n character at the end with a 0byte. often
code like:
if (fgets(s,len,stdin) != NULL)
s[strlen(s)-1] = ”;
is being used. The problem here is that it’s possible to have zerolength strings and effectively causing an off-by-one underflow. (if you don’t believe me, download some opensource software and grep for fgets!, it really is very common).

page 46:
secure file operations:
“9. Compare the device and inode numbers in the stat structure obtained before you opened the file with those in the stat structure obtained after you opened the file to verify that they are the same file.”

This is just wrong! just because file x has ino y and is on dev z at time n-1 doesnt mean that at time n the file with ino y and on dev z is file x ! Ok, so this might sounds a bit confusing, there is actually a nice mailing list post about this: http://www.opennet.ru/base/audit/17.txt.html

page 49:
There is a reference to “building secure software” for more info on how to prevent file race conditions. Unfortunatly the info in there is flawed and suffers from the same issue as page 46 step 9 as described earlier.

page 57:
“Because launchd is a critical system component, it receives a lot of peer review by in-house developers at Apple. It is less likely to contain security vulnerabilities then most production code”.

And yet when I audited it last year It contained a textbook example of a file race condition (see http://www.suresec.org/advisories/adv3.pdf for more details). More worrysome is that at the time the todo file stated (and I quote): “code review”.

page 58-59:
a code example, and that’s not confusing because ….

page 69:
Page 69 mentions threat modeling, but forgets to mention “Threat modeling” by Frank Swiderski and Window Snyder, which is basicly THE book about threat modeling, it covers nothing else !

There were some things I really liked about the paper:

page 10:
mention of david wheelers secure programming for linux and unix howto. That one is actually REALLY good. I wonder why David never turned it into a real book (as in, get it in a professionally printed version).

page 36:
There is a list of insecure functions and then the more secure equivalent of these functions that should get used. It mentions the more secure replacements for strcpy, strcat, strncpy and strncat. Namely strlcpy and strlcat, 2 functions designed by some of the people of openbsd, for more info, see http://www.openbsd.org/papers/strlcpy-paper.ps

page 55:
functions to “change privilege level” I like how they specifically say to watch the return value (hi vixie cron) and that those calls are confusing and differ across different unices.

So, a conclusion is in order here I guess. There were some dissapointing things in there, first off, there was no mentioning whatsoever about fuzzing, and testing code was only VERY briefly mentioned. Likewise almost nothing was said about secure kernel programming. The only thing that got briefly mentioned regarding kernel programming was to use Kauth and to be carefull which modules you load if you make a helper program that needs to load a module. Imho there was too much marketing in the paper, I don’t want to know why osx is more secure then something else
(wether or not it’s true) I just want to get the facts about writing secure code for osx. I feel this paper didn’t get much (or adleast not enough) peer review. It’s too incomplete. Lastly there is a fair amount of usefull content in there, but please, take it with a grain of salt.

edit: The cat is out of the bag, the bug in cron I hinted towards (see page 55 comment) got fixed not too long ago:
http://bugs.gentoo.org/show_bug.cgi?id=134194

Ok, somewhat misleading. They don’t really do that, but they made an exception for Brian Krebs (a fairly well known tech. reporter at the washington post), you can read about it in his blog: http://blog.washingtonpost.com/securityfix/2006/05/a_time_to_patch_iii_apple_2.html

Basicly Brian made a summary of the last 2 years of vulnerabilities (in OSX) that got fixed by apple, and ran it by apple. who subsequently gave most of them a severity rating. You can see apple’s ratings at:
http://blog.washingtonpost.com/securityfix/apple updated FINAL.htm

from the blogpost: “Even though the company [apple]officially eschews severity ratings, it didn’t have any problem assigning numbers to the flaws listed in my spreadsheets, with those flaws earning a “1″ deemed the most serious and those with a “4″ the least worrisome”

So I want to talk about 1 particular vulnerability, namely CVE-2005-3705. This is a remote heap overflow in webkit. Which is basicly the html rendering engine (from kde) that apple uses for safari (and some other programs). It was given a severity rating of 4 by apple, so according to apple it’s “least worrisome”. HILARIOUS ! anyone still taking apple security seriously ?

Let’s make a hypothetical comparison with microsoft here. Suppose there was a remotely exploitable heap overflow in IE (hm, well to make it more equal, let’s say in mshtml.dll which I believe ms uses to render html, feel free to correct me). Do you think the good people over at MSRC (http://www.microsoft.com/security/msrc/default.mspx) would even consider rating something like that anything less then critical (which would more or less compare to 1 in the apple severity rating) ? OFCOURSE NOT !!!! the press would have a field day with that one. besides some media attention it just doesn’t make sense. You have a utility that comes default with your os that you use maybe 100 times a day to surf the internet, and it has a heap overflow in it that could potentially get triggered by ANY WEBPAGE YOU VISIT, without clicking on anything on that webpage.

Some people might be thinking that it got rated least worrisome because there is no exploit for it, or because it would be hard to do. This is simply not true. As it turns out, that particular vulnerability got reported to apple by one of my co-workers (Neil Archibald). And he does have a proof-of-concept exploit for it (no, I will not email it to you!). I’m sure some people now might think “ok, so you have an exploit for it, no one else does, so the rating is still valid”. That would make no sense at all, If Neil can make a working exploit for it, then so can anybody else who knows what he’s doing !

long abs(long l) {
if (l < 0) return -l;
else return l;
}

It always returns a positive value, right ? Wrong !!!
If you give in 0×80000000 it will return 0×80000000.
Basicly if you’d negate that with 2nd complement you end up with the same negative number.

While at a customer this week I learned something really interesting. When you’re in a meeting and things get written on a whiteboard, do NOT take notes, take pictures !!!

Moving on to some security blogging. I’ve been doing a whole bunch of code reviews lately and one of the things I’ve seen are good boundschecks being performed INSIDE assert statements. THIS IS BAD !!!, if you do this, please stop doing so. It doesnt help. The only reason to use assert is to help the programmer catch some things that shouldn’t happen AT ALL. asserts go away once you do a non-debug compile (and if your stable program releases are compiled with -DDEBUG or something simular you should get shot). DON’T DO BOUNDSCHECKING INSIDE assert’s.

A while ago I ran into an interesting return value issue:
pipe(fds);
basicly if you’d do this you’re assuming pipe always succeeds. Obviously it doesnt always succeed, and when that happens you end up with uninitialised file descriptors. Turns out they sometimes lead to VERY interesting security bugs. always check your return values !!

Lastly, I want to quickly blog about null pointers. I was planning to write a whole paper about this, but as I wont have any time anywhere in the forseeable future I’ll just blog it. Basicly, some null pointers can be exploited. The thing is that you have to see them in the right context. The context in this case is kernel space. What happens if you get a null pointer deref in kernel space ? you get a page fault, right ?
These just might be exploitable !. In most modern oses the address space is ’shared’ between the kernel and whatever app is running at that point. on 32 bit machines the first 2 or 3 gigs of address space (which is where 0×00000000 is located) are reserved for the app and the rest is for the kernel (mind you, this is os and in some cases architecture specific). So if the os allows you to map 0×00000000 it’s possible to exploit (most) null pointer derefs inside the kernel. That means local priv. escalation !.

so basicly, in order to exploit (most) null pointer derefs inside a kernel you need 2 things:
- a ’shared’ address space between your app and the kernel
- the os has to allow your app to map 0×00000000

This works on most modern unices. I would suspect this works on most other modern operating systems aswell. (this doesnt work on osx btw).

Exploiting the null pointer inside userspace is sometimes also possible. I’ll leave that for another blogpost tho.

Oh, and there are even some public references to exploiting null pointer derefs. In 1994 there was an exploit from a group called 8lgm that exploited a null ptr deref in SCO unix (although this was in userspace). It is mentioned in the shellcoders handbook (check page 505). And last year at cansec there was a talk about memory related problems which also covered exploiting null pointers.

edit: exploiting null ptr derefs this way is not just theoretical, there are real exploits out there for this kind of bugs !

2nd edit: It appears I missed 1 public reference to NULL pointer exploitation in the kernel. http://isec.pl/vulnerabilities/isec-0023-coredump.txt
It is mentioned there in a VERY subtle way :)

3th edit: another subtle post about it
http://eeyeresearch.typepad.com/blog/2006/08/post_ms06035_ma.html

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).

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/

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.

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 :)

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 !

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().

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, ….

How I hate mac fanboys ….

Anyways, At IT Underground, when I was talking to Shawn Merdinger about how I tracked down one particular bug with isic he told me that this kind of stuff should get documented. Since It’s pretty trivial to do so I dont feel like dedicating a full html page or a paper about it, but I’ll just blog it.

Basicly, you first run isic doing something like:

isic -s 192.168.10.132 -d 192.168.10.126 -F 15

wait till whatever you try to fuzz panics or breaks in some way and hit ctrl + C. when you do that you see the following:

“Caught signal 2
Used random seed 5579
Wrote 37001 packets in 2.64s @ 14016.17 pkts/s”

so you know the tcp/ip stack you broke died somewhere in the last couple of 1000 packets. basicly the next thing you want to do is generate the exact same packets, and then skip the first X packets, and manually do a binary search untill you narrowed it down to a single packet.
This is really easy to do with isic.

Generating the same kind of packets is easy, since you know the seed that got used to generate the packets you can feed it back to isic using the -r switch. Next, you want to skip the first 25000 packets for example, this too is trivial: -k 25000. and then you want it to send no more then the amount of packets you initially send, which in this case is 37001 packets, this can be done with the -p switch. so you’d do:

isic -s 192.168.10.132 -d 192.168.10.126 -F 15 -r 5579 -k 25000 -p 37001.

now if the tcp/ip stack you fuzzed panics, you know its somewhere in the range of 25000-37001. Now all you need to do is a binary search, and you should find the culprit within 30 minutes or so.

Once you know which packet causes problems (using ethereal as a sniffer for example) you can use scapy (the coolest tool ever to do low level packet construction) to reconstruct the packet in a simple one-liner. So that you can try to figure out what exactly is needed to trigger the bug.

Hope this is usefull to someone.

I bet if RMS read this he’d be thrilled. The text doesn’t end there tho, but it shocked me somewhat when I read it the first time. It continues with “What incentive would there be to continue your hard work? …”

The full link is:
http://www.microsoft.com/piracy/how_intellectual.mspx