I know all good programmers have probably heard all this before but since I recently found some code which does some mixing and matching of binary and string functions I figured it was worth touching on. The following functions read NULL bytes and continue to read input until some event for the storage buffer is filled, recv, read, fgets, and many more. As we all know that the end of a character array is marked by a NULL byte.

What am I getting at here? The main reason I'm posting this is because I recently saw some code which reads in data from a file using fgets(). This code then checks for the first character to see if its a comment character ('#'). If it is it ignores that line and reads the next line. However, the code later looks a little something like this:

buff[strlen(buff)-1] = '\0';

If the first character of the line was a NULL byte the strlen() would return 0 as the first char marks the end of the data. This obviously leads to a simple off-by-one issue.

A more correct version of this would look something like this:

size_t len = strlen(buff);

fgets()
...

if(!len)
return ERROR;

else
buff[len - 1] = '\0';

Of course this is just a simple example of some of the dangers of reading in binary data and treating it as a character array.

Recently a heap overflow in Quicktime's handling of HTTP response codes when attempting to connect to a server using RTSP on TCP port 80 was discovered. I have spent some time lately investigating this vulnerability.

It appears that this issue is caused due to a flawed attempt to perform bounds checking. When data is read in from the server Quicktime executes a function at 0x6761d530 (QTCacheComponent_ComponentDispatch+80b0) which copies the data to the heap. This function takes 3 arguments the source buffer the destination buffer and a length value. The issue seems to be the caller of this function passes the strlen() of the source buffer rather than the size of the destination buffer.
The following is the disassembly of the copy:

loc_6761D550:
mov al, [ecx]
mov [esi+ecx], al
cmp byte ptr [ecx], 0
jz short loc_6761D560
inc edx
inc ecx
cmp edx, edi
jb short loc_6761D550

This would be equivilent to the following:

strncpy(dst, src, strlen(src));

Obviously this is not correct. This causes a very large overflow which can overwrite several heap chunks.

As covered in several publicly available papers this can easily be exploited on Windows 2000 and prior if the overflow runs into a free heap block an attacker could overwrite the heap management structure used to unlink a free block from the doubly linked free list. This allows for a 4 byte arbitrary overwrite. Windows XP SP2, Windows 2003, and Windows Vista present more of a challenge for exploitation in this fashion. This is due to additional sanity checks performed during the unlinking of free blocks from the free list within the RtlFreeHeap() function.

As of right now I have not found a way to successfully exploit this issue on my test machine running Windows XP SP2. It does however, appear that the exploit code I do have would yield code execution on Windows 2000 SP4 machines. I have two possible options for XP SP2. I could try to either find a way to reach a code path which if hit would cause the free block to be placed on the lookaside list rather than the free list. This would allow me to bypass the checks. The other option seems to be overflowing into a block containing a critical section linking structure and perform a similar attack on that structure.

I'm still investigating the methods of exploitation on Windows XP SP2. If I do manage to get code execution I'll post my conclusions so keep an eye out.

In a previous blog post I mentioned that some of the new features in IE7 would likely becomes vectors for vulnerabilities. The recent Black Tuesday (Microsoft Patch Tuesday) security bulletins confirmed my initial suspicions. Three vulnerabilities in the .NET framework were patched this Tuesday two of which affect IE7.

As stated previously IE7 added support for .NET applications so that .NET applications could be run from within the web browser. The recent vulnerabilities are sure to encourage other vulnerability researchers to dig deeper and find more vulnerabilities in .NET. I would not be shocked to see a trend in .NET vulnerabilities emerge as more and more people learn about the framework and begin to figure out ways of testing the framework for vulnerabilities.

I have not blogged in a while so I figured I better get back to it. I'm going to touch on some source code auditing techniques regarding variables. I hope you all enjoy. Feel free to leave any comments regarding this post or any suggestions.

When auditing source code theres a lot of things to keep in mind such as return values, code paths, logic etc. Today I'll discuss a little bit about how to properly follow variables in code.

First thing to notice about any variable is the datatype. In the C and C++ languages there are several different datatypes which are of various sizes and represent various forums of data. When following a variable through the code the best thing to do is to look at the declaration of the variable. Make a note of what datatype the variable is declared as and what amount of data can be stored in it.

The next thing to do is to watch the variable and make any notes of where the variable is assigned a dynamic or static value. Dynamic values are typically much more interesting than static values however, programmers can and do make mistakes by assigning static values to variables. While looking for variable assignment the auditor should keep in mind the datatype and any kind of typecasting which may be taking place which could cause the intended values being assigned to be represented differently than expected.

Now the auditor should have some basic information about the variable. From the first two steps the auditor should be able to get a fairly clear picture of what the variable is used for and what kind of values the variable can receive. The next part is to try to find relationships between variables.

Relationships between variables is often important. Variables which rely on each other to get value can often times cause problems. This is typically due to trust of the other variables value. If a variable relies on another variable to get a value and a user can manipulate the value of either variable there may be times when the variables can be out of sync with each other and this can cause problems in some portions of the code which should be looked at. For instance, one variable may have some sort of arithmatic preformed on it based on the value of another variable.

