First off, some bitching. Online accounts, and why I dont want them or need them. A lot of websites out there want to force you into creating a free (they always mention that its “FREE” and so it must be good, right?) account. If you don’t do so you can’t access whatever it is you want to access. Now there are obviously cases where you’d want this (writing a blog entry, buying something on amazon, putting something up for auction on ebay, …). But people abuse it, I DON’T WANT NO STINKING ACCOUNT TO DOWNLOAD PAPERS, READ SOMEONE’S BLOG, OR EVEN ACCESS SOMEONE’S SITE. coz it’s timeconsuming, and coz you’ll want to remember your password (adleast for 5 minutes so you can log in and do whatever you wanted to do). PLEASE STOP DOING THIS UNLESS IT IS NEEDED !!!!
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