Mozilla / Firefox security practices

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
EDIT: my bonsai query is wrong - I restricted it incorrectly, so there are actually more changes. I still think my point stands, though this means many more lines of code changed.

Nothinman sent me a pm.


Figured I might as well reply here. I'm not speaking for anyone. This is a mix of facts as I understand them, and my opinion.

Response to http://www.infodrom.org/~joey/log/?200507300606:
It is very unfortunate that the Mozilla Foundation does not provide dedicated, isolated and clean patches for security problems that have been reported against their software packages which do not change the functionality. Instead they release new versions that usually fix tons of security problems and other stuff irrelevant for security updates.
You could use bonsai to diff the sources between point releases and get the patches you want. {edit:following numbers are incorrect - real numbers are 1-2 thousand} They added 52 lines and removed 39 lines of code between 1.0.4 and 1.0.5. They undid one of the changes (+33 lines, -46 lines) for 1.0.6. It doesn't get much more specific than that. Each checkin even has a brief comment explaining what the code change does. The code itself is often commented. If the Debian team doesn't care enough to read those few dozen lines of changes, and get on IRC and talk to mozilla devs to figure out what's being changed if they don't understand, maybe they shouldn't be shipping modified versions of the product.

The ranting Debian person also fails to explain WHICH of the VERY small number of changes weren't security-related. (In this case, the API change in 1.0.5 wasn't security issue, but a fix for a major regression that had been introduced on the Gecko 1.7 branch, which powers Firefox 1.0.x and Mozilla 1.7.x).

The Mozilla Foundation has broken compatibility twice so far in 1.0.x releases - 1.0.3 to fix a severe security issue (I believe this was a reasonable decision - get hacked when using any of a large number of extensions, or break compatibility with a handful extensions - what would you pick?), and 1.0.5 because they didn't catch side-effects of a change (1.0.6 unbreaks what they broke with 1.0.5). Are they not allowed one mistake?

What's really annoying is when distros do something like "1.0-3" which backports a security fix into 1.0 and report a 1.0 user agent, though the code is identical to, say 1.0.4. The result is that they get banned from Mozilla Update, since for security reasons Mozilla Update can't serve any content to Firefox 1.0.3 or older, but the site can't tell that their "1.0" actually has the necessary security fixes. Because the distros don't bump the version number, their users come complain to the Mozilla Update people. We take enough flak about picking security over convenience from people using official releases already.






Response to http://kitenet.net/~joey/blog/entry/bug_hiding_systems-2005-07-30-06-25.html:
There were several links to the mozilla bug tracking system, I chose the first:
Access Denied
You are not authorized to access bug #294795. To see this bug, you must first login to an account with the appropriate permissions.

Please press Back and try again.
Amazingly, they want you to get a user account and log in just to see a bug report. This is normally the point where I decide I have something more pressing to attend to, and so will most people.
First off, it's not that you log in, it's that you have to be a member of the security group. Note that the message says:
To see this bug, you must first login to an account with the appropriate permissions.
I can't see the bug either. These are the only people who can see that bug (plus any others they specifically allow). This guy should understand that for all major vulnerabilities, they specify a date when the relevant bugs will be open. The idea is to give distributors time to fix their releases, and people time to update before telling the world how to exploit the hole (often bugs contain testcases which could trivially be adapted into exploits).

The guy goes on to log in with a bugmenot and, of course still can't access the bug.

That's right, this bug, which is for a security hole that was fixed two weeks ago, is not being dislosed until apparently, August 1st. Same is true for several others of the holes fixed in recent versions. That's two weeks for distibutions that have to backport these fixes to race against black hats to see who can track down the hole in all the other changes in the new mozilla release, and respectively fix and exploit it.
As I said above, there aren't that many changes made in 0.0.1 releases. The distro people can't spend 10 minutes on IRC to talk with Mozilla developers about the changes?

Ubuntu's decision to just include the new release rather than backporting patches is probably what the Mozilla Foundation wants anyway - that way there are fewer users filing bugs on nonsensical / modified product versions. Every so often, someone files a bug using a distro-modified version that turns out to be a problem in the modifications the distro made. Shipping official versions would reduce this.

