Closed
Bug 381179
Opened 18 years ago
Closed 18 years ago
Software update should fail silently or provide better UI for certificate mismatches
Categories
(Toolkit :: Application Update, defect)
Toolkit
Application Update
Tracking
()
RESOLVED
DUPLICATE
of bug 366191
People
(Reporter: Gijs, Unassigned)
Details
(Whiteboard: [sg:moderate] bug 340198 came back?)
Steps to reproduce:
1. Visit a big hotel chain with wifi provided by Swisscom or some other vendor which does the same thing.
2. Start up a laptop and join the (open) wifi network.
3. Open Firefox when it is supposed to look for updates (I think it does this once a day, but I'm not sure and can't be bothered to check at the moment).
Expected Result:
Firefox opens, perhaps with UI indicating that it tried to update itself and/or extensions, and failed.
Actual Results:
The first thing that opens is a dialog saying something like the following:
"You have attempted to establish a connection with "update.mozilla.org". However, the security certificate presented belongs to "secure2.swisscom.com". It is possible, though unlikely, that someone may be trying to intercept your communication with this web site."
(hostnames are probably incorrect, but you get the idea)
Now, as far as I can tell the problem here is that what the swisscom thing does is return its own domain for any dns lookup you do, and then redirect you to the actual swisscom domain if you hit the server with a different URL. This may or may not be entirely correct, but either way - the result is that you're shown this cryptic security dialog without having done anything. This is really really *weird* for ordinary users, and it would be great if we could provide either better UI or just failed silently, because the current setup is odd.
Reporter | ||
Comment 2•18 years ago
|
||
So from what I recall, I hit this bug in February this year (staying at some NH hotel for FOSDEM), which was long after bug 304286 was fixed. So I think it should have been OK at that point if that fix really fixed the problem. I'm in no position to test this right now, unfortunately, but it might be good to attempt to re-test.
Comment 3•18 years ago
|
||
Scary, the hotel was trying to MITM your SSL connections?
Bug 304286 only covered the AUS app update check. At the time we missed the fact that the Extension Manager had a separate implementation, which was (supposed to be) fixed in bug 340198 in 1.5.0.7 and FF2.0.0.0
Whiteboard: [sg:low] → [sg:moderate]
Updated•18 years ago
|
Whiteboard: [sg:moderate] → [sg:moderate] bug 340198 came back?
Comment 4•18 years ago
|
||
(In reply to comment #3)
> Bug 304286 only covered the AUS app update check. At the time we missed the
> fact that the Extension Manager had a separate implementation, which was
> (supposed to be) fixed in bug 340198 in 1.5.0.7 and FF2.0.0.0
That bug seems to be about certs accepted for browsing later being accepted for software update requests. I think bug 366191 is the bug that fixed this problem - is this bug not a duplicate?
Comment 5•18 years ago
|
||
I guess it's possible that Gijs misremembered addons.mozilla.org as update.mozilla.org, since he filed this bug report a few months after encountering the bug.
Comment 6•18 years ago
|
||
The fix for bug 366191 was released with 1.5.0.10 and 2.0.0.2 on February 23. FOSDEM 2007 was held on February 24th and 25th.
Gijs: how diligent are you about upgrading immediately? Do you think it was likely you were still running the unfixed version at the time?
Comment 7•18 years ago
|
||
What is the concern here?
Your ISP (the hotel) tried to MITM you, sorta. They apparently weren't
trying to fool into thinking that their web site was the one you wanted.
They just wanted you to go to their site, probably so they could force
you to login and maybe even pay for the WiFi service. Nearly all WiFi
hotspots everywhere do this, so it's not unusual, and most people would
not really regard it as an attack.
Anyway, as reported in comment 0, the host name mismatch was detected and
reported. So, from a security standpoint, it did exactly what it was
supposed to do. I wonder, did it offer to let you "continue" to override
the error? That would be BAD, but FF users can't be deprived of their
beloved overrides.
So, I guess the complaint here is simply that there is a warning dialog
without apparent cause, e.g. the user may not have any idea why the
https request was sent at all. I think you're suggesting that the error
dialog should say "Auto updated failed because server was not mozilla's
update server.", or perhaps that it fail silently to avoid confusion
altogether. I could live with either of those suggestions.
In any case, this seems to be only a UI issue, not any actual vulnerability.
Comment 8•18 years ago
|
||
We consider "UI issues" that are likely to result in compromised computers to be vulnerabilities.
Reporter | ||
Comment 9•18 years ago
|
||
Yeah, so Nelson is right in that the whole point of routing you to that page is to get you to pay for the WiFi service.
Dan: Heh, that's a "fun" issue. I'm usually diligent in applying updates, but I arrived for FOSDEM on friday. Which I guess means that I missed the update on that occasion (and in fact, that the MITM the hotel was doing might even have been exactly the thing that prevented me from getting it). So I'll dupe this to bug 366191, since it's at the very least the same issue. If I see it again, I'll reopen there, I guess.
Sorry for raising a false alarm! I guess I'll have to be better at filing bugs for these things immediately :\
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Comment 10•18 years ago
|
||
(In reply to comment #8)
> We consider "UI issues" that are likely to result in compromised computers to
> be vulnerabilities.
Then all the UI that lets the user ignore the security error and continue
is a vulnerability.
Comment 11•18 years ago
|
||
Bug 366191 is the poster boy for users who hurt themselves by overriding
security errors. That bug illustrates precisely the reason we should not
let users override security errors.
There was a user who was being MITMed. A WiFi spot was intercepting his
browser's attempts to fetch browser updates. It was returning falsified
DNS entries, causing his browser to go to the wrong IP address, and the
server at that address was trying (poorly) to fool his browser into
believing that this other server was actually the updates server. (This
is pretty typical WiFi hotspot behavior, but this user wasn't in a WiFi
hotspot. He was IN HIS OWN HOME.)
The user's instinct was to override the error, and connect anyway. !!
The attack didn't fool the browser's built-in security features, which
detected it and didn't allow it to proceed automatically, but it succeeded
in getting the user to override the security error, and to do so repeatedly,
surrendering himself repeatedly to the attack.
The MITM may not have been malicious, and may even have been accidental,
but it was an MITM nonetheless. It could have been malicious. The user
had no idea, and made no judgment, about the maliciousness of the attack
before surrendering to it. He had been conditioned to dismiss all security
errors.
Rather than thinking "It's a good thing I was protected from this MITM
attacker", he was mad that he was unable to permanently override the error.
Just imagine if he HAD been able to permanently override it. He would have
permanently made himself vulnerable to that MITM attacker.
He proposed (Bug 366191 comment 7) that we take action to permanently
disable this error dialog (by including an unexpired attack cert in our
product, although that would not have had the effect he intended). This
shows that our security error UI is UTTERLY failing to help protect users
from attackers. He still had no idea that he was being attacked, that
the browser had stopped the attack, and that overriding the error was
surrendering to the attack.
I believe that user typifies the majority of FireFox users. I think most
users would hurt themselves in exactly the same way. It's like letting
children play with loaded weapons. Those who know better should be held
accountable when they give those weapons to the children.
The "fix" was to disallow users from overriding security errors for
updates.mozila.org ONLY. Users being MITMed while trying to reach other
servers are fair game, apparently.
If the error message had instead said "Rejoice! Your browser just stopped
an attacker from intercepting your browser's communications with
updates.mozilla.org, and prevented the attacker from pretending that it was
updates.mozilla.org and downloading malicious software to your computer."
and offered no override, the user might have had a different (and more
appropriate) reaction.
Imagine a bank vault door with a button on it that says "If the door
isn't unlocked and open, press here and it will open immediately."
Would you say that bank is protecting the security of its depositors?
How is that different from what Firefox does now?
How much longer will FireFox go on conditioning its users to override
every security error that comes along?
Comment 12•18 years ago
|
||
(In reply to comment #11)
> The "fix" was to disallow users from overriding security errors for
> updates.mozila.org ONLY. Users being MITMed while trying to reach other
> servers are fair game, apparently.
What makes you think that was the fix? The behavior even before that patch landed was to not show security dialogs at all for App Update checks (i.e. return false from all of nsIBadCertHandler's methods), the patch simply extended that behavior to extension update checks, and added a check that the certificate being used was derived from one in the default root store.
I don't think anyone agrees that prompting the user to make a decision in this case is a good idea, and I thought bug 366191 comment 6 makes that pretty clear.
Comment 13•18 years ago
|
||
(In reply to comment #12)
> I thought bug 366191 comment 6 makes that pretty clear.
Sorry, I meant bug 366191 comment 4.
Comment 14•18 years ago
|
||
Gavin,
Surely you don't deny that the fix was only for updates.mozilla.org (or *.mozilla.org) ?
Comment 15•18 years ago
|
||
(In reply to comment #14)
> Gavin,
> Surely you don't deny that the fix was only for updates.mozilla.org (or
> *.mozilla.org) ?
If you mean that the fix only applies to software and extension update, I agree. I don't see how it is limited to any specific domains, though. Both extension and app update can (and do, in practice) connect to sites other than *.mozilla.[com|org], and when they do, the code will behave correctly (i.e. not show any UI and fail silently) when a bad cert error is encountered.
If you're advocating for similar changes to "normal" web browsing, you're doing it in the wrong place - this bug (and bug 366191) are only about update requests.
Assignee | ||
Updated•17 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•