bannedit's blog

Binary or String?

2008-02-15T19:08:00.002-05:00

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.

Quicktime RTSP

2008-01-22T13:30:00.000-05:00

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.

IE7 .NET Predictions Confirmed

2007-07-13T16:49:00.000-05:00

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.

Become One With the Variables

2007-03-08T21:29:00.000-05:00

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.

Happy New Years

2007-01-04T12:35:00.000-05:00

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!

Common Bugs in the scanf Family of Functions

2006-11-15T11:22:00.000-05:00

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 The Beginning of the End or Just the Beginning?

2006-11-07T14:16:00.000-05:00

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.

strncpy fun

2006-10-11T15:19:00.000-05:00

Lately I've been a tad busy doing some code projects. So I have neglected the blog a little bit. I have had some time lately to do some code audits and I've noticed some interesting types of bugs which some may misunderstand.

Commonly we think that strncpy will null terminate for us. Many of us already know this is not the truth. I recently saw some code which was doing something like the following:

char buf[BIG_BUFFER+1];
...
strncpy(buf, user_data, BIG_BUFFER);

So why is this bad? Well it might not be obvious if your not all that familiar with the operation of strncpy. The strncpy function copies data to another memory location. In this case we are copying user_data into buf. We also specify a size value of BIG_BUFFER which is how many bytes we need to copy. Many people have heard I'm sure that strncpy will null terminate for you. However, there is some truth to that but its not entirely all there is to it. It will null terminate if the data supplied to copy is less than the size passed to the function. We see here that BIG_BUFFER is less than BIG_BUFFER + 1. So what is the problem?

By setting user_data to a value >= to BIG_BUFFER we fill buf all the way to the last array slot. The last slot is left empty ... or is it?

In C strings are defined as a memory location which continues on until a null byte marks the end of it. 0x41 0x41 0x41 0x41 0x41 0x41 0x00 is an example of the string "aaaaaa". The null byte marks the end of the buffer.

The thing to remember in C is that memory starts out as uninitialized. So seemingly random data can be contained with memory which is not specifically assigned a value. In the above example we see the buf is never assigned a value. If it were this might not be a problem at all.

In our example we reach the next to last slot of the array buf. We leave the last array slot untouched. When the strncpy function finishes the array will not be null terminated as one might imagine due to the BIG_BUFFER+1 size declaration and the BIG_BUFFER strncpy argument. Instead that last slot of the array is uninitialized.

So if we look back to our definition of a string we can see that the expected null byte is not there so any functions which treat this memory as a string value will incorrectly read past the end of the buffer due to the uninitialized memory located at the last slot of the array.

Exploiting uninitialized memory bugs is a topic for another day. There are some great papers out there on the subject mercy@felinemenace has written one up a while back and Halvar has done some talks at Blackhat about it so if your interested search around and I'm sure you'll find what your looking for.

Internet Explorer 0-day The Continuing Saga

2006-09-27T20:07:00.000-05:00

Microsoft recently patched the VML issue which was causing such a fuss in the security industry. This is one of the few times they have actually done an out of cycle patch. I definately think it was the right thing to do any I think it should happen a little more often.

The day the patch came out Metasploit's HD Moore released a exploit module which preformed about 4 different methods of evasion in an attempt to evade Intrusion Detection Systems and Anti-Virus scanners. It is definately the best exploit out there at the moment for this issue. However, it still uses javascript which mean disabling javascript is still a saving grace. Still one should be aware that javascript is not a necessity when exploiting this issue.

So now on to the topic at hand. VML was definately a 0-day vulnerability but it was just patched which makes it no longer 0-day. So where is the new 0-day? Is it in something different? Is it just as bad as VML?

The newest 0-day exploit comes yet again from HD Moore (good job). This time around we can really start to see that Microsoft has a lot of work to do when it comes to security and the process of patching vulnerabilities. There was an exploit today released for a vulnerability which was disclosed nearly 3 months ago. The issue has gone nearly 3 months unpatched. It was originally thought by many to be just a Denial of Service but it turns out it is really much much more than that. The issue is within the ActiveX object WebViewFolderIcon.

This is only exploitable within Internet Explorer. A good workaround for this issue would be to disable active scripting and also set the killbit for this ActiveX object.

It just goes to show that denial of service vulnerabilities sometimes turn out to be exploitable even though many who have taken a close look say otherwise. The security industry is full of people with varying skills and varying skillsets. Keep this in mind when you listen to all the comments surrounding a security issue.

I can't recall how many times I've heard that some vulnerability is only a denial of service due to such and such a factor. Then I take a look at it and it turns out to be much more than just a denial of service. Very recently a vulnerability was discovered which rendered any denial of service condition exploitable in applications in which a user could sufficiently influence the loading and unloading of libraries resulting in arbitrary code execution (MS06-051). I have always been of the opinion that if you can not state something as a fact don't make any statement at all.

VML - The Vulnerable Markup Language

2006-09-22T01:24:00.000-05:00