If I understand correctly, this guy is first complaining that the bug is closed, and second complaining that it's only closed for two weeks before the black hats get access. Which way does he want it? He's also apparently not aware that there's an advance-notification list that distributors and vendors can join to be notified earlier about security issues and fixes.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
Figured I might as well reply here. I'm not speaking for anyone. This is a mix of facts as I understand them, and my opinion.

I appreciate it, I debated on just opening a new thread about it but I wanted to make sure I got your attention =)

If the Debian team doesn't care enough to read those few dozen lines of changes, and get on IRC and talk to mozilla devs to figure out what's being changed if they don't understand, maybe they shouldn't be shipping modified versions of the product.

The maintainer for mozilla-browser is listed as maintainer of 166 packages, if he had to jump through those hoops with every patch for every package nothing would get done. And I wouldn't be surprised if the moz devs on IRC told him just to package the new version they released.

it it's only closed for two weeks before the black hats get access

But who reported the hole in the first place? Was it talked about on BugTraq or any other archived mailing list? No one knows except for a handful of special people. If the black hats were really interested in releasing an exploit for Mozilla I doubt they'd start by looking through the BTS for reported and unfixed holes.

He's also apparently not aware that there's an advance-notification list that distributors and vendors can join to be notified earlier about security issues and fixes.

And who does the verification of the people who join that list?

Ubuntu's decision to just include the new release rather than backporting patches is probably what the Mozilla Foundation wants anyway - that way there are fewer users filing bugs on nonsensical / modified product versions. Every so often, someone files a bug using a distro-modified version that turns out to be a problem in the modifications the distro made. Shipping official versions would reduce this.

I thought Ubuntu did the same thing as Debian in this regard, maybe that's changed recently. And users will always find ways around whatever procedure's you put in place, especially one aimed for new users like Ubuntu.
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
Originally posted by: Nothinman
If the Debian team doesn't care enough to read those few dozen lines of changes, and get on IRC and talk to mozilla devs to figure out what's being changed if they don't understand, maybe they shouldn't be shipping modified versions of the product.

The maintainer for mozilla-browser is listed as maintainer of 166 packages, if he had to jump through those hoops with every patch for every package nothing would get done. And I wouldn't be surprised if the moz devs on IRC told him just to package the new version they released.
I would be surprised. I mentioned this in one channel and various people said they'd help. Maybe debian needs to find more people, or reduce their number of packages to something more manageable. Or they should just stop using their ridiculous definition of stable that means "not even major crash fixes are included".

it it's only closed for two weeks before the black hats get access

But who reported the hole in the first place? Was it talked about on BugTraq or any other archived mailing list? No one knows except for a handful of special people. If the black hats were really interested in releasing an exploit for Mozilla I doubt they'd start by looking through the BTS for reported and unfixed holes.
You don't think the security group accounts for this? Bugs that are known to be public are opened. The Firefox 1.0.3 hole was full-disclosured, and the bug was opened. It was re-closed when somebody provided specific exploit instructions to work around our temporary fix on Mozilla Update, but the relevant info was made available.

He's also apparently not aware that there's an advance-notification list that distributors and vendors can join to be notified earlier about security issues and fixes.

And who does the verification of the people who join that list?
No idea.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
I would be surprised. I mentioned this in one channel and various people said they'd help. Maybe debian needs to find more people, or reduce their number of packages to something more manageable. Or they should just stop using their ridiculous definition of stable that means "not even major crash fixes are included".

Well maybe we just need to get a DD on the Mozilla security team.

You don't think the security group accounts for this?

You say that like stupider things haven't been done.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
I've been considering different browsers for a little while now...

Only provide bug details to a secret society of mozilla developers because hackers can't use diff? Kinda fishy... ;)
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
Only provide bug details to a secret society of mozilla developers because hackers can't use diff? Kinda fishy...
I think the goal is to just make it more difficult. Often, seeing the fix won't show you how to actually exploit the hole.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: CTho9305
Only provide bug details to a secret society of mozilla developers because hackers can't use diff? Kinda fishy...
I think the goal is to just make it more difficult. Often, seeing the fix won't show you how to actually exploit the hole.

