Closed Bug 679742 Opened 13 years ago Closed 2 years ago

Firefox/Nightly claims "up to date" despite being unable to check for updates.

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1643309

People

(Reporter: KaiE, Unassigned)

References

Details

Attachments

(1 file)

Failed update console log
(deleted), text/plain
Details
If an attacker blocks the connection to aus3.mozilla.org, and consequently Firefox/Nightly is unable to check for updates, the about dialog will report "Update to date". This is wrong.
This can easily be reproduced, just add the following line to your /etc/hosts file (or the equivalent used on your operating system): 127.0.0.1 aus3.mozilla.org
I have filed this bug, because KaiRo asked me to do so. I'm not aware of a good fix for this problem. Let's assume Mozilla update service ran a timestamping service. If Firefox contacts the update service, and the reply contains the current timestamp, together with a digital signature, does this help us? No it doesn't. User's clocks are often wrong, as studies have shown. A mismatch between local time and server time would be common. Warnings based on mismatching would be false negatives, Warnings about being up to date could still be false positives. Furthermore, if an attacker were able to abuse a compromised CA, it might be able to produce fake information about most recent versions. I believe this bug is WONTFIX. In my opinion, the only solution to this problem is: - do not use a simplification like "you are up to date" - keep the version number
(In reply to Kai Engert (:kaie) from comment #2) > I believe this bug is WONTFIX. I don't think so, there's a lot of things we can do here. > In my opinion, the only solution to this problem is: > - do not use a simplification like "you are up to date" That's a start. If we have not (successfully, i.e. with getting a valid reply) checked within the last day (or whatever the default period for checking might be in prefs), maybe allowing for some padding, then we should _never_ display "you are up to date" but instead "checking for updates was not possible/successful". In addition, if the version being run (i.e. the build ID) is over a certain threshold (depending on the channel - e.g. a week for nightly, two weeks for aurora, 4 weeks for beta, 12 weeks for release and every other value), then we should also display a message that the version is probably outdated and at a security risk and they should see to get an update. > - keep the version number That's completely independent of this issue. For your other concerns: > User's clocks are often wrong, as studies have shown. A mismatch between > local time and server time would be common. Warnings based on mismatching > would be false negatives, Warnings about being up to date could still be > false positives. I don't see how that makes our situation worse - either something in the About dialog will look wrong to them, like their version is outdated (and we might want to show that for the build ID being in the future as well) or we can actually query some time sources on the web and warn the user if his clock differs too much. We already end up in a pretty bad place with certificates when the time is wrong, the update stuff doesn't make to too much worse. > Furthermore, if an attacker were able to abuse a compromised CA, it might be > able to produce fake information about most recent versions. If an attacker can make Firefox believe his server is our AUS server, then the About dialog is the least of our problems.
See https://support.mozilla.com/en-US/questions/863261 for a slight variation of this (i.e. user is told is not up to date where it is).
I believe I'm having the same symptoms with a different cause. On my work computer, FF 5 release still reports that it's up to date (which it's not anymore). In the past FF has complained about something interfering with checking for updates. That "something" in this case is a corporate Websense server that does a man-in-the-middle on https requests by signing them with its own certificate. Without the certificate installed FF won't go to any site without certificate errors (which is correct). With the websense cert installed things work normally *except* for FF updates, which FF seems to still think are forgeries. I verified the response coming from the update server and it's reporting the correct version as current (6). The net result is that for some reason as a result of all this Help > About reports that FF is up to date even though it either doesn't know, or in my case what appears to be not trusting the response saying it's not. Either way it shouldn't say "up to date" unless it knows that to be true. If it's not, it should say that it can't automatically check for an update.
(In reply to Chris Eaton from comment #5) > That "something" in this case is a corporate Websense server that does a > man-in-the-middle on https requests by signing them with its own > certificate. That IMHO is mostly criminal, but ignoring that, Firefox update rightly only accepts the update website to use one of two very specific certificate roots, so that attacks on users by sending them wrong updates are even harder. All that is not the topic of this bug, though. Still, you are indeed hitting this bug as we should never tell the user that their version is "up to date" when we can't verify that claim, which is also the case in your situation.
(In reply to alex_mayorga from comment #4) > See https://support.mozilla.com/en-US/questions/863261 for a slight > variation of this (i.e. user is told is not up to date where it is). That must be something different, as this bug is about telling the user he is up to date when (s)he isn't, not the other way round.
So, I did some digging and that string in its potentially misleading usage has been introduced by Rob Strong in bug 596813 but it doesn't help that its ui-r (or UI proposal) was beltzner, not sure he still wants to be involved in discussing that. Also, that the string is named for "no updates found" but actually says "up to date" tells the story nicely that the difference between those two messages was not fully thought through.
Depends on: 596813
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8) > So, I did some digging and that string in its potentially misleading usage > has been introduced by Rob Strong in bug 596813 but it doesn't help that its > ui-r (or UI proposal) was beltzner, not sure he still wants to be involved > in discussing that. > > Also, that the string is named for "no updates found" but actually says "up > to date" tells the story nicely that the difference between those two > messages was not fully thought through. This was implemented 100% per the requirements made by the user experience team and that text was specifically asked for that condition.
(In reply to Robert Strong [:rstrong] (do not email) from comment #9) > This was implemented 100% per the requirements made by the user experience > team and that text was specifically asked for that condition. In this case, I think they didn't realize or undervalued the rather problematic case when their version is actually outdated, we can't check and tell them it's current and they freely can get exploited by black hats due to us weighing them in false security.
I am running into this on both 6.0.1 and 6.0.2, release. For the latter, it was after Firefox had downloaded an update on another account, but that update had failed. Fortunately, trying the update again on that account worked. This was Windows 7 Home Premium SP1. The other is a Windows XP Home SP 3 computer that has the flag set not to automatically update. The user heard about Firefox 7, and tried to update from about:, but it still says that Firefox is up to date. This makes even less sense to me, since, even if you are holding out for triggered updates on Firefox 7, 6.0.2 should have still been offered. Both of these computers are on the same network, if this matters. aus3.mozilla.org is can be reached via ping, but https://aus3.mozilla.org redirects me to http://www.mozilla.org I'm sorry if this is the wrong place to put this, but, once again, this is the only place that pops up when I do a Google search for my problem.
(In reply to Terrell Kelley from comment #11) > I am running into this on both 6.0.1 and 6.0.2, release. No you haven't. This bug is about Nightly, and you are talking about releases. Updates to Firefox 7 have been temporarily suspended while we are working on a solution for http://blog.mozilla.com/addons/2011/09/28/issue-discovered-with-firefox-add-on-upgrades/ This bug is about the case where we are _unable_ to check for updates, but your versions can check but just do not get an update offer, in which case "up to date" is the right thing to display.
While I thank you for the information, I cannot see how this bug does not still apply. Firefox is _not_ up-to-date. I can go out right now and download Firefox 7.0. Firefox truly is "_unable_" to check for updates because it appears you guys have shut down the update server. Per this bug, I should be told "an update is unavailable" or "No updates available." That is all Firefox knows. The current text is a lie, and thus appears as a bug to anyone who knows Firefox 7 is out but can't update. Also, I want to point out that, as I stated, the fact that I can't even upgrade to Firefox 6.0.2 led me to believe that the problem was on my end. But I'm loathe to file a new bug unless I know for sure that an old bug does not apply. Hence the rest of my post explaining that I didn't know if the bug applied.
(In reply to Terrell Kelley from comment #13) As stated in comment 12, the Firefox 7 updates are currently turned off. We will be re-enabling updates once Firefox 7.0.1 is released to fix the issue reported here: http://blog.mozilla.com/addons/2011/09/28/issue-discovered-with-firefox-add-on-upgrades/
Terrell, the root cause of this bug is different than what you are experiencing in your comment #11 with your release build. Release builds have updates disabled at this time due to bug 680802 and updates for releases will be re-enabled in bug 689906.
This still happens. I have FF 20.0 on Windows and the about dialog claims it is up to date when clearly it is not, as 20.0.1 was released days ago.
(In reply to David Balažic from comment #20) > This still happens. > I have FF 20.0 on Windows and the about dialog claims it is up to date when > clearly it is not, as 20.0.1 was released days ago. Do you see any errors in Error Console when checking for updates? Can you also provide a copy of the Error Console messages if you set app.update.log to true, restart Firefox, and check for updates? Please attach this info as a plaintext file. Thanks
I already updated to 20.0.1 At that time the had no connectivity. I could probably be reproduced with 20.0.1 too (a task I leave to experienced developers).
My version of the issue is still true. 19.0.2 says that Firefox is up to date in Help > About. Every now and then the error about Firefox being unable to update will pop up, due to Websense rewriting SSL requests and FF thinking the update is being faked. It really shouldn't tell people it's up to date when it doesn't actually know that's the case.
(In reply to Chris Eaton from comment #23) > My version of the issue is still true. 19.0.2 says that Firefox is up to > date in Help > About. Every now and then the error about Firefox being > unable to update will pop up, due to Websense rewriting SSL requests and FF > thinking the update is being faked. > > It really shouldn't tell people it's up to date when it doesn't actually > know that's the case. Please file a new bug specifically about "Websense rewriting SSL requests"... we might be able to handle that condition now with the additional security checks we have added in the last year.
I ran into a variant of this bug on FF 32.0 on OS X. If FF is configured for a SOCKS proxy, and the proxy is down, then going to Preferences -> Check for updates reports that "Firefox is up to date". Should I open a new bug, since the cause is slightly different?
(I don't think it needs a new bug; I don't think we'd need anything specific to address that particular proxy-configured-but-down use-case, other than what's required to fix this main bug here.)
Flags: firefox-backlog?
Flags: firefox-backlog? → firefox-backlog+
Flags: qe-verify?
Still happening today. Currently using Nightly 45.0a1 (2015-11-05), I know 45.0a1 (2015-11-06) is already available, don't know if there are more recent, but when I try to update it, it checks for a new version and then reports that "Nightly is up to day" when it clearly is not. Creating a new profile did not solve the problem.
(In reply to yonezpt from comment #30) > Still happening today. Currently using Nightly 45.0a1 (2015-11-05), I know > 45.0a1 (2015-11-06) is already available, don't know if there are more > recent, but when I try to update it, it checks for a new version and then > reports that "Nightly is up to day" when it clearly is not. > > Creating a new profile did not solve the problem. Could you please add the app.update.log preference and set it to true in about:config? Once that's set and you restart Firefox you should get some update logging information in the Web Console developer tool. Next time the update fails please capture that information and attach it to this bug report.
Flags: qe-verify?
Attached file Failed update console log (deleted) —
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #31) > (In reply to yonezpt from comment #30) > > Still happening today. Currently using Nightly 45.0a1 (2015-11-05), I know > > 45.0a1 (2015-11-06) is already available, don't know if there are more > > recent, but when I try to update it, it checks for a new version and then > > reports that "Nightly is up to day" when it clearly is not. > > > > Creating a new profile did not solve the problem. > > Could you please add the app.update.log preference and set it to true in > about:config? Once that's set and you restart Firefox you should get some > update logging information in the Web Console developer tool. Next time the > update fails please capture that information and attach it to this bug > report. It wasn't posting to the web console (had all log levels enabled, verified one by one) but it posted to the browser console (ctrl + j), the file attached contains the exact log of what happens when I open the about box with the update feature until I close it.
(In reply to yonezpt from comment #32) > Created attachment 8685042 [details] > Failed update console log Thanks, it looks like you're getting empty update snippets. Rob, I'm not sure if you're the right person but would you be able to advise how debug this further?
Flags: needinfo?(robert.strong.bugs)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #33) > (In reply to yonezpt from comment #32) > > Created attachment 8685042 [details] > > Failed update console log > > Thanks, it looks like you're getting empty update snippets. > > Rob, I'm not sure if you're the right person but would you be able to advise > how debug this further? That is correct, if I open the xml file directly it only shows <updates></updates> and nothing else.
Could you guys please file a new bug for the issue discussed in comment 30 - comment 34? This bug here is specifically about the messaging / UI being misleading when updates aren't found, whereas comment 30-34 are about a specific instance of an update not being found & figuring out what's causing that.
Flags: needinfo?(yonezpt)
(In reply to Daniel Holbert [:dholbert] from comment #35) > Could you guys please file a new bug for the issue discussed in comment 30 - > comment 34? > > This bug here is specifically about the messaging / UI being misleading when > updates aren't found, whereas comment 30-34 are about a specific instance of > an update not being found & figuring out what's causing that. Seems to have been fixed today. I was working with Nightly for the past few hours and just now it prompted for an update restart (the notification was very basic with no images unlike usual update prompt box, just text), clicked on it and it worked correctly, using now the most recent Nightly. Sorry for having used this bug, thought the problem would apply here.
Flags: needinfo?(yonezpt)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #33) > (In reply to yonezpt from comment #32) > > Created attachment 8685042 [details] > > Failed update console log > > Thanks, it looks like you're getting empty update snippets. > > Rob, I'm not sure if you're the right person but would you be able to advise > how debug this further? Likely due to something server side and aus5 is now showing an update. Note: after 10 consecutive background check failures (controlled by the app.update.backgroundMaxErrors pref) the user is notified that something is preventing the check along with an url to get the latest version.
Flags: needinfo?(robert.strong.bugs)
So, we do notify the user after 10 consecutive background update check attempts that fail. This is controlled by a Firefox preference so if that number is too large it can always be lowered with a Firefox -> Preferences bug. Note: the text in the about dialog that says Firefox is up to date was decided by Firefox UX way back when and a Firefox bug should be filed if the desired change is to that text since the code and strings are entirely under Firefox.
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #38) > Note: the text in the about dialog that says Firefox is up to date was > decided by Firefox UX way back when and a Firefox bug should be filed if the > desired change is to that text since the code and strings are entirely under > Firefox. It's not that this string needs to change -- it's fine, for the scenario that it describes (where we've received an authoritative response that we are up to date) Rather: I think we need an additional string, for the scenario in this bug, where the update check failed. (And presumably we may need additional logic in this dialog to display that string instead of the currently-used one.) Should that still go in a new bug? (I thought that's what this bug covered all along, kind of...)
Flags: needinfo?(robert.strong.bugs)
(In reply to Daniel Holbert [:dholbert] from comment #39) > (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from > comment #38) > > Note: the text in the about dialog that says Firefox is up to date was > > decided by Firefox UX way back when and a Firefox bug should be filed if the > > desired change is to that text since the code and strings are entirely under > > Firefox. > > It's not that this string needs to change -- it's fine, for the scenario > that it describes (where we've received an authoritative response that we > are up to date) > > Rather: I think we need an additional string, for the scenario in this bug, > where the update check failed. (And presumably we may need additional logic > in this dialog to display that string instead of the currently-used one.) Sorry, I should have been more explicit and I was referring to changing the displayed string which you are quite right in calling it an addition. I wanted to display an error in the About Dialog for this case and it was decided by Firefox UX way back when that it should display the current string and instead rely on the background check failure notification for this case. Whatever the case, the app update UI does display the error and the Firefox About Dialog does not and this change would need to be done in Firefox About Dialog code. > > Should that still go in a new bug? (I thought that's what this bug covered > all along, kind of...) Not saying new bug. I am saying that this was designed this way by Firefox UX and all of the code that would need to be modified is in Firefox itself. For example, Thunderbird would need to be changed to pick up these modifications. So, moving it over to Firefox would be necessary to get Firefox UX to revisit this and to add that string.
Just noticed it was in Firefox -> Security which should be adequate.
Flags: needinfo?(robert.strong.bugs)

Maybe this bug should be relabeled.

If Firefox cannot check if a new update is available, then Firefox shouldn't say "is up to date", but say "searching for updates failed".

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 6 duplicates and 11 votes.
:serg, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(sgalich)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(sgalich)

I think this is a duplicate of bug 1643309

Flags: needinfo?(sgalich)

(In reply to Mathew Hodson from comment #50)

I think this is a duplicate of bug 1643309

I agree.

Status: NEW → RESOLVED
Closed: 2 years ago
Duplicate of bug: 1643309
Resolution: --- → DUPLICATE
Flags: needinfo?(sgalich)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: