just a quick update…

It has been a while since I’ve posted anything that would fall into the ‘life’ category, so I figured I would give a quick status update.

I haven’t been doing much over the past few weeks, been doing some off and on reading of random documents (USENIX, Blackhat presentations, etc.) but nothing really notable. Things have been crazy over the past month with work and traveling back and forth from NC, so I haven’t really had a lot of time to do some stuff that I’ve been meaning to. Now that a lot of it has settled down, I’m able to relax a little bit and do some stuff on the weekends that I’ve been putting off for a while.

My first goal is to finish another book, either “The Design and Implementation of the FreeBSD Operating System” or “Computer Architecture, Fourth Edition”. It is no secret that I love BSD and I came really close to reading the old school 4.4BSD book and I probably will at some point, but so much has changed across all the BSD operating systems since then that I feel like I would benefit more from reading one that incorporates the changes that have been implemented in the past 5+ years. The problem still remains that there aren’t any texts that cover recent versions of FreeBSD ( >5.2), but I can at least get a base line understanding and then get the rest from the source. A part of me just wants to skip the book phase and go straight to the source, as that always seems to help me more than reading books, but we’ll see. There is also that book on computer architecture that looked like a REALLY good read, I might pick that up and see if I can’t start reading through it as well. Anyhow, thats my reading for the next 2 or 3 months (I’m slow, but try to be thorough).

As for the other stuff, I’ve been reviewing some code recently, nothing too hardcore but just something to keep the wheels turning. Now that things are settling out, I’m hoping to spend some more time reviewing a few open source projects. I’m also hoping to be at USENIX this year and am planning on doing the Linux kernel internals training with a friend from work, which will be a nice getaway for a few days.

Anyhow, so thats the update. I’ll be looking into the patch Tuesday bugs over the next day or two, so if I run across anything worth posting, I will.

order of evaluation fail

I was looking at the PHP patches again, when I saw this block of code was fixed:

int ptlen = strlen(pt) - strlen(env_script_name);
int path_translated_len = ptlen + env_path_info ? strlen(env_path_info) : 0;
char *path_translated = NULL;

path_translated = (char *) emalloc(path_translated_len + 1);
memcpy(path_translated, pt, ptlen);
if (env_path_info) {
memcpy(path_translated + ptlen, env_path_info, path_translated_len - ptlen);
}

I thought this was interesting, I’ve never actually seen a vulnerability ‘in the wild’ caused by failing to account for the order of evaluation. I’m surprised this code even worked in the first place without consistent crashes, but I guess it did. Either way, what happens is the + is evaluated before the ? is and the compiler will generate code that first adds ptlen and env_path_info, then checks the result of the addition for a value, and then branches (which is more than likely going to be always true), as opposed to branching and then adding the result of the conditional like was intended. So the value of ptlen, which is intended to be used in the allocation, is never added into the value of path_translated_len and a too-small buffer is allocated.

The nasty thing about this bug is that it can be exploited without running a PHP script since it is in the CGI SAPI.

oh and…

This is just cool:

http://www.engadget.com/2008/05/04/bug-bot-video-reveals-swarming-drones-extreme-rocking/

PHP 5.2.6 released

The latest version of PHP addresses a few vulnerabilities. One of my favorite past times is looking at patches, but PHP is of particular interest to me since the Month of PHP bugs is kindof what got me really started. I got a little bit of time to take a look at one of the bugs which I thought was kindof interesting.

The first is a relatively straightforward integer overflow in printf style functions. The overflow actually occurs in php_sprintf_appendstring, which is not directly exported as a PHP function. The code looks something like this (as always thank WordPress for the lack of indentation):

int copy_len = (expprec ? MIN(max_width, len) : len);
int req_size = *pos + MAX(min_width, copy_len) + 1;
if (req_size > *size) {
while (req_size > *size) {
*size <<= 1;
}
*buffer = realloc(*buffer, *size)
}

This is obviously only a small portion of the function, but it is where we see the meat of the bug. It should be obvious that since req_size is signed and we control the values going into the arithmetic, we can cause an overflow which would cause the signed comparison between req_size and *size to evaluate to false, which means the reallocation will be skipped despite the need for it. Later on in the function, we see something roughly similar to this:

while(padding_length–)
(*buffer)[(*pos)++] = padding

Where padding_length is (min_width - copy_len). So with a large value as padding_len (larger than our buffer anyway), we write the value of padding across the heap padding_length times. There is also a memcpy call that occurs which could be used for some fun too, but I didn’t really want to spend too much time on it. So from here, do some cscoping (greatest tool ever) and we can see that there are 7 cross references, which I was planning on explaining but realized it would be too large of a post for such a simple vulnerability (that and you could probably make assumptions based on the PHP documentation and variable names without actually reading the code, but where is the fun in that :p). Anyhow, you can trigger the bug by doing something similar to printf(”foo [%2147483646s]“, “AAAAAAAAA”). So, thats the quick and dirty on that one. I should probably note that there is much more to the code that depends on other arguments in the prinf style statement (eg alignment), but again, if you are that interested you can ask and I will explain or just look at the code.

The other one that caught my eye is detailed here:

http://www.sektioneins.de/advisories/SE-2008-03.txt

And is just plain cool. There were some others that I haven’t had time to look at yet, but hopefully will soon.

OpenBSD 4.3 released!

Rock on! Take a look:

http://www.openbsd.org/43.html

malloc madness

Ever since Mark Dowd’s unholy exploit for Flash came out, there has been a lot of attention and debate regarding checking the return value of memory allocation functions and the repercussions of not doing so.

My first point is, why would you NOT check the return value of malloc style functions for NULL? I mean, that is something you learn from day 1 with those types of functions and there is nothing good that comes from not checking. I guess I don’t understand the school of thought that not checking the return value is considered acceptable.

What I am torn on is whether or not allocation failures should fail inside of malloc or in the caller. I think Ptacek makes an interesting point and one that I’ve thought about a few times, which is why bother returning NULL and not just cleanup inside of malloc when the allocation fails? In a lot of ways it makes much more sense, but at the same time I can see why I wouldn’t want to do that. What if I want to call my own cleanup routines or handle the allocation failure on my own? He proposes that we have a function that does the same thing malloc does now and return NULL, but I think what the end result of all this would be is that devs would still call the ‘unsafe’ version of malloc as opposed to the safe version. After all, it isn’t that hard to just create a wrapper function for malloc that does what you want and protects from these NULL derefs.

I also think a lot of people are blowing this out of proportion. I wouldn’t consider this to be anything completely mind blowing or all that new (ok, the exploit itself is amazing, I’m referring to the concept of NULL+offset). You still can’t exploit vanilla NULL pointer derefs, you have to be able to (in some way or another) control an offset that is used in some type of pointer arithmetic. Even if you forget the whole NULL dereference thing, I think that using a user-controlled offset into a memory block is cause for concern in itself. A lot of the people that are commenting on this have more experience than I do, so its likely I’m missing something here, but if I can control and offset into an array, structure, or just a block of memory in general, I feel like that alone is a problem. Granted it could be sanitized in some way, but if it is exploitable in a NULL+offset bug, I imagine ptr+offset wouldn’t be that much more difficult to exploit in some cases. I guess it depends on the bug, but either one of those would be cause for concern in my book.

Someone (can’t remember off the top of my head atm) also made the interesting point that it doesn’t have to be directly a NULL+offset, don’t forget that access to structure members is performed via offsets as well. So something like struct->int_b, would turn into a [ptr+4] when compiled. While this alone isn’t exploitable (since we don’t control the offset), having an array inside of a struct like struct->int_b[user_val] could turn into an exploitable condition because you are essentially doing [ptr+4+(user_val * sizeof(int))], but I revert to my previous point that if I’m able to exploit that using a user supplied value (user_val) with a NULL deref, then that alone is a problem.

