Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Posted Sep 7, 2015 7:19 UTC (Mon) by roc (subscriber, #30627)In reply to: Mozilla: Improving Security for Bugzilla is the wrong angle by xophos
Parent article: Mozilla: Improving Security for Bugzilla
> me) that some bad guy had it first.
The important question is whether it's being exploited or not. Vulnerabilities are often warehoused. If someone finds it but we roll out a fix before they can use it, or sell it to someone who uses it, no harm done. It certainly would be interesting to know what that number is though.
> So any feature development, update cycles, deadlines etc. become irrelevant until this vulnerability is fixed.
Bad guys have vulnerabilities that aren't reported to us, too. Should we stop everything and look for them? Your logic seems to suggest we should, but that doesn't make sense.
> So first warn your users instantly and do a fix within 2-3 days (What do you have auto update for anyway?).
We do try to get a fix within a few days, especially if the bug is present in a shipping release. (AFAICT these days most security bugs are found in code that hasn't reached release yet, even with our short release cycle.) However, doing a browser update every few days or even once a week would be a ton of of work and a significant burden on our users, so if there's no sign of the bug being known in the wild, we'll bundle into the next update, which is at most six weeks away (three, on average). This is standard practice.
> If you can't do that (because the fix is complicated) disable the vulnerable functionality until you have a real fix.
Deliberately breaking random Web sites or apps every week (or six) is not a realistic option.
> If you can't do that, tell your users how to work around the vulnerability.
This would be ineffective for most users.
> If you can't do that, advise your users not to use the your software for X days, where X is the number of days after which you are sure to have a fix
> ready and deployed.
If every vendor followed your advice, there wouldn't be much software for people to use. Heartbleed -> turn off the Internet.
Your suggestions make some sense in the worst cases, e.g. when a public exploitation tool gets an exploit for some critical vulnerability. But when we have no reason to believe a vulnerability is circulating externally, extreme measures are a disservice to users.
Posted Sep 7, 2015 11:08 UTC (Mon)
by xophos (subscriber, #75267)
[Link] (20 responses)
Posted Sep 7, 2015 11:31 UTC (Mon)
by roc (subscriber, #30627)
[Link] (2 responses)
Posted Sep 7, 2015 14:55 UTC (Mon)
by xophos (subscriber, #75267)
[Link] (1 responses)
Posted Sep 7, 2015 23:08 UTC (Mon)
by roc (subscriber, #30627)
[Link]
Posted Sep 7, 2015 20:01 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (15 responses)
In which case, again, we might as well shut down the internet. To quote Knuth, "I have not tested it, I have merely proven it correct", and Einstein, "Insofar as maths refers to reality, it is not certain, and insofar as maths is certain, it has no relation to reality".
There are all sorts of ways of minimising bugs, but at the end of the day, there is NO WAY of being confident that any program is going to run as intended. As soon as hardware of any sort (electrical, human, mechanical) gets involved, THERE ARE NO GUARANTEES.
Cheers,
Posted Sep 8, 2015 5:02 UTC (Tue)
by xophos (subscriber, #75267)
[Link] (14 responses)
Posted Sep 8, 2015 8:06 UTC (Tue)
by ovitters (guest, #27950)
[Link]
PS: No need to press enter all the time. Paragraphs are cool! :-P
Posted Sep 8, 2015 17:05 UTC (Tue)
by zlynx (guest, #2285)
[Link]
Posted Sep 14, 2015 19:52 UTC (Mon)
by ballombe (subscriber, #9523)
[Link] (11 responses)
There are complex software with almost no bugs: TeX, IJG libjpeg, qmail
Posted Sep 14, 2015 23:20 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (10 responses)
The problem is that these programs weren't cleverly developed to be bug-free from the start – they started out just as buggy as all other programs, but were beaten on long enough for virtually all their bugs to be fixed (in the case of TeX, over 30 years by now). This approach is not very helpful if, like most people, you want to write your software and use (or sell) it right away.
Posted Sep 15, 2015 10:39 UTC (Tue)
by jezuch (subscriber, #52988)
[Link] (9 responses)
...and no new features added. That's the only way to bug-free software: 30 years of bug fixing + no new functionality, ever :)
Posted Sep 15, 2015 11:06 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link] (8 responses)
No, you can also use theorem provers. For example, there is already a bug free C compiler and a microkernel, http://compcert.inria.fr/compcert-C.html . The real problem is that perceived cost of using formal verification is considered way too high even for mission critical software. I wonder what kind of hacking attack it would take to change the balance cost.
Posted Sep 15, 2015 11:16 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (3 responses)
Of course the presumption there is that your formal specifications are bug-free. A verified implementation of a buggy specification isn't much better than a buggy implementation as far as the end result is concerned. C, for example, is probably still simple enough to lend itself to that sort of thing (although notably the authors of this compiler had to make do with a subset of the language). With something like TeX, things might look a bit different. Interactive programs, which are less easily described in terms of translating a well-specified language X into another well-specified language Y, are probably even more difficult.
Or, as Donald E. Knuth said, “Beware of bugs in the above code – I didn't try it, I only proved it correct” (as the author of TeX, he probably knows what he's talking about).
Posted Sep 15, 2015 11:52 UTC (Tue)
by ibukanov (subscriber, #3942)
[Link] (2 responses)
One does not need a detailed and inevitably complex formal specification to have a useful statement about the program. For example, proving that a C program does not have undefined behavior or that a user input is always properly escaped would be immediately useful even if that does not prevent bugs that could lead to denial-of-service. That is, the goal should not be to specify the detailed behavior, but rather the bounds of acceptable errors and then prove those bounds.
Posted Sep 16, 2015 6:10 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (1 responses)
Posted Sep 16, 2015 6:14 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
For example, for a train controller system, it's easy to come with an invariant "no trains on the same railway section" and even more elaborate like "a train must not approach a busy section with a speed more than 15 km/h".
Posted Sep 15, 2015 15:49 UTC (Tue)
by NAR (subscriber, #1313)
[Link] (3 responses)
"(transformation of C source text to CompCert C abstract syntax trees) is not formally verified"
So I think this is not a formally verified program that converts C source code into executable. Not surprisingly the hard part (handling user input) is missing. That's where most bugs are.
I remember CS class when I furiously tried to verify a practically "Hello World" level concurrent program and it took better part of the 90 minutes exam to achieve grade 2 (5 is best, 1 is failing). If I remember correctly, the avarage grade for the class on this particalar exam was below 2 - not because we were such lazy bastards who didn't study, but because it was hard and complicated. I knew the theory to pass the oral exam with grade 5, but computing the verification was really complicated even for a trivial task.
Posted Sep 16, 2015 8:16 UTC (Wed)
by cebewee (guest, #94775)
[Link] (2 responses)
Posted Sep 18, 2015 22:36 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Try and parse the following (legal!!!) statement in databasic
REM: REM = REM(10, 4); REM this calculates the remainder from dividing 10 by 4
That's a label, a variable, a function and a statement, all different, and all using the same identifier. (Incidentally, I don't know of a single compiler that correctly identifies all four - different implementations permit different syntaxes, but they are ALL valid.)
Now try providing a formal proof for a system that can cope with that ... :-)
Cheers,
Posted Sep 19, 2015 13:01 UTC (Sat)
by cebewee (guest, #94775)
[Link]
Posted Sep 8, 2015 7:02 UTC (Tue)
by oldtomas (guest, #72579)
[Link]
This sounds plausible if you assume that the users are the browser's primary customers. This is changing right in front of our eyes.
Chrome leads the pack, but it'd be naïve to assume the others won't follow (and you can see signs of it scattered across the last five to seven years or so).
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Wol
Mozilla: Improving Security for Bugzilla is the wrong angle
But it seems that the whole industry has their priorities backwards.
I know it makes economic sense: Users see new features, but they don't notice, when their computers are not owned by some stealthy malware.
Firefox crashes. It does this at least twice a week for me without using flash or other horrible plugins.
It does it even on android, where there are none of those.
I know that not all crashes are exploitable bugs, but they are more often than not.
Firefox doesn't need any more features. It doesen't need a new look. Heck it doesn't even need to go any faster.
The only thing that could make it better would be less bugs.
And when there are as few bugs in firefox as possible, as many unittests as possible, as much static checking of invariants as possible.
Then maybe html 6 or the next generation of ecmascript is out, and Feature development is needed for a short while.
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
but there is little interest in bug-free software.
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
From the linked article:
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle
Wol
Mozilla: Improving Security for Bugzilla is the wrong angle
Mozilla: Improving Security for Bugzilla is the wrong angle