The major update UI displays the contents of the detailURL attribute in the update snippets. We've sandboxed the content to prevent scripts etc, but we appear to load it from an http:// url which is not secure. This means a MITM could easily replace that content. results could be simply a spoof ("click this link" to a non-mozilla site), or the content could redirect (or better, meta refresh) to a URL serving an exe, prompting the user to download a trojan. Pointed out by Aaron Sigel https://twitter.com/#!/diretraversal/status/52107274294018048 Release Engineering is probably the wrong component because I don't see any of the release-blocking flags I need. Who would change this content? Note the entire www.mozilla.com site is available over https so there is no reason not to use it in the link.

Also now published at http://vttynotes.blogspot.com/2011/03/man-in-middle-attacking-mozilla-firefox.html For now this only affects 3.x users who manually Check for Updates. We need to fix this and regenerate the snippets before we push this out as an advertised update to millions more users.

Switch to https for 3.5/3.6 -> 4.0 major updates.

Update the default location for Firefox if we don't set a value in the release config.

(In reply to comment #3) > Created attachment 522247 [details] [diff] [review] > [tools] Change default url for Firefox Thunderbird guys, you probably want this too. Seamonkey's website doesn't support https.

(In reply to comment #0) > Note the entire www.mozilla.com site is available over https so there is no > reason not to use it in the link. (In reply to comment #4) > (In reply to comment #3) > > Created attachment 522247 [details] [diff] [review] > > [tools] Change default url for Firefox > > Thunderbird guys, you probably want this too. Seamonkey's website doesn't > support https. If mozilla.org is available via https I would love to take a dir there for SeaMonkey to avoid the potential MITM attack here. And/or we can try and figure out how to get an https capable seamonkey-project.org. But I think it may be best to divert our end to another bug.

The patches above fix the situation for future major updates. Fixing up the existing snippets for the live major update: for b in Firefox-3.5.18-build1-4.0-MU Firefox-3.6.16-build1-4.0-MU; do for t in '' '-beta' '-test'; do echo ${b}${t} rsync -a ${b}${t}/ ${b}-https${t}/ find ${b}-https${t}/ -type f -exec sed -i -e 's/^detailsUrl=http:/detailsUrl=https:/' {} \; done done Used diff to check the changes are correct for all 6 dirs, eg: diff -ru Firefox-3.6.16-build1-4.0-MU-test/Firefox/3.6.16/Darwin_x86-gcc3-u-ppc-i386/20110319135224/af/releasetest/complete.txt Firefox-3.6.16-build1-4.0-MU-https-test/Firefox/3.6.16/Darwin_x8 6-gcc3-u-ppc-i386/20110319135224/af/releasetest/complete.txt --- Firefox-3.6.16-build1-4.0-MU-test/Firefox/3.6.16/Darwin_x86-gcc3-u-ppc-i386/20110319135224/af/releasetest/complete.txt 2011-03-21 20:13:48.513553000 -0700 +++ Firefox-3.6.16-build1-4.0-MU-https-test/Firefox/3.6.16/Darwin_x86-gcc3-u-ppc-i386/20110319135224/af/releasetest/complete.txt 2011-03-27 15:27:56.751502000 -0700 @@ -7,5 +7,5 @@ build=20110318052756 appv=4.0 extv=4.0 -detailsUrl=http://www.mozilla.com/af/firefox/4.0/details/ +detailsUrl=https://www.mozilla.com/af/firefox/4.0/details/ updateType=major All the detailsUrls get a 200 response, verified they look OK. The exceptions are ja and ja-JP-mac, which redirect to an http only site. Bug 645568 for that. Push the test snippets live for QA: ~/bin/backupsnip Firefox-3.6.16-build1-4.0-MU-https-test ~/bin/pushsnip Firefox-3.6.16-build1-4.0-MU-https-test ~/bin/backupsnip Firefox-3.5.18-build1-4.0-MU-https-test ~/bin/pushsnip Firefox-3.5.18-build1-4.0-MU-https-test

Callek, please file a bug on making seamonkey-project.org available via https, I think that should be doable and we should file a followup on both this and that other one to do this change for SM as well.

btw: I had a discussion with mrz about putting the billboard on https://aus3.mozilla.org/ so we could easily use the same mechanism for verifying the server's cert as we do for updates and he said it should be able to handle the load with no problem.

(In reply to comment #5) > If mozilla.org is available via https I would love to take a dir there for > SeaMonkey to avoid the potential MITM attack here. www.mozilla.org also supports SSL. Everything under projects/seamonkey/ redirects over to seamonkey-project.org so you can't use that. Given future plans to merge mozilla.org/mozilla.com you'd better ask dboswell what's a good spot that won't step on any namespace they were planning to use.

FTR I've filed bug 645639 to track the necessary Thunderbird changes.

With QA for checks. Production snippets are in Firefox-3.6.16-build1-4.0-MU-https Firefox-3.6.16-build1-4.0-MU-https-beta Firefox-3.5.18-build1-4.0-MU-https Firefox-3.5.18-build1-4.0-MU-https-beta

Comment on attachment 522246 [details] [diff] [review] [buildbot-configs] Fix release configs for Fx 3.5 and 3.6 Landed on default - next release will pick it up. http://hg.mozilla.org/build/buildbot-configs/rev/9ebee224d6ea

Comment on attachment 522247 [details] [diff] [review] [tools] Change default url for Firefox http://hg.mozilla.org/build/tools/rev/3f8f520f51b2

Not entirely sure how to set the blocking flags. It's fixed on the branch configs which is great for next time. What about the pending 3.x->4.0 major update though? that one needs to be regenerated and tested? - do we need a new bug for that? - there's already a fixed copy on releasetest. Is that a one-off test or is there a whole set of regenerated snippets that just need to be moved to the release channel?

Comment #6 here, and subsequently bug 646136, describe all the steps used to regenerate and tweak the 3.6.16/3.5.18 -> 4.0 final snippets. That was for releasetest, beta, and release, with only releasetest pushed into use.

nthomas: what do we need to do to get this pushed to release and beta channels?

If QA reports no issues with 3.6.16/3.5.18 -> 4.0 using https on releasetest we can push this out quickly. So, Anthony ? Wasn't this getting farmed out to an outside group ?

(In reply to comment #17) > If QA reports no issues with 3.6.16/3.5.18 -> 4.0 using https on releasetest we > can push this out quickly. So, Anthony ? Wasn't this getting farmed out to an > outside group ? Well, major update testing was farmed out for 3.6.16/3.5.18 -> 4.0. However we never specifically asked them to check for HTTPS. Is it possible to get HTTP updates on releasetest or are they only available via HTTPS? If... a) MU snippets on releasetest are only available over HTTPS, the results are valid b) MU snippets on releasetest are available over both HTTP & HTTPS, we'll need to do some additional spotchecks (should take less than a day)

I sent an email to r-d on March 27th ("Major updates to Firefox 4.0 using https for billboards"), asking for testing of the https billboards. Prior to then they were http, including the original verification for 4.0 ship day. So the key question is, was the testing done before March 27th or after ?

Our first testers started testing this on March 29th.

OK, great. Is testing complete now ? Where there any problems discovered ?

Yes, testing was completed that same week. No problems were discovered, however we did not do any testing specific to HTTPS. We only tested to make sure updates were prompted, downloaded, and installed.

As long as there were no comments on the billboard being slow to load, or sometimes wasn't complete, then I think we're fine. How come there wasn't a sign off email back to r-d ?

(In reply to comment #23) > As long as there were no comments on the billboard being slow to load, or > sometimes wasn't complete, then I think we're fine. How come there wasn't a > sign off email back to r-d ? No problems were found. I did send an email last week -- not sure why it didn't go through. Should I resend?

What are we waiting for on this bug? Why can't it be pushed live already?

Sorry, communication issues and me being away led to us not doing this. At this point we should wait for the MU refresh that comes from shipping 4.0.1 on Thursday. I've verified we're pointing at https://www.mozilla.com/%locale%/firefox/4.0/details/ for both 3.5.19 and 3.6.17.

Where's the Macaw download? I thought it was first supposed to be released on Tuesday then got pushed to today (Thursday). Patches for this and bug 640158 are ready to land, but the Firefox 4 download page still has 4.0.0. So, what's the big wait for TWO patches?

The update has more than 2 patches. And we are currently in the release process, hang tight...it will be out today (it takes some time to move the bits around, qualify the update, etc).

(In reply to comment #28) > The update has more than 2 patches. And we are currently in the release > process, hang tight...it will be out today (it takes some time to move the bits > around, qualify the update, etc). Okay...thanks. However, your Bug Queries lists on (https://wiki.mozilla.org/Releases/Firefox_4/Macaw) and the 4.0.1 Release Notes page don't match. On "Releases / Macaw" - Fixed returns ZERO results and directs to (https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status2.0:Macaw-fixed). However, the change list on the 4.0.1 Release Notes page goes to (https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status2.0%3A.1-fixed) and lists 53 Bugs, but I don't see this one (645551) listed.

Yeah, the bz admins were supposed to change the flag and did not. I have updated the query on the wiki. This one is not listed as it isn't marked .1-fixed yet. Once the updates are live it will be marked and show up in that query.

When I look at the live snippets I see https details URLs. For example Mac 3.6.16 -> 3.6.17 minor update https://aus2.mozilla.org/update/3/Firefox/3.6.16/20110319135224/Darwin_x86-gcc3-u-ppc-i386/en-US/release/Darwin%209.8.0/default/default/update.xml Mac 3.6.17 major update (forced) https://aus2.mozilla.org/update/3/Firefox/3.6.17/20110420140830/Darwin_x86-gcc3-u-ppc-i386/en-US/release/Darwin%209.8.0/default/default/update.xml?force=1 That looks "fixed" as far as what I was originally reporting. What "this" are we "not doing" per comment 26?

(In reply to comment #31) > That looks "fixed" as far as what I was originally reporting. Yes, that's the effect of the buildbot-configs patch. > What "this" are we "not doing" per comment 26? Refreshing the major updates that pointed to 4.0, which is what I assumed you were referring to in comment #25. At any rate, this is fixed at last.