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.
Yes.
Short answer no with a maybe.
We still research the bug and come up with tentative solutions, but we don't patch the problem. I can understand the point if it's to save time and money for other things, but if they are going to find a solution to the problem and time/money is already spent, then that is completely wasted if it isn't utilized. Plus you're risking the data by not closing a known hole or bug. Doesnt make sense.
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.
Yup, it's not about quality software, it's about money. Hardly anyone makes software anymore because they want to or because they like making quality software...they'll just do the bare minimum they can to maximize profit.
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.
Examples:
Not likely to be fixed completely - In some ways, Windows is a security hole
Could be fixed if escalates - password strength and use
Should be fixed - Lack of any authorization requirements etc.
If you remember the Pinto car-b-ques, there is a money factor to think about. Since most standard computing systems are not life-critical, some bugs can be left for later. Some bugs you might know about but they are not in your code such as those shipped with the networking stack of the RTOS that you use for an embedded product. An insecure FTP client on an embedded machine that has no access to other machines or sensitive material is not terribly bad.
On the other hand, if the machine can be compromised and allow the attacker access to other machines... that needs to be fixed.
Support NYCountryLawyer RIAA vs People
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.
The one you hope for: Someone finds and public announces a problem. You team looks "quick to act" deploys a solution.
That other one: Someone exploits the bug to a degree you and your team never considered and your user community is devastated.
all known security bugs should be fixed, but low-risk non-public ones can be low priority. we cant expect any vendor to send a patch each and every time they find a security bug, but once they find one the next version they release damn well better have it patched.
I could see not waiting till your next regular patch, so as to avoid bringing it to the attention of the hackers.
But the rest of his arguments are pretty crappy.
excitingthingstodo.blogspot.com
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.
IANAL, but if a company suffers a significant financial loss due to a bug that the vendor knew about but did not patch, does that not open them up for big time law suits?
"Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
Besides, aren't there liability issues with knowingly shipping a product with undisclosed defects?
The fix the problem as soon as they discover it. The next release of the product does not have the problem. If the
problem becomes public before the next release, then they immediately issue the patch for it and hope that people
patch.
As long as they release often enough that the fixes are largely in place before the problems are found, I have no
issue with this. It actually seems responsible since it posses less risk to the customers that are slow in patching
their systems that the alternative.
*sigh* back to work...
Are you willing to indemnify your users for any and all losses suffered by them due to a flaw/bug which you knew about but chose not to patch? If not, then patch it!
'The tyrant will always find pretext for his tyranny.' - Aesop's Fables
The problem is that if you've discovered a security hole; chances are someone else has as well. Just because a problem hasn't been reported to your company doesn't mean that it is unknown.
History shows that there are lots of black hats that will sit on security breaches/expploits/bugs/etc and exploit them for their own end rather then reporting them to a company. Breaches in security should be patched as soon as they are discovered. If 1 person found the bug/hole/exploit/whatever, that means another person can find it as well. There's nothing there about having to report it to a vendor once found by either person.
One of these days i'm going to find this 'peer' guy and reset HIS connection!
Not that simple. Developing a patch does not fix a security hole. Releasing a patch does not fix a security hole. Applying a patch fixes a security hole, if all goes well. When you combine the fact that the number of holes in existence is multiplied by the number of installations, with the fact that the development team very rarely has any power over when patches are actually applied, security through obscurity doesn't look so cut-and-dried naïve versus publicizing your holes by releasing patches.
Notice that the person who posted the argument in the article never said they leave holes unpatched to save "a few hours of time". He didn't say they left holes unpatched at all. He said that they prioritized based on severity and publicity—who wouldn't? And he said that patches for unknown holes were developed, tested, and not released until they were needed. This gives them the advantage of not alerting the malicious user community that there are holes they can exploit if they act more quickly than the users who have to apply the patches. But it also means that when the time comes for them to release the patch, they know it's been patiently tested, not kneejerked out the door. I'd rather have no patch for an unknown hole that's not likely to be exploited than a patch that's going to make my software buggy.
The only downside to this is that you have to trust the developers to correctly assess the risk of leaving unknown holes unpatched. If they think a hole is unlikely to be randomly spotted and will only do minimal damage if it is, but script kiddies spot it in a week and manage to get remote root access from it, yes they screwed up by not patching it right away. Mistakes like that can be made the same way the mistakes that created the hole in the first place were made. But you have to make such judgments just to prioritize the holes, regardless of what you intend to do with them. And there certainly isn't anybody more qualified to make those judgments than the developers who discovered the hole.
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.
You know something, I was planning on rebutting, but you're entirely correct. But you make it sound like a bad thing. Some of our clients are educated and experienced in the technical world. Many of them choose to see the forest from above -- and so they demand a taller tree first.
When given the option between a week of effort to fix a security hole (for free), or a week of effort to build a new feature (for cost), not all but most of our clients prefer the latter. They would rather grow their business (even on an unstable balancing act) than safe-guard their business. And all the advice in the world doesn't seem to be able to change that.
I guess it's the typical/traditional backup advice. I have yet to meet a client that is willing to spend the time and effort to develop a reliable backup routine (not even a restoration routine). They'd rather run the risk of losing all of their data, and dealing with the headaches and fall-out, than to spend money to prevent something that may never occur.
I can respect that -- hell I make the same decisions every day. And sometimes I even make those decisions with other people's data. But that's the very same risk/reward decision that every business entrepeneur makes. So in the grand scheme of things, I guess it's insignificant compared to most of the other decisions in running a business.
Just off the top of my head, I'd say that firing an employee is a bigger risk than worrying about hard drive failures.
I don't know where you work but I can tell from your focus on secure coding that you have never worked for Microsoft.
"Buffer overflows are never a problem, because I assume that all incoming data from ANY source should be treated as if it were pure Ebola virus. I assume nothing, even if the protocol / file header is of a certain type."
You don't trust data being passed even internally? Ever? Doesn't all of the redundant checking hurt speed and efficiency? What if it is part of a loop being called thousands of times?
Wow, what's it like to live in a world where everything's black and white? ;)
But seriously, anyone, and I mean anyone, who's worked with a large program (depending on the language you use, over 10,000 lines) knows that you can't change code without the risk of unintended consequences. If a small security hole requires a large rewrite, it's nearly 100% guaranteed to introduce new bugs and security holes.
And if you rtfa you'd realize that the person has real numbers to back up the fact that most exploits are used after the patch is released and the details are public.
Finally, the argument that the company should do what's best for the consumer is bullshit. Profits drive business, everything dealing with the software should boost the bottom line somehow. If you want people to program something for the pure joy of programming, use open source, otherwise you're buying from a business and you have to deal with the downsides of businesses.
Proper planning, good design, code reviews, and disciplined testing is all you need.
Unfortunately there seems to be very few companies willing to budget (in time or resources) for any more than two of these, let alone all four. And even more unfortunately, the past 40 years of commercial software seem to suggest that such miserliness has been a profitable decision.
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.