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.