Should Vendors Close All Security Holes?

johnmeister writes to tell us that InfoWorld's Roger Grimes is finding it hard to completely discount a reader's argument to only patch minimum or low security bugs when they are publicly discovered. "The reader wrote to say that his company often sits on security bugs until they are publicly announced or until at least one customer complaint is made. Before you start disagreeing with this policy, hear out the rest of his argument. 'Our company spends significantly to root out security issues,' says the reader. 'We train all our programmers in secure coding, and we follow the basic tenets of secure programming design and management. When bugs are reported, we fix them. Any significant security bug that is likely to be high risk or widely used is also immediately fixed. But if we internally find a low- or medium-risk security bug, we often sit on the bug until it is reported publicly. We still research the bug and come up with tentative solutions, but we don't patch the problem.'"

Comments

i didn't rtfa

[flynt]

I did not RTFA, but I did read the summary. I did not hear his argument, I heard his conclusion repeated with more words.

Re:Should Vendors Close All Security Holes?

[eln]

Also, vendors should include a free pony with every software license they sell.

Closing all vulnerabilities is not practical. In any sufficiently complex piece of software, there will be bugs and security holes. Obviously, you need to close the nasty ones, but many of these exploits are not particularly high risk. In these cases, especially if the fix would involve a major redesign or other highly disruptive solution, it may be best to just leave them alone.

If, for example, the underlying design of your product allows for a minor, difficult to exploit security hole, it is probably not worth it to spend the time and money to redesign the product. More likely, your choices would be either a.) live with the (small) vulnerability, or b.) scrap the product entirely.

The decision to close a security hole should be dependent on the potential impact of the hole, the urgency of the issue (are there already exploits in the wild, for example), and how many resources (time and money) it will take to fix it.

The summary missed those parts.

[khasim]

Basically ...

#1. If we spend time fixing those bugs, we won't have as much time to fix the important bugs.

Translation: we put in so many bugs that we don't have time to fix them all.

#2. We give priority to any bugs that someone's leaked to the press.

Translation: we only fix it if you force us to.

#3. "Third, the additional bugs that external hackers find are commonly found by examining the patches we apply to our software."

I had to post that verbatim. They're releasing new bugs in their patches.

#4. "Fourth, every disclosed bug increases the pace of battle against the hackers."

Yeah, that one too. The more bugs they fix, the faster the .... what the fuck?

#5. If we don't announce it, they won't know about it.

Great. So your customers are at risk, but don't know it.

Re:The summary missed those parts.

[Lord_Slepnir]

I just don't think that the GP has ever worked on a large piece of software, or has worked in a business environment. Linux has some of the best minds in the world working on it, and it still has holes. Vista could have used a few more months being polished, but I can only imagine the threats of "Release now or else" coming from the headquarters.

Re:The summary missed those parts.

[SnapShot]

It could just reflect a realization that releasing a patch is as likely to introduce new bugs as it is to fix an existing bug. And, the patch identifies existing bugs which means that customers that don't install the patch are more vulnerable than they were before. Instead, you save up your fixes and your new features and your release new versions as a "dot release" and you reduce the number of versions out there in the wild. From a psychological standpoint your customers get new features and "updated security" instead of a never-ending series of security patches. Prioritization should go on behind the scenes, of course, so that the more critical fixes always make it into the latest release.

Now I'm off to read the article and see if my theories match up with their logic...

Re:Procrastination?

[The_Wilschon]

Low-risk does not mean easy to fix. Sometimes, a bug might be a very low-risk bug, but demand immense amounts of time to find and fix. For instance, sometimes I might be writing a program, and at some point, it begins crashing unpredictably, but very rarely. I know that there is a bug, but I have no idea what the trigger is, I have no idea which part of the code contains the bug, and I have no idea how to fix it. Since the MTBF is (say) 3 months, and (say) the code is not long-running (like a daemon or a kernel), it is probably not worth finding and fixing the bug.

Now, that's bugs, which is a wider category than security holes. So, suppose that instead of crashing, it very rarely and briefly enters a state in which a particular sequence of bytes sent to it via the net can cause it to execute arbitrary code. Furthermore, suppose the program should never be running as root, so the arbitrary code is nearly useless. This is a low risk security hole, and probably not worth patching.

Could take hundreds of man-hours to find the cause, and perhaps even longer to fix. Probability of ever seeing this exploited is very very low. Should it then be patched?

Downside to always patching

[drfuchs]

The article and responses miss an important point: patches of any kind are risky! And not just because they might introduce a new security flaw, but more generally because they may break some feature or another. In applications with millions of lines of code, and where the cost of doing a patch release amortized over all customers is millions of dollars, it can make lots of sense to just roll a fix into the next planned upgrade release. That way you get a complete Q/A and customer beta-test cycle to increase the confidence level of the fix.