Why Can't Microsoft Just Patch Everything? 640
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."
Re:Seems like some people don't understand coding (Score:5, Informative)
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:Doesn't he know? (Score:2, Informative)
Do you have any sources to back up that statement? It sounds highly dubious as there was just a trojan that exploited an unpatch vulnerability reported earlier today [slashdot.org] on Slashdot. I find it very hard to believe that there have been no worms or viruses, *ever* to exploit an unfixed vulnerability.
Welcome to Corporate America (Score:2, Informative)
The reality of Corporate America, however, is based on quarterly results. Getting that next release out the door and being able to sell is everything. That means that all clean-up work (bugs, exploits, refactoring) will be prioritized along with new features and unless it's really critical will likely not get done for a long time, because they are lower priority since they bring no customer sales.
Unless and until those bugs affect the bottom-line, the company won't do a thing about them. A good recent example would be Sony's rootkit problem, which it turns out was pointed out to them before the public release on sysinternal's blog.
http://www.gloryhoundz.com/ [gloryhoundz.com]
Re:Mod parent up! (Score:5, Informative)
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 (Score:5, Informative)
$
You're Missing Something... (Score:5, Informative)
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) [mozilla.org]. (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 because they are so big. (Score:2, Informative)
There are programs that would run under 95/98/ME, but not on NT/2000/XP and vice versa. Those are competely different product lines that have nothing essensial in common.
Re:Mod parent up! (Score:5, Informative)
Re:It's all about "cute" data structures (Score:5, Informative)
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];
sprintf(buffer, fullAddress);
streetName = new char[strlen(buffer) + 1];
strcpy(streetName, buffer);
0;
0;
}
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.
Re:Good ole' 2002 (Score:3, Informative)
Write = 2
Execute = 1
0444 = Read by everyone
0111 = Execute by everyone
Re:Good ole' 2002 (Score:5, Informative)
As an example of the extra hurdle copying imposes, say you want to attack someone via a set of holes in Firefox. With /lib/ld-linux.so, you need only the following, if you can't make firefox itself do arbitrary things:
With out the ld-linux vector, you have to:
So it's not a huge hurdle, but it's there!
Dependecy hell (Score:3, Informative)
MS likes to pretend that windows is immune to such things, but the truth is every piece of software is interconnected. MS creates the illusion of no dependency problems by solving as much of it as possible behind closed doors, and wrapping the results in binary installers. The sheer amount of effort to resolve the problem is high
Re:Doesn't he know? (Score:2, Informative)
Re:Mod parent up! (Score:2, Informative)
If you were really Ring 0, then you could interupt, restart or kill programs running "SYSTEM" level privileges.
Re:Mod parent up! (Score:3, Informative)
An OS running privileged code is not a problem. The problem comes when that privileged code can execute arbitary code with the same privileges without any form of control or even indication that this is happening. A well engineered OS will be written to minimise the amount of code running with privs because of the amount of damage even a bug, let alone malware, can cause.
Any exploit that attacks the OS at the GUI level (which isn't hard to do with ActiveX) can pwn the system.
This makes ActiveX a design flaw.
Rewrite the OS to run as much of the GUI in userland as possible and take the performance hit and/or 'ease of use' hit.
The performance issue is not clear cut, moving code which handles arbitary input into "userland" means less of a need to check the input it also may be possible to get around any perfomance issues by writing more efficent code and having the core OS automatically load alternative binaries depending on the hardware type. Indeed considering the performance of modern hardware the code involved must be horribly inefficent in the first place...
I also don't understand how issues of structured codeing and good software engineering are directly relevent to how good the user interface is or is not.
Re:Mod parent up! (Score:1, Informative)
Microsoft said that IE was a central and integrated part of the "Windows Experience", not a critical part of the OS. (but since common people and the media don't understand the difference, they talk as if they were the same thing)
Re:It's all about "cute" data structures (Score:1, Informative)
Wrong. You evidently don't have much experience in old-school hardcore C programming. (Try reading the original implementation of TCP/IP for a sample)
The traditional way is to end the struct with char a[1], NOT char *a. That way you just allocate one big block of however much data is needed, cast it to the desired struct type, and store that for use. There is not a separate pointer variable inside the struct, which had to be allocated separated.