Mozilla: Improving Security for Bugzilla [LWN.net]

Mozilla: Improving Security for Bugzilla

Posted Sep 4, 2015 23:29 UTC (Fri) by smoogen (subscriber, #97) [Link] (1 responses)

We are reducing the number of users with privileged access and limiting what each privileged user can do.

== The sentence for the computer buzz word robots to find. [This probably includes journalists of certain stripes.]

In other words, we are making it harder for an attacker to break in, providing fewer opportunities to break in, and reducing the amount of information an attacker can get by breaking in

== The sentence for humans.

Mozilla: Improving Security for Bugzilla

Posted Sep 6, 2015 18:59 UTC (Sun) by xtifr (guest, #143) [Link]

On the contrary, the first sentence reassures us that the vague, hand-wavy second sentence actually means something useful. At least, those of us who actually care, and are sick of vague and frequently empty promises to "improve things."

...Or maybe I'm a robot. In which case, I hope that you, for one, will welcome your new robotic overlords. :)

Mozilla: Improving Security for Bugzilla

Posted Sep 4, 2015 23:37 UTC (Fri) by pboddie (guest, #50784) [Link] (3 responses)

Interesting that the linked FAQ - a PDF document - is presumably hosted on something resembling one of those Web caching nodes one sees all over the place nowadays, judging by the lengthy hostname on some unmemorable domain in the URL. It's almost like the punchline to a bad joke. (A Dropbox URL would have been the icing on the cake.)

A few things (maybe found in the FAQ) are still left lingering. For example, is this a general Bugzilla problem or more a specific thing to Mozilla's instance (which is unhelpfully referenced as just "Bugzilla")? Free Software really needs robust bug trackers and tools, despite what the GitHub crowd may say, and projects need the confidence to keep using them. If I were still running Bugzilla instances, I'd really want to know a bit more about what to do with this news.

(I remember dealing with MediaWiki and actually getting some pretty good security-related news from that project, even though it wasn't my software of choice, and even though I later ended up just using the Red Hat packages, anyway.)

Mozilla: Improving Security for Bugzilla

Posted Sep 4, 2015 23:56 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (1 responses)

Yes, read the FAQ. Bad guys obtained somebody's password. This is neither specific to Mozilla's bug tracker instance, nor to Bugzilla as software, nor even to the concept of bug trackers.

Mozilla: Improving Security for Bugzilla

Posted Sep 5, 2015 12:49 UTC (Sat) by pboddie (guest, #50784) [Link]

OK. Thanks for summarising in a more concise and coherent way than a blog post entitled "Improving Security for Bugzilla" and saving me from digging up the essentials from an FAQ document published on ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com.

Mozilla: Improving Security for Bugzilla

Posted Sep 17, 2015 9:07 UTC (Thu) by ssokolow (guest, #94568) [Link]

Yeah. NetDNA is the old/legacy name of MaxCDN's enterprise offering. They're basically the current "cool kid" competitor to Akamai because they offer http://www.bootstrapcdn.com/

Mozilla: Improving Security for Bugzilla

Posted Sep 5, 2015 10:02 UTC (Sat) by warrax (subscriber, #103205) [Link] (2 responses)

What's most amazing to me about this is that there are (at the very least) 3 bugs which are classified as sec-high or sec-critical which have been lingering in the bug tracker for over 130 days. If that doesn't scare you about the security of the Firefox code base, I don't know what will.

(Not that I think proprietary or Chrome/Chromium code is necessarily any better, but damn... I guess this might be some of the reasoning behind Rust, but I doubt that those bugs are simple memory safety issues -- which are *usually* pretty easy to fix.)

Mozilla: Improving Security for Bugzilla

Posted Sep 5, 2015 12:10 UTC (Sat) by roc (subscriber, #30627) [Link] (1 responses)

How did you draw that conclusion?

Mozilla: Improving Security for Bugzilla

Posted Sep 5, 2015 17:04 UTC (Sat) by warrax (subscriber, #103205) [Link]

They mention how long the attacker had access to different classes of bugs.

Mozilla: Improving Security for Bugzilla

Posted Sep 5, 2015 16:37 UTC (Sat) by drag (guest, #31333) [Link] (8 responses)

All of the steps taken by Mozilla seem to be appropriate.

What I am curious about is what form does the 'two factor' authentication take.

Admins have their personal passwords 'stolen' so that attackers can gain access to a project's servers has been a perennial problem for open source projects. Debian, Fedora, etc. If, for example, the 'second' factor is from a separate device.. like a cell phone with a number generator in it, then that would probably be extremely helpful.

Large scale distributed projects all seem very vulnerable these sorts of issues. If Mozilla can find a good solution then I am very interested in it.

Mozilla: Improving Security for Bugzilla

Posted Sep 5, 2015 21:43 UTC (Sat) by roc (subscriber, #30627) [Link] (7 responses)

The second factor is a TOTP app running on a smartphone.

Mozilla: Improving Security for Bugzilla

Posted Sep 6, 2015 0:43 UTC (Sun) by drag (guest, #31333) [Link] (6 responses)

Do you know what software they are using on the phone or server side?

Mozilla: Improving Security for Bugzilla

Posted Sep 6, 2015 7:16 UTC (Sun) by roc (subscriber, #30627) [Link] (4 responses)

On the server side, no.

On the client side, off-the-shelf TOTP apps work, like Google Authenticator on Android.

Mozilla: Improving Security for Bugzilla

Posted Sep 6, 2015 13:14 UTC (Sun) by jhoblitt (subscriber, #77733) [Link] (1 responses)

I stopped using Google Authenticator after loosing a number of TOTP tokens when flashing my phone. I've since switched to a yubikey neo (with NFC) + the yubico equivalent of the Google Authenticator app a couple of months ago.

Mozilla: Improving Security for Bugzilla

Posted Sep 6, 2015 21:11 UTC (Sun) by iarenaza (subscriber, #4812) [Link]

FreeOTP (https://fedorahosted.org/freeotp/) is another alternative.

Mozilla: Improving Security for Bugzilla

Posted Sep 11, 2015 16:12 UTC (Fri) by hkario (subscriber, #94864) [Link] (1 responses)

Google Authenticator is (surprise! surprise!) closed source

hardly a good pick to store your keys to the castle

Mozilla: Improving Security for Bugzilla

Posted Sep 11, 2015 16:20 UTC (Fri) by pizza (subscriber, #46) [Link]

Google Authenticator just implements subsets of an open spec (TOTP, RFC6238) There are many implementations, on a variety of platforms.

Mozilla: Improving Security for Bugzilla

Posted Sep 9, 2015 8:39 UTC (Wed) by ovitters (guest, #27950) [Link]

For server side, seems code is called "MFA". See e.g. http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=blob;.... I see the perl module Auth::GoogleAuth as well as GD::Barcode::QRcode for the image. This all is not in an extension.

If you browse around the repository they have all kinds of nice things in extensions. E.g. something which uses a http dns blacklist to automatically deny account creations based on IP address, etc.

Mozilla: Improving Security for Bugzilla

Posted Sep 5, 2015 19:29 UTC (Sat) by ibukanov (subscriber, #3942) [Link] (6 responses)

The reason for compromise was that the same password was used both for Bugzilla and another site that got compromised. This problem could be trivially prevented if browsers would provide better password management including automatic password generation.

Mozilla: Improving Security for Bugzilla

Posted Sep 7, 2015 3:26 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Or integration with external password managers. I really don't want my passwords tied to the browser; it isn't the only thing that needs them and I don't trust them that much anyways.

Mozilla: Improving Security for Bugzilla

Posted Sep 7, 2015 8:47 UTC (Mon) by epa (subscriber, #39769) [Link] (3 responses)

Yes, or some halfway decent keypair authentication as used for ssh.

Mozilla: Improving Security for Bugzilla

Posted Sep 7, 2015 17:06 UTC (Mon) by ewan (guest, #5533) [Link] (2 responses)

Browsers are fine with SSL client certs. If you're in a community that can issue their own, it works brilliantly - it's decently secure, and 'logging in' is completely transparent, sites just know who you are as soon as you're connected.

Mozilla: Improving Security for Bugzilla

Posted Sep 8, 2015 13:39 UTC (Tue) by cortana (subscriber, #24596) [Link] (1 responses)

It's the logging out that's difficult. Perhaps this is just a failing of the one site I use that uses client certificate authentication, but there doesn't seem to be any way to log out so that I can change users without restarting Firefox.

Mozilla: Improving Security for Bugzilla

Posted Sep 10, 2015 16:58 UTC (Thu) by kvaml (guest, #61841) [Link]

Yes, they should provide a button that forces a 401 authentication error. That should allow you to switch credentials.

Mozilla: Improving Security for Bugzilla

Posted Sep 14, 2015 3:14 UTC (Mon) by gutschke (subscriber, #27910) [Link]

FIDO U2F would also help a lot, as it ties the second factor to the domain name. I am sad to see that it hasn't been picked up widely yet.

Look out other bug trackers

Posted Sep 5, 2015 21:14 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link]

It seems to me that a critical point here is that the attackers were after information about known security bugs, presumably so they could exploit them before they were closed. I sincerely doubt this is a one-time thing. Every project that deals with security bugs needs to be looking at how it tracks them and whether they also have exploitable problems that could give an attacker access to all their known security bugs.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 7, 2015 5:07 UTC (Mon) by xophos (subscriber, #75267) [Link] (22 responses)

There should not have been anything in that bugzilla that's worth stealing.
When an exploitable security problem is found by some good guy that reports it to Mozilla, chances are about 50% (higher, if you are more cynical than me) that some bad guy had it first. So any feature development, update cycles, deadlines etc. become irrelevant until this vulnerability is fixed.
Hello Mozilla people if you find a vulnerability:
So first warn your users instantly and do a fix within 2-3 days (What do you have auto update for anyway?).
If you can't do that (because the fix is complicated) disable the vulnerable functionality until you have a real fix.
If you can't do that, tell your users how to work around the vulnerability.
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.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 7, 2015 7:19 UTC (Mon) by roc (subscriber, #30627) [Link] (21 responses)

> When an exploitable security problem is found by some good guy that reports it to Mozilla, chances are about 50% (higher, if you are more cynical than
> 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.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 7, 2015 11:08 UTC (Mon) by xophos (subscriber, #75267) [Link] (20 responses)

If there is a security vulnerability found that can not be fixed in a few days every few weeks in Mozilla then yes it is time to stop every thing else and concentrate solely on finding and fixing those in my oppinion.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 7, 2015 11:31 UTC (Mon) by roc (subscriber, #30627) [Link] (2 responses)

I don't think that's the case.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 7, 2015 14:55 UTC (Mon) by xophos (subscriber, #75267) [Link] (1 responses)

but that was your argument against disabling vulnerable functionality until it can be fixed.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 7, 2015 23:08 UTC (Mon) by roc (subscriber, #30627) [Link]

My comment was about the entire ecosystem. One day your browser doesn't work, a few days later your bank's Web server doesn't work, next week it's your router, later it's your entire OS.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 7, 2015 20:01 UTC (Mon) by Wol (subscriber, #4433) [Link] (15 responses)

> yes it is time to stop every thing else and concentrate solely on finding and fixing those in my opinion

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,
Wol

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 8, 2015 5:02 UTC (Tue) by xophos (subscriber, #75267) [Link] (14 responses)

I am a software developer, i know that there is no non-trivial program without bugs.
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

Posted Sep 8, 2015 8:06 UTC (Tue) by ovitters (guest, #27950) [Link]

Are you a sole software developer? In a big team, you don't focus on one thing at a time. Mozilla has loads of people working for them. Like any big company, all those people focus on different things. Simplistic example, try having every single person in a company solely focus on sales. It doesn't work!

PS: No need to press enter all the time. Paragraphs are cool! :-P

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 8, 2015 17:05 UTC (Tue) by zlynx (guest, #2285) [Link]

Removing a bunch of bugs from code is the entire idea with Rust. So Mozilla IS doing something about it. Hopefully Rust will be able to help reason about the code and prove things are right. As well as being fast and memory efficient.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 14, 2015 19:52 UTC (Mon) by ballombe (subscriber, #9523) [Link] (11 responses)

> I am a software developer, i know that there is no non-trivial program without bugs.

There are complex software with almost no bugs: TeX, IJG libjpeg, qmail
but there is little interest in bug-free software.

Mozilla: Improving Security for Bugzilla is the wrong angle

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.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 15, 2015 10:39 UTC (Tue) by jezuch (subscriber, #52988) [Link] (9 responses)

> 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).

...and no new features added. That's the only way to bug-free software: 30 years of bug fixing + no new functionality, ever :)

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 15, 2015 11:06 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (8 responses)

> That's the only way to bug-free software: 30 years of bug fixing

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.

Mozilla: Improving Security for Bugzilla is the wrong angle

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).

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 15, 2015 11:52 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (2 responses)

> Of course the presumption there is that your formal specifications are bug-free.

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.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 16, 2015 6:10 UTC (Wed) by jezuch (subscriber, #52988) [Link] (1 responses)

On the other hand, sufficiently detailed specification is indistinguishable from a program. So if writing programs is hard, why should writing sufficiently detailed specifications be any easier?

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 16, 2015 6:14 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

It's fairly easy to come up with useful invariants in a spec, that might be difficult to uphold.

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".

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 15, 2015 15:49 UTC (Tue) by NAR (subscriber, #1313) [Link] (3 responses)

From the linked article:

"(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.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 16, 2015 8:16 UTC (Wed) by cebewee (guest, #94775) [Link] (2 responses)

I would disagree that converting source code to ASTs is "the hard part". There isn't much interesting happening there in most languages.

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 18, 2015 22:36 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

You've clearly never tried to write a lexer/parser.

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,
Wol

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 19, 2015 13:01 UTC (Sat) by cebewee (guest, #94775) [Link]

Why is this any harder to parse than "A: B = C(100); D foo"? I mean, it's somewhat unusual for modern languages to have variables, functions and statements in separate namespaces, but otherwise?

Mozilla: Improving Security for Bugzilla is the wrong angle

Posted Sep 8, 2015 7:02 UTC (Tue) by oldtomas (guest, #72579) [Link]

> if there is a security vulnerability found that can not be fixed in a few days [...] it is time to stop every thing else and concentrate [...] [on] fixing those

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).