“There is some sort of perverse pleasure in knowing that it’s basically impossible to send a piece of hate mail out through the Internet without its being touched by a gay program. That’s kind of funny.” — Eric Allman.
got that from http://findarticles.com/p/articles/mi_m1589/is_n754/ai_20350568
http://plan9.bell-labs.com/sources/plan9/sys/src/ape/lib/bsd/gethostbyname.c
just did a google codesearch for gethostbyname()
the 90’s called, they want their bugs back!
Every once in a while I stumble on some kernel code where the code attempts to do authentication based on the pid of the calling process.
This does not work ! it’s insecure, just don’t do it!
Usually, the code assumes that process with pid x has certain privilege’s.
for example, lets say you only want root to issue ioctl’s on a device.
you’d make the open callback for your device do something like:
open_fn() {
if (current->uid == 0)
add_pid_to_trusted_list(current->pid);
}
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.
I was reading http://lists.grok.org.uk/pipermail/full-disclosure/2008-February/060411.html and figured I’d take a look at some if it’s code. it’s not all that secure. here are some code snippets:
void splitvtrc()
{
…
char line[BUFSIZ], newline[BUFSIZ*2], *parsed[256];
…
for ( i=0, head=ptr=newline; ((ptr-newline)<(BUFSIZ*2-2))
&& *tail; ) {
…
parsed[i++]=head; <– no boundscheck done for parsed
…
}
}
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;
…
}
I like browsing through amazon’s website as much as the next guy, but pandzilla showed me a new way of appreciating amazon. Looking for the craziest reviews of items on amazon. Breathtaking !
some things you should see:
http://www.amazon.com/Underhill-Farms-Elk-Carcass/dp/B000IDOB5Y/ref=sr_1_23/104-0721154-5701564?ie=UTF8&s=gourmet-food&qid=1173397485&sr=1-23
http://www.amazon.com/Bobs-Red-Mill-Xanthan-Gum/dp/B0000CCZUO/ref=pd_bbs_2/002-2655636-8027208?ie=UTF8&s=gourmet-food&qid=1173207456&sr=8-2
http://www.amazon.com/gp/product/customer-reviews/B000002UB3/sr=8-3/qid=ARRAY(0×58fc7004)/ref=cm_rev_sort/002-3634337-6436051?customer-reviews.sort_by=%2BOverallRating&s=music&x=12&y=8
http://www.amazon.com/gp/product/customer-reviews/B000001FS3/sr=1-11/qid=ARRAY(0×574a1498)/ref=cm_rev_sort/002-3634337-6436051?customer-reviews.sort_by=%2BOverallRating&s=music&x=8&y=12
isn’t that hilarious ?
FiSH is a plugin for most popular irc clients that implements encryption. I looked at it a few years ago, and it was horrible. Stacksmashes _everywhere_. I briefly looked at it again yesterday, only to discover that all the bugs are still there ! somewhat shocking. I wonder how many people have been owned because of those bugs.
I looked at the xchat plugin code (but I believe most of the code is shared and only the entry point code is (obviously) different) and it basicly registers 4 functions that handle incomming data:
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
“trying to unfuck [some issue] while it’s still unfuckable” — Dan Kaminsky
http://www.usatap.org/FAQ.htm
check nr 6. omfg, these people need to be shot !
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 knew it was going to happen eventually.
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
Been a while since I blogged. I’ve been busy you know, xmas, 23c3, newyears, recovering from all that, ….
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.