snippet details URL is not secure, can spoof major updates

RESOLVED FIXED

Status

Release Engineering
General
P2
normal
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: dveditz, Assigned: nthomas)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 Macaw+, status2.0 .1-fixed, blocking1.9.2 .17+, status1.9.2 .17-fixed, blocking1.9.1 .19+, status1.9.1 .19-fixed)

Details

(Whiteboard: [sg:moderate spoof], URL)

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
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.
(Reporter)

Updated

7 years ago
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
status1.9.1: --- → wanted
status1.9.2: --- → wanted
status2.0: --- → wanted
(Assignee)

Comment 2

7 years ago
Created attachment 522246 [details] [diff] [review]
[buildbot-configs] Fix release configs for Fx 3.5 and 3.6

Switch to https for 3.5/3.6 -> 4.0 major updates.
Attachment #522246 - Flags: review?(bhearsum)
(Assignee)

Comment 3

7 years ago
Created attachment 522247 [details] [diff] [review]
[tools] Change default url for Firefox

Update the default location for Firefox if we don't set a value in the release config.
Attachment #522247 - Flags: review?(bhearsum)
(Assignee)

Comment 4

7 years ago
(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.
(Assignee)

Updated

7 years ago
Depends on: 645568
(Assignee)

Comment 6

7 years ago
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

7 years ago
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.
(Assignee)

Updated

7 years ago
Assignee: nobody → nrthomas
Priority: -- → P2
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.
(Reporter)

Comment 9

7 years ago
(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.
(Assignee)

Comment 11

7 years ago
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
Whiteboard: [sg:moderate spoof] → [sg:moderate spoof][with qa]
Attachment #522246 - Flags: review?(bhearsum) → review+
Attachment #522247 - Flags: review?(bhearsum) → review+
(Assignee)

Updated

7 years ago
Depends on: 646136
(Assignee)

Comment 12

7 years ago
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
Attachment #522246 - Flags: checked-in+
(Assignee)

Comment 13

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

http://hg.mozilla.org/build/tools/rev/3f8f520f51b2
Attachment #522247 - Flags: checked-in+
(Reporter)

Comment 14

7 years ago
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?
(Assignee)

Comment 15

7 years ago
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.

Updated

7 years ago
Blocks: 647107
(Reporter)

Comment 16

7 years ago
nthomas: what do we need to do to get this pushed to release and beta channels?
blocking1.9.1: ? → .19+
blocking1.9.2: ? → .17+
blocking2.0: ? → Macaw+
(Assignee)

Comment 17

7 years ago
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)
(Assignee)

Comment 19

7 years ago
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.
(Assignee)

Comment 21

7 years ago
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.
(Assignee)

Comment 23

7 years ago
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?
(Reporter)

Comment 25

7 years ago
What are we waiting for on this bug? Why can't it be pushed live already?
(Assignee)

Comment 26

7 years ago
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.
Whiteboard: [sg:moderate spoof][with qa] → [sg:moderate spoof]

Comment 27

7 years ago
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

7 years ago
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

7 years ago
(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

7 years ago
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.
(Reporter)

Comment 31

7 years ago
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?
(Assignee)

Comment 32

7 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED

Updated

7 years ago
Blocks: 653974
(Reporter)

Updated

7 years ago
status1.9.1: wanted → .19-fixed
status1.9.2: wanted → .17-fixed
status2.0: wanted → .1-fixed
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.