645551 - snippet details URL is not secure, can spoof major updates

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Daniel Veditz [:dveditz]]

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.

Comment 1

[Daniel Veditz [:dveditz]]

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.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [buildbot-configs] Fix release configs for Fx 3.5 and 3.6

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

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: [tools] Change default url for Firefox

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

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 5

[Justin Wood (:Callek)]

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

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 7

[Robert Kaiser]

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.

Comment 8

[Robert Strong (they/them - no direct email)]

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.

Comment 9

[Daniel Veditz [:dveditz]]

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

Comment 10

[Mark Banner (:standard8)]

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

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

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 12

[Nick Thomas [:nthomas] (UTC+12)]

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 13

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 522247 [details] [diff] [review]
[tools] Change default url for Firefox

http://hg.mozilla.org/build/tools/rev/3f8f520f51b2

Comment 14

[Daniel Veditz [:dveditz]]

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 15

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 16

[Daniel Veditz [:dveditz]]

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

Comment 17

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 18

[u279076]

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

Comment 19

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 20

[u279076]

Our first testers started testing this on March 29th.

Comment 21

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 22

[u279076]

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.

Comment 23

[Nick Thomas [:nthomas] (UTC+12)]

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 ?

Comment 24

[u279076]

(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?

Comment 25

[Daniel Veditz [:dveditz]]

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

Comment 26

[Nick Thomas [:nthomas] (UTC+12)]

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.

Comment 27

[Chris B.]

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?

Comment 28

[LegNeato]

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

Comment 29

[Chris B.]

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

Comment 30

[LegNeato]

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.

Comment 31

[Daniel Veditz [:dveditz]]

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?

Comment 32

[Nick Thomas [:nthomas] (UTC+12)]

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