Blog powered by Typepad
Member since 07/2003

« That's service! | Main | Alberta's gemstone. »



Tee hee...the Goddess & Greg are tag team blogging.

Robert, thanks very much for the view from the inside looking out. I guess I have a little more insight into how this stuff keeps getting past Microsoft, but I still think they should have taken Bruce's suggestion seriously. Buffy the buffer slayer...ohh, I smell sequel!

Greg, I'm going to address your comments about going entirely opensource in a full post, but I'd like to ask you... With the demise of Netscape, but Mozilla going like gangbusters, do you think Microsoft can really afford to go that long without a freestanding browser upgrade without opensource eating their lunch? Maybe that'd be a good thing though, and a standards-based browser will get a really strong foothold before MS gets any competition ready.

I mean, let's face it, there are a lot of really useful features in other browsers that MS needs to implement, never mind dealing with the standards issue. I just don't think an improved (?) browser will be enough reason for anyone to buy a new OS.


Bruce Kratofil

Microsoft will continue to drag it's feet and delay releasing patches because they KNOW they have the consumer by the computing balls.
Microsoft has already announced that the next best thing to a bug fix for Windows is the next version of Windows (aka "Longhorn").
MS knows that people will pay for the upgrade.
Internet Explorer 6 SP1 is the last 'stand alone' version of the browser. The next version (7?) will be released as part of Longhorn - and that is about 5 years away... sad thing is that people will wait. Ballmer said that any improvements to the OS or browser will be integral to each other (so much for the DOJ rulings).
Linux is already a threat to Microsoft and they know it. - MS has lost that battle, even though they really tried.
Linux already is a viable alternative.
I have used it and FreeBSD 100% since 1996.
EVERYTHING I did under windows I do under Linux - web browsing (Mozilla, Opera) word processing/spread sheets (, cd burning (XCDRoast), mp3 playing (xmms), movie (online and DVD) watching (mplayer/xmms). You name it, there IS a way to do it with Linux.
Just go through my old entries, or visit my linux page (all linked on my main page).
The only reason people don't THINK there is an alternative to Windows is because they DON'T THINK, period or they accept shoddy work as the only way to do business.

Sorry, I don't usually do a mini-blog post in other people's blogs. :/

Da Goddess

Sending the geek boyfriend over here to discuss this with you as I type.....

Robert Poole

What it boils down to is poor coding methodology. It's almost impossible to catch every single bug, no matter what methodology you use, but clearly Microsoft employed some rather naive assumptions about certain arguments to system function calls (in their case, calls to Win32 API functions). Some of these same naive assumptions are present in older UNIX code, stuff that's over a decade old in many cases. (Many implementations of the POSIX API have similar problems.)

The fundamental issue is that much of this code is written in languages like C and C++, and these languages give you plenty of ways to shoot yourself in the foot, because they allow pointer arithmetic, and they allow you to do things like point to memory your application doesn't actually own. To compound the problem, strings (as handled in C and C++) are arrays of characters, either statically or dynamically allocated. There's nothing indicating how many bytes of memory actually belong to a string, so strings are terminated with a null character (a character with a value of 0).

Most programmers up til now have simply either statically allocated a fairly large chunk of memory to create a buffer for a string, or else they dynamically allocate a fixed amount of memory at run time. Either way, the buffer has a finite size. The problem comes in when certain checks are not put in place to enforce the restriction of not writing past the beginning or end of a block of memory. It isn't necessarily laziness -- 99% of the time, the buffer is so big that falling off the end of it isn't going to happen.

In Mac OS X or Windows, there appear to be upper limits on how much text a password field or other text field can hold, and the default is a fairly large value. In some cases, the amount of data a GUI widget can hold is much larger than the buffer allocated by the underlying code to hold the result, hence the exploits that involve flooding/overflowing the buffer. You may recall there was a recent exploit in Mac OS X that allowed a user to break password protected screen savers and the login panel.

It's a simple matter of putting a few comparisons in to limit how much data gets copied from one buffer to another, for example. But when you consider how many times a typical piece of system software has to manipulate or otherwise handle strings, the amount of extra checking code suddenly looks a bit more daunting.

The real solution is to use a more object oriented approach which encapsulates all string functionality into an object which does every conceivable sanity check each and every time. But owing to the huge amount of legacy C and assembly code out there, and the need to inter-operate with it, there will always be situations where an OO approach won't save you.

I know that many Carbon API calls in OS X (and many Win32 API calls in Windows) use a Pascal calling convention, where strings are converted from C-style to Pascal-style. Pascal style strings aren't terminated with a null character; rather, the beginning of the string in memory is an integer value (stored in 1, 2, or 4 bytes) indicating the length of the remainder of the string. You'd think this would be a bit safer, and it would if you were using Pascal as your programming language. The unfortunate fact is, almost all of these API calls immediately convert the Pascal-style string back to a C-style string internally. (The reason for using Pascal-style strings in the first case, and the Pascal function calling convention in general, has to do with the way the original Mac Toolbox was written -- it was originally written entirely in Pascal, then later re-coded in C for speed, with the function calls retaining their Pascal heritage so someone could run old legacy code from 1984 and still have it work correctly.)

Microsoft has two problems working against it. First, they tend to hire young programmers fresh out of college, ostensibly so they haven't been "tainted" by methodologies and expectations of the rest of the industry. This makes them easier to mold as Microsoft sees fit, but it has the down side of creating a workforce lacking in seasoned programmers who'd know how to avoid these kinds of programming gotchas. Second, Microsoft has a lot of inertia as a company; they steadfastly adhere to internal standards and practices that have long been discredited or fallen out of favor in the rest of the world. (Case in point, Microsoft still AFAIK advocates the use of Hungarian notation for variable names, even though modern type safe languages such as C++ make it unnecessary, and most critics of Hungarian notation rightly point out that it can sabotage the maintainability of code.)

The end result seems to be that Microsoft code has a tendency to look like itself (or other Microsoft code, to be less cutesy) an awful lot; so a lazy/sloppy piece of code written in one place in the deep dark past has a good chance of having been copied or mimicked in another piece of code elsewhere. Therefore, it's not surprising that there is a lot of unsafe code lurking in Windows which does not properly check buffer limits, or only checks some things and not others.

Before the Internet gave a potential TCP/IP socket to every user on the planet, the code was written to be fast and efficient, so "superfluous" checks were excised from a lot of code (or never added in the first place) in the name of speed. As the number of users on the net increased, and as the kind of users changed from academic/business/military to commercial/unbounded, the number and kind of malicious users skyrocketed. Suddenly, code that nobody thought would be an issue is becoming targeted by black-hat hackers everywhere.

The fact remains, though, that buffer overflow exploits are potentially a lot more dangerous in Windows than in UNIX-like operating systems, because in Windows you have Win32 API calls that can be executed arbitrarily by any piece of software and can gain total access to the OS and everything it encompasses, regardless of what privileges that software started out with. (There's one API call which is a huge security risk because it allows any application to send a Windows event/message to any other running application, forcing the running application to execute arbitrary code with whatever privileges the application happens to have.) Buffer overflow exploits make it easy to force a remote system to execute arbitrary code if crafted correctly. You don't need to be a genius to figure out that putting these two things together spells disaster.

We're going to continue seeing more and more asinine exploits cropping up in Windows, whereas open-source operating systems (such as the Darwin infrastructure of Mac OS X, as well as *BSD and Linux) have the benefit of massive peer review, so most of the potential problems get discovered and dealt with quickly. I'm sure you've heard this before, but it bears repeating: Security through obscurity is not security. The NSA knows this, which is why the only trusted cryptographic cyphers are ones that are published and extensively tested and examined by theorists as well as the white-hat hacker community. Source code should be treated no differently.


Will & Tony:

Thanks for your observations guys!

While I can appreciate what you're saying about the complexity of the code and the process, I still don't understand why the same mistake keeps getting past them! I mean, how hard is it to remeber to test for a buffer overrun error in every finished piece of code before it's released? And that's not a rhetorical question. I'm honestly curious to know why that hasn't been implemented as the most basic quality control item. They've had hundreds of these errors. Shouldn't it be standard procedure to change the way they implement buffers? Or does each use of a buffer utilize different coding and approach?

I mean, if I'd sold 100 photographs and 80 of them came back for exposure correction? I'd be damn sure to double check my exposure everytime I took a shot from then on.

Or if I'd written 100 articles, and spelled the same word wrong in 80 of them? Then the last thing I'd do before submitting every future article would be to scan it for that word, and make certain it was correct each time.

I do understand that there's no way every flaw can be caught. But it seems this one is practically sitting up and waving a red flag and they're intentionally ignoring it! They have been shown right where to look over and over, and still keep right on issuing new software with the same bug. I mean cripes; the bug announced in DirectX infects 5 or 6 generations!

Sorry, it just literally boggles my mind that MS could keep allowing the same mistake to be made after years of having to go back & fix it. If you can fix it after the fact, you can just put in the little extra effort & fix it before release. That's how I see it anyway.

Other opinions (or explanations)?


So far this year you are spot-on. There have been 26 patches to Windows for security issues in almost as many weeks. In comparison Mac OS X has had 5. (see my note on this at Kookaburra weblog )

I don't think Microsoft are stupid - it just looks that way. Windows is a huge piece of code. Windows XP is 45+ million lines of code. Windows 95 was under 5 million lines of code and had over 3000 defects.

If the focus has been on new code rather than fixing code it is to be expected that absolute defects have grown with the code base. So that would equate to 27000 defects!

Integrating the browser with the OS was a bad move from a security perspective - it helped win the Browser wars for Microsoft though.

Being focussed on high backward compatibility also hurts. It all comes down to an increasingly complex OS for which the focus has been on new features over enhanced stablity. Microsoft's 'trustworthy computing initiative' is an attempt to address that. It seems to have been prompted by corporations staying with Windows 2000 or switching to various *nixes. We are unlikely to see major progress on Microsoft OS security until Longhorn (2005). In the meantime stay on top of your patches or switch to something else.

Will Leshner

I think the problem is that they have literally thousands of programmers banging on their code. I certainly have no love for Microsoft. Heck, I'm a Mac guy. But as a programmer, I can kind of understand the problem. I just can't understand why any company would choose a Windows-based server product over, say, a UNIX or Linux based product.

The comments to this entry are closed.