Seeing crappy descriptions don't always help either. Seeing the code is much much better. ;)
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
Seeing crappy descriptions don't always help either. Seeing the code is much much better.
You'd be surprised. With a reasonable explanation of a hole (i.e. the kind you'd find in the bug report), a slightly-not-stupid script kiddie might be able to put together an exploit. Given a normal security patch, I would not expect to have much of a clue how to go about attacking the hole it fixes. To have any hope of exploiting a hole based on a patch alone, you'd need to either be very familiar with the code that was changed, or you need to have a LOT of time and motivation.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: CTho9305
Seeing crappy descriptions don't always help either. Seeing the code is much much better.
You'd be surprised. With a reasonable explanation of a hole (i.e. the kind you'd find in the bug report), a slightly-not-stupid script kiddie might be able to put together an exploit. Given a normal security patch, I would not expect to have much of a clue how to go about attacking the hole it fixes. To have any hope of exploiting a hole based on a patch alone, you'd need to either be very familiar with the code that was changed, or you need to have a LOT of time and motivation.

"Not stupid" and "script kiddie" are mutually exclusive. ;)

I dunno, if the patch fixes a problem the patch should give the hacker an idea of what to play with. At least as much idea as with a crappy description (the kind that are most common with security reports).

Closing the security reports to the users is a travesty.
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
Originally posted by: n0cmonkey
Originally posted by: CTho9305
Seeing crappy descriptions don't always help either. Seeing the code is much much better.
You'd be surprised. With a reasonable explanation of a hole (i.e. the kind you'd find in the bug report), a slightly-not-stupid script kiddie might be able to put together an exploit. Given a normal security patch, I would not expect to have much of a clue how to go about attacking the hole it fixes. To have any hope of exploiting a hole based on a patch alone, you'd need to either be very familiar with the code that was changed, or you need to have a LOT of time and motivation.

"Not stupid" and "script kiddie" are mutually exclusive. ;)

I dunno, if the patch fixes a problem the patch should give the hacker an idea of what to play with. At least as much idea as with a crappy description (the kind that are most common with security reports).

Closing the security reports to the users is a travesty.

You'd rather show the world 3 exploits from day 0, before anybody even knows workarounds, than land a fix (and share the patch with trusted distributors) and give people some time to update? That bug was reported on 4/18, and the patch written the next day. It was checked in on 5/9 for 1.0.4 which was released on 5/23. Between 4/18 and 5/23, NO regular users could be protected if the bug were made public.

Given that a large number of people still use 1.0, not even 1.0.1 (we know this because of a bug in 1.0's auto-update code which DDoSes a Mozilla Update server at 0:00GMT on the first of every month), it's probably not great that you can get exploits right from bugzilla even after this many months.
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
By the way, even though the lines of code changed is closer to 2000, my point still stands: 1) each checkin has an explanation, though sometimes cryptic if security-related (in which case distributions can be notified or could ask on IRC) 2) crash fixes are important too 3) shipping a customized version of something as big as mozilla is going to be difficult. I would imaging OpenOffice would be hard to maintain too.
 

n0cmonkey

Elite Member
Jun 10, 2001
42,936
1
0
Originally posted by: CTho9305
You'd rather show the world 3 exploits from day 0, before anybody even knows workarounds, than land a fix (and share the patch with trusted distributors) and give people some time to update? That bug was reported on 4/18, and the patch written the next day. It was checked in on 5/9 for 1.0.4 which was released on 5/23. Between 4/18 and 5/23, NO regular users could be protected if the bug were made public.

Given that a large number of people still use 1.0, not even 1.0.1 (we know this because of a bug in 1.0's auto-update code which DDoSes a Mozilla Update server at 0:00GMT on the first of every month), it's probably not great that you can get exploits right from bugzilla even after this many months.

I'd rather the world know what is going on when a patch is released. If a patch was written the next day, why did it take over a month to release it to the world?
 

CTho9305

Elite Member
Jul 26, 2000
9,214
1
81
If a patch was written the next day, why did it take over a month to release it to the world?
Probably because they don't want to release updates every day, but prefer to release them in groups of patches - like Microsoft's "all patches on Tuesdays" or whatever. I know I'd be irritated if there was an update every week unless the process was VERY painless (it looks like 1.5 updates will be much less painful). Even so, corporations probably wouldn't like it. Plus, they need to do QA (though that probably doesn't take much more than a week). Ask the Mozilla Foundation, or Asa ;).