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)

defect
Not set
normal

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.
Huh, I thought this was fixed long ago in bug 304286.
Whiteboard: [sg:low]
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.
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]
Whiteboard: [sg:moderate] → [sg:moderate] bug 340198 came back?
(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?
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.
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?
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.
We consider "UI issues" that are likely to result in compromised computers to be vulnerabilities.
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
(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.
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?
(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.
(In reply to comment #12) > I thought bug 366191 comment 6 makes that pretty clear. Sorry, I meant bug 366191 comment 4.
Gavin, Surely you don't deny that the fix was only for updates.mozilla.org (or *.mozilla.org) ?
(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.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.