A tale of two patches, part 2

Apparently, some people think I chose a bad example yesterday to illustrate my point that patching complex software takes time. So maybe a different example will help.

This Secunia advisory from September 9, 2005 was rated “highly critical”:

Tom Ferris has discovered a vulnerability in Firefox, which can be exploited by malicious people to cause a DoS (Denial of Service) or to compromise a user’s system.

The vulnerability is caused due to an error in the handling of an IDN URLs that contains the 0xAD character in its domain name. This can be exploited to cause a heap-based buffer overflow.

Successful exploitation crashes Firefox and allows code execution but requires that the user is tricked into visiting a malicious web site or open a specially crafted HTML file.

NOTE: Exploit code is publicly available.

This Mozilla.org advisory offered a workaround that involved disabling the IDN functionality

On September 6 a security vulnerability affecting all versions of Mozilla Firefox and the Mozilla Suite was reported to Mozilla by Tom Ferris and on September 8th was publicly disclosed.

On September 9, the Mozilla team released a configuration change which, as a temporary measure to work around this problem, disables IDN in the browser. IDN functionality will be restored in a future product update. The fix is either a manual configuration change or a small download which will make this configuration change for the user.

Sound familiar? That’s exactly how Microsoft initially responded to the WMF exploit.

The patch for this vulnerability (and remember, there was working exploit code out there) was incorporated into Firefox 1.0.7, which was released 12 days later, on September 21.

I’m not trying to “smear the Open Source community.” In fact, I’m an enthusiastic Firefox user and supporter. In the September 9 vulnerability, I don’t think that the Firefox developers were underestimating the problem, nor were they sitting on a patch. The process took 12 days, period. I don’t think the Windows security team was sitting on the WMF exploit either. The process of developing and testing a fix takes time. That’s true of any complex program, including Firefox and Windows.

4 thoughts on “A tale of two patches, part 2

  1. Pingback: The PC Doctor
  2. Just give up Ed, the zealots are going to twist your words one way or another. It’s why we keep them around – such unrestrained passion is what gets amazing programs like Firefox developed and pushes them to the masses. Unfortunately, it’s also one of the least enjoyable qualities of these people. They’re always ready to jump on someone with a different viewpoint, even when that person has nothing but the best of intentions.

    Just admit defeat and move along. In the end, it’ll be better for all of us… 🙂

  3. We’ll have to agree to disagree on this Ed.

    My position is simply this: the WMF vulnerability was not an obscure buffer overflow issue. It was actually a FEATURE inserted in to the WMF file processing to handle errors. This feature is why remote code was executed. Ilfak’s fix was to simply disable that feature.

    It was the most expedient thing he could do in the face of a zero-day exploit in progress and NO SOURCE CODE.

    Granted, there were some WMF files which relied on the escape sequence when errors cropped up. However, Ilfak’s fix didn’t beyond disabling that capability BECAUSE HE DIDN’T HAVE THE SOURCE CODE. It should have been relatively simple to work on this to someone WITH source code.

    Other open source software flaws that you cited were not discovered as zero day exploits. They were reported publicly. To some misinformed security firms that’s the same as “exploit in the wild”.

    And in the end, Microsoft did testing on HOW many platforms? Let’s see: 2000 SP4, XP SP2, XP SP2 64 bit, and 2003 server with 32 and 64 bit versions. How many flavors did they have to test here and how much time should it have taken? Contrast that with the hundeds of flavors of various operating systems in Open Source. You’re comparing a relatively small set of OS flavors with literally hundreds of different implentations of Open Source kernels…

    Let me make one thing clear: The many eyes theory of open source code doesn’t always ferret out faulty source code in advance. However, when a vulnerability becomes known, the many eyes theory works extremely well. So, while overall reliability may not be any better, the response time usually is. How much better?

    In the Microsoft world, we have the Microsoft managers. A problem gets as much attention as the Managers decide to give it. If you check E-Eye (http://www.eeye.com/html/research/upcoming/index.html) you’ll see that there are some serious problems which have been reported to Microsoft and the fixes are WAY overdue. This has been standard behavior from Microsoft for the last three years I’ve been watching this list.

    Now in fairness, as you said, they want to make a fix that works the first time. But clearly they’re in over their heads to have this many exploits of this severity lurking around for this long.

    The bottom line is this: Given that we can’t see the code to fix it for ourselves, how much trust should we invest in Microsoft’s assessment of their own product’s vulnerabilities? If the data from E-eye is anything to go on, we ought to take a very careful look at this.

    Please understand, I use Microsoft products. I specify them. They have their strengths (ease of use and very broad hardware support) and their weaknesses (security, even when it exists is still mostly a cultural afterthought).

    Right now, as security problems linger longer and longer I have a huge problem when exposing a mission critical Microsoft computer to the Internet. I have to firewall it and lock it down to just the ports it needs. Contrast that to a ‘BSD OS.

    And the funny thing is that Microsoft actually uses an early version of the BSD TCP/IP code in their OS. Apparently they forgot to update it…

  4. AB3A, I would think that you’re on rather thin ice with your reference to the eEye Windows vulnerability list. This list is a major selling point for the company products – which means that to be frank, it is in their interest to make this list as long and frightening as possible. Without taking the time to look into it, I cannot be sure – but I haven’t found any details about the exploits they’re listing.

    Just as with Microsoft, any company’s viewpoint on their own and others’ products must be taken with a whole bushel full of salt – perhaps even more so in this case, when the viewpoint on Microsoft products forms the selling pitch…

Comments are closed.