No, I’m not dead yet

January 9th, 2007 by ilja

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.

undefined behavior

December 16th, 2006 by ilja

Every once in a while I go looking for “undefined behavior” in some manpages (or the lack thereof).
I found a good one this time. This is straight from the hp-ux pthread_mutex_lock manpage:
WARNINGS
A recursive mutex can be locked more than once by the same thread
without causing that thread to deadlock. Undefined behavior may result
if the owner of a recursive mutex tries to lock the mutex too many
times.

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

hardcoded off-by-one’s

December 16th, 2006 by ilja

About 2 months ago I found some security bug in FreeBSD. I mailed them about it (both colin and security-officer@), no reply, so I mailed again about a month ago, no reply, so I mailed again 2 days ago and finally got a reply (after writing “I mailed this to you guys twice already in the course of about 2 months, no response so far,trying one last time:” in my email) from one of their security people that they are looking into it. Today I got a reply saying that “there is very little risk”.
because of the nature of this bug (I’m not going to give too much detail yet :) I mailed back to say I disagree, and am currently looking into some possible attack vectors (it’s not a trivial stacksmash or anything like that) (woohoo, free QA, think I could bill them ? :). So at some point I start digging into some of their pam code and read the following:
void
makesalt(char salt[SALTSIZE])
{
int i;

for (i = 0; i < SALTSIZE; i += 4)
to64(&salt[i], arc4random(), 4);
salt[SALTSIZE] = ”;
}

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.

eweek’s OnSecurity podcast

December 14th, 2006 by ilja

I just listened to the one where they interviewed Dave Aitel. It was interesting, they talked about some of the common computer security things, disclosure, ZERT, hacker-vendor relationship, ….
By far the most entertaining thing about that podcast was the small commercial at the beginning. I think it was for some patch management thing from microsoft. In it you hear this aussie saying “A dingo ate my server”. that cracked me up !

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

0day alert

December 9th, 2006 by ilja

It seems fefe has been auditing gnupg and found some hilarious bugs. Read about it here. The blog’s in german, but you don’t need to be able to read german to find t3h 0day !

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

2 wonderful quotes

December 4th, 2006 by ilja

2 really cool quotes I just read:
“…and is of course LGPLed (”free as in communism”).” — Michal Zalewski
“These people are looking more and more like a criminal organization every day.” — Bruce Schneier about the MPAA

Bruce has a point !

OpenBSD allows suid shellscripts ?

December 4th, 2006 by ilja

I’m stunned !!
why the fuck would it do that ? No other sane os on the planet has allowed that to happen for adleast a decade !

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

Fuck you lenovo

December 4th, 2006 by ilja

A couple of months ago I was forced to buy a new laptop after a liquid experiment with my laptop. I purchased the ibm thinkpad x60, coz I love those small machines. The machine is nice, but the screen really blows. I’ve only had it for a few months And I’ve already lost count of how many broken pixels it has :(

oh, it’s just a kernel panic

December 2nd, 2006 by ilja

yea right !
so, assume you have a bug in your kernel that simply calls panic() and does nothing else wrong. They do exist, take the fpathconf() bug in osx for example.
A lot of people don’t believe these are security bugs.
I beg to differ. THEY ARE SECURITY BUGS. for one, a panic effectively causes a shutdown. SHUTTING DOWN A BOX IS A PRIVILEGE NO ONE EXCEPT THE SUPERUSER SHOULD HAVE ! maybe this isn’t entirely true on a desktop, but this sure makes sense on something that’s used as a server. So for this fact alone it’s a security bug. But it gets worse. kernel panics often lead to loss of data on disk. This is because at the time of panic not all data is synced to disk. I’ve had this happen to me quite a few times when toying with some kernel bugs on OpenBSD and NetBSD. I assume this is probably common among most operating systems, and that none that I’m aware of have special disk sync code in the panic() function (or BugCheck[Ex](), depending on which os you’re using).
When I was playing with some osx kernel bugs in late 2004 and early 2005 I once had my entire home directory removed after a kernel panic, something you really don’t want. But wait, it gets even worse. Kernel panics are unnatural, they interrupt everything you do and basicly panic your system. That means, that some weak hardware might not like it and you might cause hardware to break (while this is probably rare these days, I’ve been told by some oldtimers that this used to be a big problem for some hardware).
I’ve talked to lmh (of the month of the kernel bugs) and he told me that if you use filevault on osx, and have a kernel panic that whatever filevault is protecting gets garbled, certainly not something you want.

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

PinkBSD

November 29th, 2006 by ilja

a.k.a NetBSD blowing up on a trivial ioctl fuzzer.