Why Can't Microsoft Just Patch Everything?

paneraboy writes "If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks, why can't Microsoft -- with its massive army of programmers and massive budget -- patch all of its vulnerabilities? Had Microsoft fixed a low risk browser vulnerability six months ago, perhaps we could have avoided last week's zero-day exploit. Currently, more than two dozen Windows XP issues remain unpatched. Ou thinks Microsoft ought to fix them all." From the article: "Almost 4 years after the launch of Trustworthy Computing, I found myself wondering why am I staying up till 4:00 AM to deliver an emergency set of instructions (Home and Enterprise) to my readers because Microsoft felt it unnecessary to patch a flaw six months ago that was originally low risk but mutated in to something extremely dangerous."

Comments

Re:Seems like some people don't understand coding

[cnelzie]

Of course, if the base design philosophy is flawed to begin with, even if they could "patch everything" the would likely be better off rewriting from the ground up.

    Many components of Windows and MS Software on Windows utilized Remote Procedure Calls, even if the applications are on the same exact system. This is inherently flawed, as shown in many past MS Windows exploits. Just look at the MS-SQL expoits as perfect examples.

    If designed with security, instead of "ease of coding" was the design from the start, RPC wouldn't be used for communication between processes on the exact same piece of hardware. This is how it is done with MySQL and Apache on Linux and why RPC exploits won't work if those services are running on the exact same hardware.

    The list of flawed design decisions that went into Windows at the very beginning continue to haunt the Windows Operating System to this day. No, I am not some blind unqualified moron making these statements, I manage Windows desktops for a living, used to work full time with Windows Servers and one of my hobbies has been looking into OS architecture design and how it relates to system security.

Re:Mod parent up!

[cnelzie]

Well, ActiveX was really initially designed to not only "kill" Java (which didn't work), but also to attempt to lock everyone into using Windows running PCs for using the Internet. (Thank whatever belief system you have that didn't work.)

    By tying ActiveX so tightly into the OS, they not only succeeded in making ActiveX an almost required component of any Windows Installation, they also knee-capped themselves in regards to handling security. Unless it is seperated from OS, ActiveX will always be a threat to the security of a Windows PC.

Re:Good ole' 2002

[Tony Hoyle]

That problem was fixed, um... 4 years ago?

$ /lib/ld-linux.so.2 ./test ./test: error while loading shared libraries: ./test: failed to map segment from shared object: Operation not permitted

You're Missing Something...

[abscondment]

Note the vast majority of "bugs" in bugzilla that are labeled "enh" --> those ones are enhancements that users would like to see.

Instead of counting against Mozilla, the fact that they allow so much user input is a great OSS feature.

No one said OSS was free of bugs. Since end users are allowed to submit bugs, the only ones that should be counted are those that are confirmed.

Try the following list: bugs that are in Firefox, not marked "enh", and have an action priority (P1-P5). (note: copy/paste link since bugzilla refuses connectiosn referred by /.)

Only 179 bugs. Sure, those are only the ones that the Mozilla team deem necessary to work on; however, we've seen from their reactions with 1.06 -> 1.07 that they are very quick on figuring out what's important and patching it quickly. Sure, that's a lot of unpatched bugs. But: that list is publicly available. Any researcher can go in and say, "hmmm.... let's find the security flaws that Mozilla has left unpatched". And they do, trust me; the thing is, the Firefox team patches the bugs that cause security flaws. Other ones are cosmetic, user interaction, or feature-based in nature. They still appear as "bugs", even though they don't pose a security threat.

The issue is not that OSS has no bugs - that's an obvious farce. The issue is that Microsoft first misdiagnosed a critical bug, and then left it unpatched for 6 months and counting. The Firefox team consistently finds those bugs that do pose a threat, and they leave the work they do open and transparent so that security researcheres can check up on what happens. Microsoft - let's put it thise way: if security researchers never found the flaws in Microsoft's programs, Microsoft would save money and increase efficiency by not fixing them.

Re:It's all about "cute" data structures

[daVinci1980]

Insightful? Clearly moderated by people who don't code for a living.

Okay, first off, your code (as mentioned by the other poster) isn't legal C or C++. But let's fix it and discuss it how I'm sure you *meant*.

So here's the correct code:

struct foo {
        int length;
        char* buffer;
};


Now then, you argue that this is problematic because it's allocated dynamically, based on what someone else told me the size was.

Actually, this struct doesn't appear in the Win32 or the MFC API anywhere (nor does anything that looks significantly like it), but more importantly, this kind of struct will *never* be a problem. Let's consider all of the cases:

1) length is too large to allocate a buffer for. The code throws a bad_alloc exception when buffer = new char[length] is called.
2) length is negative. new takes unsigned integers for allocation, so the value is actually very large and positive. The bad_alloc will be thrown in this case too.
3) length is zero. I get a pointer to memory that is 0 bytes long.
4) length is valid. We allocate a proper amount of space and away we go.

Let's assume for a second though that someone gives me the buffer pointer *and* the length.
1) length is the correct size (no issue).
2) length is too small for the buffer (no issue, but I am wasting memory).
1) length is larger than buffer actually is long. I write out of bounds, but in the heap. This will likely result in a crash, but NOT in an exploit. This struct could be anywhere in memory, but it will not overwrite the stack, which would be necessary to execute arbitrary code.

Buffer overflows are only a problem when the buffer exists on the stack. In the heap, buffer overflows will result in a crash, or possibly undefined behavior. But on the modern PC, it would be impossible to use a buffer overflow in the heap to reliably execute arbitrary code.. Unless the coder in question was doing something really, really stupid (like executing code from an arbitrary instruction buffer in their structure, which you conveniently just overwrote). Fortunately for us, MS does not do anything of that nature.

For reference, buffer overflows occur when someone does something like this:


void GetAddress(char *& streetName, char* fullAddress)
{
        char buffer[25]; // No one will ever give us input longer than this!
        sprintf(buffer, fullAddress); // Possible overflow
        streetName = new char[strlen(buffer) + 1];
        strcpy(streetName, buffer);

        0; // Improved : sprintf(buffer, "%s", fullAddress);
        0; // More Improved : snprintf(buffer, 25, "%s", fullAddress);
}

But the best would've been to do it like this:


void GetAddress(char *& streetName, char* fullAddress)
{
        int requiredBufferSize = snprintf(0, 0, "%s", fullAddress) + 1;
        streetName = new char[requiredBufferSize];
        snprintf(streetName, requiredBufferSize, "%s", fullAddress);
}


Or to not use C style reading at all.