Whenever an auditor sees a variable which is important to how a function operates the auditor should consider that any dynamic values the variable receives which is user supplied is always malicious. Dynamic values which are most interesting to look at are values which can bypass logic, cause an arithmatic operation to result in a value which is not expected (ie. a negative array index), large integer values, and long strings.

If auditors pay attention to variables they are sure to find some bugs.

I know its been a while since I posted anything. But to behonest not a lot of interesting things have been going on in the security world lately. Everything has been kind of slow due to the holidays. However, I expect that to change.

I've been doing some research lately on some vulnerability classes and doing some inivative work with regards to vulnerabilities. I hope to be sharing my findings with everyone in a few months. Likely I'll be doing a talk at a conference. I haven't decided which one I'd like to talk at yet but I am thinking about it.

I'll post some more in the coming months about common types of vulnerabilities and how to spot them in code. I think people really seem to like that subject. So I'll continue in that trend and post some more vulnerable code and explain why its vulnerable along with the usual stuff thats going on in the security world.

Happy New Years everyone!

The scanf function is an interesting one. It definately leaves a lot of room for a programmer to go wrong. The most commonly known bug is that scanf does not do any bound checks explicitly. This can however be solved with the proper format string.

The following is an example using sscanf which is used to read formatted input from a variable:

void split_input(char *buf)
{
char a[256], b[256];

sscanf(buf, "%s:%s", a, b);
printf("%s\t%s\n", a, b);

return;
}

In this example what happens if buf contains input which does not match the specified format? First we need to consider the state of the variables. In this example the variable a and b are not initialized. This fact leads us to our answer. The variable a will be assigned a value as long as buf contains data. However, if buf does not contain input in the format "somestring:someotherstring" the b variable will remain uninitialized. This can lead to some interesting vulnerabilities if the uninitialized data can be controlled prior to calling this function. Another thing to point out is that if buffer contains input larger than the allocated space for the variable a and b between the ":" delimiter a buffer overflow will occur because these functions do not check bounds.

Another typical bug occurs when programmers try to solve the issue of the scanf family of function not preforming bounds checks. Above I mentioned that this can be solved by using the proper format string. If you thought automatically that the format string I had intended was "%.NNs" NN being the value to restrict the size by, then you would be very wrong. The scanf family of function utilize a different form than the printf family of functions to limit the size of a format.

char buffer[256];
scanf("%256s", &buffer);

This example depicts the proper form of restricting the size of a format within the scanf family of functions. There is however a subtle flaw in the example which I added on purpose to show that even this is not always so easy to do properly. In this example we have an off-by-one condition. The last valid index of buffer is 255 the format which is specified will fill the entire buffer leaving no room for the null byte.

So using scanf functions can be very dangerous when they are not properly used. If you must use them try to read the manual page for them and test your code extensively.

Internet Explorer 7 has caused a lot of hype lately. It just recently became public and people are already finding some very minor bugs in it. The thing most people haven't looked at is how IE7 deals with some of the older bugs. It seems like IE7 has done a lot to improve. For instance now when active content is displayed on a page A dialog will come up asking you if you want to run the control and it will also give you some information about the control. ActiveX controls have been the biggest source of vulnerabilities in IE. With this feature atleast users can have some idea what it is they are enabling the website to do.

IE 7 seems to have been designed with security in mind. Although theres some features which were added which in my opinion sound like bad ideas from a security stand point. XAML is one technology being put into IE7. XAML is a markup language which is useful for creating user interfaces. By incorporating XAML into IE7 Microsoft has come up with what they call XBAP. XBAP is a .NET binary which can be rendered inside of IE7. They have considered security in this case by adding a sandbox around the binary. The interesting thing is that the idea of XBAP is so complex and it takes ideas from so many other technologies which have inheriently had security issues that this idea is bound to be buggy. Another interesting point is that the UI elements created from XAML will be vector graphics rendered using DirectX. This seems interesting as many of the DirectX vulnerabilities in the past were not such a big deal because they only seemed to affect people who played video games or had malicious local users on their machine.

I'm sure theres other interesting things in IE7 which might be useful to look at as well. Just recently someone found a interesting bug which could be used to spoof a link to a SSL site and make the site seem like it has an invalid SSL certificate. This alone while a very minor bug could be used in some sophisticated attacks.

Another interesting this is that IE7 allows you to manage ActiveX controls and it allows you to enable or disable them at will. However one thing which does standout is that there are some ActiveX controls which are in the list which can be used without authorization from the user. If theres a vulnerability in any of these default controls that would be rather disasterous.

The internet is a dangerous place. Users keep wanting new flashy features. Until a feature has been tested extensively and been reviewed and beta tested for an extended period of time those fatures should not be added to software which already has its problems. I think Internet Explorer definately does not spell the end of IE 0-day and I truely feel we will be seeing a lot of interesting and new vulnerabilities in it.

Internet Explorer 7 has its upsides and its downsides its gonna be a fun journey indeed.