Sorry for going at Microsoft again in my second blog post here, but since the text was already written mostly, it's something I can easily add 
Buffer overflows are a very typical source of security problems, emerging from a bit of carelessness on side of software developers. Buffers are areas of memory, used for example to contain text, and C [a computer language] developers need to take extra care to always manage their maximum length when handling them, since by nature, they're only limited by the first "zero" character.
See the problem? You have the text Hello World, which has 11 letters. Add one zero character (not the "0" you know, but an internal value 0), and the computer will know the text ends at the d. Forget to reserve that 12th letter or copy something longer than 11 letters, ignore the length, and you've got a problem, since the computer will continue to read text somewhere in memory that's beyond the area you've reserved for use for this text.
I might blog about that topic from a developers point later, for now, I wanted to make public such a buffer overflow in Microsofts Internet Explorer 7, which I first reported to Microsoft on November 4th, 2006 (receipt was confirmed), and which still has not been fixed. Yes, that's 19 months now, and I stopped thinking it would get fixed without public awareness of the bug. So here's a report of the buffer overflow, as sent to Microsoft (a bit reformatted for the blogs vBCode of course).
Summary:
When manipulating a registry value, a buffer overflow can be provoked.
Symptoms:
Random tabs, random text on options dialog, crash on exit.
Details:
By removing the terminating zero bytes, the size of the buffer previously allocated seems to overflow into otherwise used memory.
The reason for this problem seems to be based on the fact that while any application can read the size of a registry key, IE seems to make use of this only to determine the size of the buffer to allocate, but depends on a correct termination to actually stay inside this buffer. Missing consideration of string lengths is a very typical reason for buffer overflow problems.
Steps to reproduce:
At this point, you may notice either one or more of these:
Affected versions:
Danger:
I have not tried to exploit this, and I don't see any malware doing this as well, since it would probably need further registry manipulations and lead to no further privileges than those that must alread exist to use it. The issues only implication would be crashes.
So, while the possible danger of this bug alone has a tendency to be non-existent, the background would be that Microsoft does not see a necessity to fix a type of software bug that is a very common source of situations where software gets exploitable.
From a developers standpoint, there should never be a policy of ignoring a buffer overflow because it is unlikely to cause harm, as done by Microsoft here.
Buffer overflows are a very typical source of security problems, emerging from a bit of carelessness on side of software developers. Buffers are areas of memory, used for example to contain text, and C [a computer language] developers need to take extra care to always manage their maximum length when handling them, since by nature, they're only limited by the first "zero" character.
See the problem? You have the text Hello World, which has 11 letters. Add one zero character (not the "0" you know, but an internal value 0), and the computer will know the text ends at the d. Forget to reserve that 12th letter or copy something longer than 11 letters, ignore the length, and you've got a problem, since the computer will continue to read text somewhere in memory that's beyond the area you've reserved for use for this text.
I might blog about that topic from a developers point later, for now, I wanted to make public such a buffer overflow in Microsofts Internet Explorer 7, which I first reported to Microsoft on November 4th, 2006 (receipt was confirmed), and which still has not been fixed. Yes, that's 19 months now, and I stopped thinking it would get fixed without public awareness of the bug. So here's a report of the buffer overflow, as sent to Microsoft (a bit reformatted for the blogs vBCode of course).
Summary:
When manipulating a registry value, a buffer overflow can be provoked.
Symptoms:
Random tabs, random text on options dialog, crash on exit.
Details:
By removing the terminating zero bytes, the size of the buffer previously allocated seems to overflow into otherwise used memory.
The reason for this problem seems to be based on the fact that while any application can read the size of a registry key, IE seems to make use of this only to determine the size of the buffer to allocate, but depends on a correct termination to actually stay inside this buffer. Missing consideration of string lengths is a very typical reason for buffer overflow problems.
Steps to reproduce:
- Run Internet Explorer (or use ie7-reg_multi_sz-bug.reg and jump to #10).
- Open menu Tools -> Internet Options.
- Enter a bunch of startpages, in this example
http://www.google.com/
http://www.altavista.com/
http://www.yahoo.com/ - Press OK and close IE.
- Run regedit.exe.
- Navigate to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\.
- Right-click Secondary Start Pages and select Modify Binary Data.
- Delete the two last \0 bytes (see ie7-reg_multi_sz-bug.png).
- Press OK and leave regedit.exe.
- Run Internet Explorer again.
- Take a look at the startpage list in the Internet Options.
- Close IE.
At this point, you may notice either one or more of these:
- More tabs opening on step 10, with random names like http://tp/ or http://0.0.0.4/ or whatever seems to be in memory (often only on second or third start of IE in a row).
- On the Internet Options panel in step 11, see anything from random text yahoo.com to real other domains.
- On exit (step 12), Internet Explorer is now throwing an "unknown software exception 0xc0000005 at address 0x03cc4026)" and/or a "Runtime error 216 at 0x03cc4026" (reproduced this on 7.0.5730.11 only).
Affected versions:
- 7.0.5730.13 (XP Pro x64 download version, both 32 and 64 bit)
- 7.0.5730.11 (XP Pro x64 download version, both 32 and 64 bit)
- 7.0.5744.16384 (from Vista x64 RC2 download, both 32 and 64 bit)
- Other versions were not tested, but likely the same; the problem was retested and verified about monthly, last time April 4th, 2008.
Danger:
I have not tried to exploit this, and I don't see any malware doing this as well, since it would probably need further registry manipulations and lead to no further privileges than those that must alread exist to use it. The issues only implication would be crashes.
So, while the possible danger of this bug alone has a tendency to be non-existent, the background would be that Microsoft does not see a necessity to fix a type of software bug that is a very common source of situations where software gets exploitable.
From a developers standpoint, there should never be a policy of ignoring a buffer overflow because it is unlikely to cause harm, as done by Microsoft here.