Everyone I'm sure has heard all the hype surrounding the VML bug in vgx.dll. To start off this vulnerability is extremely easy to exploit and it affects just about everyone on the internet in some way or another. The issue is simple stack-based buffer overflow in the VML implementation utilized in several applications to render Vector Graphics. The problem occurs when the vgx.dll library parses a VML fill method tag which contains a long string.

Internet Explorer, Outlook, Microsoft Office, all of these products are affected by this vulnerability. The funny thing is that everyone seems to only be targeting Internet Explorer. I think the reason for this is that Internet Explorer was the first product which was reported to be affected and no one seems to have thought much about the true ramifications of this issue.

Currently no one has published publicly any exploit for XP SP2. From what I have seen the issue is extremely easy to exploit for every platform and for every service pack. I myself have an exploit which works under XP SP2 using very similar methods to the publicly available exploits. From what I have heard it seems like there is some malcode out there which has also figured out how to get exploits working on XP SP2.

Microsoft has reportedly stated they plan on releasing a patch but will not do so until their scheduled patch release on the second Tuesday of October. This seems like a long time to wait for such a simple patch. However, this is the main draw back of scheduled patch releases. I have always though Microsoft should take a more proactive approach and release patches for simple issues a lot sooner than they do. Until that day comes Microsoft has issued a workaround for this vulnerability.

Buffer Overflow Where?

2006-09-18T23:11:00.000-05:00

Recently RiseSecurity publicly disclosed a vulnerability within the XKeyboard extension for X11R6. The funny thing about this vulnerability is just how silly it really is. If you ask anyone now adays they will tell you that buffer overflows are not as straight forward as they used to be. What I mean by thins is that to find buffer overflows in source code about 5 years or so ago all anyone had to do was grep for some function known to be vulnerable. Now it is true that its a lot harder to find bugs using the same techniques. This bug however, is proof positive that the silly bugs from the past still exist in code.

static int
#if NeedFunctionPrototypes

Strcmp(char *str1, char *str2)

#else

Strcmp(str1, str2)

char *str1, *str2;

#endif

{

char str[256];

char c, *s;

for (s = str; c = *str1++; ) {

if (isupper(c))

c = tolower(c);

*s++ = c;

}

*s = '\0';

return (strcmp(str, str2));

}

We see here that str1 is directly copied into the local array str which is 256 bytes. This data copy is done with no consideration of the actual length of the data being copied or the capacity of the destination buffer which is str in this case. This is pretty much the equivilent to a direct strcpy(). Kinda makes you think just how many bugs are out there that are this easy to spot.

Research Paper

2006-09-15T15:57:00.000-05:00

For the past three months I've been working on a research paper for my employer. The paper is about source code auditing. Basically I give a few examples of code which is flawed and give an explaination as to why it is flawed. The paper will be released publicly soon. When that happens I'll be sure to post up some links to it.

I'm also working on a complementary project for the paper. The plan is to create a tool which allows auditors to create function audit logs while they view source code. The idea is to create a web based application which interacts with a MySQL database and allows an auditor to create a project to work on. The auditors can then manage the project by specifying the source code they want to look at. While looking at the source code an auditor will have the ability to follow cross references and create function audit logs for any functions they deem necessary.

The cool thing about this project is that I'm incorporating a lot of cool features which are going to be extremely useful. Some of the cool things I plan on adding into the project is syntax highlighting, multiple programming language support, dynamic flow graph generation, a very cool code viewer utilizing CSS and Javascript (DHTML), automatic source code reversion capabilities. Yea thats a lot of features. I'll definately be posting some more on this subject as the project starts to shape up some more.

Currently the layout of the web application is complete and I've started to write some of the backend code which handles the majority of the MySQL database communication. About the only thing left is to start adding on the features listed above. I expect the project to take me about three months. At that time I should at the very least have a working demo for everyone to test out.

I really hope the tool is put to good use. It seems to me that a tool such as this is really what the source code auditing community has been needing for a long time. I know it likely won't be the perfect solution for some people but it should definately help. I am designing the tool to be as flexible as possible so that people can use it in just about anyway they could imagine.

First Post

2006-09-15T04:02:00.000-05:00

Well hello there. I'm known by most people within the computer security world as bannedit. I'm a Security Intelligence Engineer for a rather large company and I spend a lot of my time doing security related research. Mainly I enjoy writing exploit code for vulnerabilities and source code auditing. I hang out a lot on pulltheplug.org a site which hosts wargames which are interesting challenges for people interested in learning more about computer security.

I've been doing computer security research the majority of my life and I enjoy it. I like looking at code which is meant to be secure and finding flaws in it. I'm by no means a bad guy. Many people hear the term hacker and instantly think of the malicous hackers. Not all hackers are bad guys. Everything I do is legal and its how I make a living, doing what I love to do. When I discover a vulnerability in software I commonly report it to the vendor who created the software. I do this so that software can be fixed and in the end be more secure.

So hopefully you enjoy my blog. I intend on posting about some interesting subjects maybe a little about recent security issues and some information about what I'm working on. Hopefully this blog is considered to be educational to everyone at some point.