compiler vulnerabilities

We had a little bit of a discussion on compiler vulnerabilities in the office today and CVE-2008-1685 came up.

The vulnerability lies in the fact that GCC assumes that the value of a pointer plus an integer is always greater than the pointer. So if you were checking for an overflow in the following way:

if((ptr+some_int) < ptr)

The comparison would be removed. Pretty cool stuff if you ask me, I’ve always found vulnerabilities in compilers kindof fun (virtual machines too). Anyhow, short post, I just promised someone I’d give someone information on the bug.

Why devs should learn both C and C++

The second stackoverflow podcast has a pretty good explanation of why developers should learn both C and C++. Give it a listen here:

http://blog.stackoverflow.com/

I couldn’t agree more. I think one of the biggest problems with our computer science grads today is that, if they learn C and C++, it is very basic and they quickly are moved to Java or another higher level language. I know of a few programs that allow students to substitute C and C++ for Java and a few others that ONLY offer Java as an introductory language. No thanks.

I have to disagree with him that C and C++ aren’t as common or popular as other languages. I think that depends on what circles you are in, there are still plenty of places for C and C++ developers to work and make their mark (kernel development, libraries, etc). In the business world, I can definitely see what he is getting at though, most of what we saw at my previous engagement was .NET.

Anyhow, worth listening to. I like the way that he explains it.

A quick look at the MS08-021 stack overflows

Someone had asked my opinion of these, so I took a quick (like 30 minutes) look at them and at the exploit that was posted on milw0rm.

I say these because there were a number of functions changed in the last patch, mostly removing ‘dangerous’ function calls (lstrcpyW, wcsncpy, etc) and replacing them with safer variants. The truth is that of the number of functions changed (I want to say around 10), only a few appear to be exploitable and only one I know for sure is. It is good thing, but no one should freak out because of so many removed functions.

I really only took a look at two functions, the others I perused but did not spend much time on. The first was ICMCreateColorSpacebyName and is definitely exploitable. It is a fairly generic lstrcpyW call that causes a vanilla stack overflow, the exploit on milw0rm exploits this vulnerability by using a EMR_COLORMATCHTOTARGETW EMF record. I feel like there are other records that can be used, but I haven’t verified it. I am going to try and play with it this weekend and work on it with a friend and see if we can come up with different paths. I can also say that it is mitigated on SP2 by /GS.

The second was BuildIcmProfilePath and does not appear vulnerable, despite several wcsn* calls. I did a quick reversing of a portion of the code and it looks something like this (sorry for the lack of indenting, kthx wordpress):

if(return_value_from_GetFilenameFromPath == arg_0) {
wcsncpy(var_20C, _ColorDirectory, 0×104);
wcsncat(var_20C, asc_7F11568, (0×103 - wcslen(var_20C)));
wcsncat(var_20C, var_210, (0×103 - wcslen(var_20C)));
wcsncpy(var_214, var_20C, arg_8)
/* Null terminate */
}

So it doesn’t appear to be vulnerable, they appear to be using the functions properly and accounting for the NULL byte in the size. The last call to wcsncpy seems dodgy, as does the else block (which is a similar call using arg_8 as the size_t value), but I looked at all the crossrefs and arg_8 is always equal to 0×104.

Anyway, that is quick and dirty. I wanted to spend more time on it than I did but I’ve been swamped the past few days and haven’t had a chance. It is quite possible that I missed something here, if I did then let me know :)

New home

On the recommendation of a friend, I thought I would give WordPress a try and I really like it. While blogger was nice since it integrated with my Google account, I really didn’t like the interface and it just felt…clunky. I like the WP templates a lot better as well, so I just decided to switch everything over a few days ago.

Anyhow, welcome back.