Slashdot Mirror
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.'"
I did not RTFA, but I did read the summary. I did not hear his argument, I heard his conclusion repeated with more words.
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.
It could work as well as the normal method, but if it catches on, it will mostly be used as an excuse to not do anything until publicly shamed. Call me cynical.
Basically ...
.... what the fuck?
#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
#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.
Was not it GM, that lost millions of dollars a few years ago in a lawsuit brought by people (and their kin), whose car was rear-ended on a toll plaza and exploded in flames?
GM's arguments, that making the car's fuel-tank more protected was too expensive for the modicum of additional safety that would've provided, were — for better or worth — ignored by the jury...
In other words, you may not deem a security hole to be large compared with the expense of pushing out another patch, but if somebody gets hurt, and their lawyer subpoenas your internal e-mails on the subject, you may well be out of business.
In Soviet Washington the swamp drains you.
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?
SIGSEGV caught, terminating
wait... not that kind of sig.
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.
I'm shocked by how many people answer this with an unqualified "Yes." That's not realistic at all.
Here's an example. An app asks for your password. That password gets written to memory for a period of time. During that time, the page containing the password may get swapped to disk. The system may then crash or lose power, leaving the password on disk. I could then boot into another OS, read the swap file, and recover your password. Unlikely, but possible.
There, I "found" a security hole. Want to patch it? You could try to make every app that uses a password store it in wired (not swappable) memory - but performance will suffer (and good luck doing that in every app). You could also dynamically encrypt all data that gets written to the swap file, and decrypt it when read, at the cost of performance again.
Are you willing to trade performance in every app to defend against this mostly theoretical vulnerability? Probably not. Security is about tradeoffs. Welcome to the realities of software development.