808979 - Provide about:config choice to allow reversion of Bug 728831

Status: UNCONFIRMED

(Firefox :: Settings UI, enhancement)

Description

[Matthew Atkinson]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121031065642

Steps to reproduce:

Tried to block vulnerable Firefox version 16.0 at our outgoing proxy


Actual results:

Version 16.0.1 was reported as being version 16.0


Expected results:

I should be able to distinguish between version 16.0 and 16.0.1 so that I can safely ban version 16.0

Comment 1

[Matthew Atkinson]

I can entirely understand why Bug 728831 was written, but in a controlled environment it unfortunately has exactly the opposite effect from what was intended, i.e. it makes things less secure.

This bug has been raised to allow the previous way of working to be chosen by changing a configuration setting. As this is a specialised change, no UI is anticipated to be necessary.

Comment 2

[Gervase Markham [:gerv]]

If you have the ability to roll out this config change to all Firefoxes in your organization, why do you not have the ability to roll out an upgrade to 16.0.1?

Gerv

Comment 3

[Matthew Atkinson]

We currently have no way to upgrade software on all our PCs, though we do have scripts which change things like prefs.js at login

Comment 4

[Gervase Markham [:gerv]]

It seems to me that this facility would only be useful when:

- There was a serious security-affecting difference between version X.0.N and X.0.N+1
- The organization used perimeter traffic-checking as a security enforcement mechanism
- An organization had the ability to change prefs.js but not to force upgrade Firefox
- The organization was able to find out about the preference and set it

Therefore, I do not see the applicability of such a preference as being very wide.

Gerv

Comment 5

[Matthew Atkinson]

- There was a serious security-affecting difference between version X.0.N and X.0.N+1

Isn't that the only reason that version X.0.N+1 would be released?

I think your second criterion will be often satisfied, though I do accept that criteria 3 and 4 may be less often satisfied

Comment 6

[Gervase Markham [:gerv]]

(In reply to Matthew Atkinson from comment #5)
> - There was a serious security-affecting difference between version X.0.N
> and X.0.N+1
> 
> Isn't that the only reason that version X.0.N+1 would be released?

Well, OK :-) But perhaps then my criteria don't capture the issue, because I've never before heard of an organization doing most-recent-version Firefox enforcement via firewall user-agent sniffing.

Gerv

Comment 7

[Ben Bucksch (:BenB)]

I agree with Gerv. If this is your organization, and you can roll out prefs, and you are concerned about security, then you should be able to roll out software updates, too. Being about to roll out software updates is of uttermost importance for security. A firewall check for the UA string will only help this particular case, but will not help Flash, Java and other software which also routinely has security holes and must be updated. Therefore, this is not a reasonable usecase. Please adapt your organization to be able to roll out software updates directly. *That* is important for your security.

Suggest WONTFIX.

Comment 8

[Ben Bucksch (:BenB)]

http://www.securelist.com/en/analysis/204792250/IT_Threat_Evolution_Q3_2012
Skip to "Exploits: Java vulnerabilities are used in more than half of all attacks"

Comment 9

[rsx11m]

We had some of this discussion in Core bug 572659 (which was building the basis for Firefox bug 728831) and also the related bug 572661/bug 588909 on the build date. In the ideal world you'd have centralized control over all of the computers used at your place and thus can ensure that everything is up to date. I sure agree that this is the optimum case. However, in heterogeneous environments that may not be feasible, and if users maintain their own machines to some extent (or bring in their own laptops) you may need to "somehow" check if there are users which need to be followed-up upon to make them aware that they have to do something with their computers.

I'm still not seeing the evidence that suppressing the patch level has any effect on actual security of an installation, and it's impact on fingerprinting should be neglectable in comparison with other identifying items (especially in the world of rapid releases). But anyway, those changes now happened. Making them configurable similar to the Firefox/x.0 compatibility token in the UA string for those who need it for some purpose sounds feasible, though this would certainly increase fingerprintability quite a bit as not many users would choose to do that.

As an alternative solution to drive-by checking of the browser version you can indirectly guess it from navigator.buildID, making sure that a recent date is returned as the build date. This can be done on your internal web pages but not on the firewall without injecting some JavaScript into the traffic, thus may not be a solution for your setup.

Comment 10

[Matthew Atkinson]

I agree with those posters who suggest that patching is more complex than just the browser. However, we are a mainly Windows site, and as many of you will know, keeping Windows systems up to date is an awful lot more complex and individual than for almost all other Operating Systems. As a result, we block old Browsers at the proxy, which is simple to do, and wish we could do more. Maybe we ought to upgrade to a better OS.

I accept that publishing the full user string would increase fingerprinting (though we could always re-suppress it at the proxy anyway), but you would only do this where you were ensuring that all it told a server is that you were fully patched, so the security issue should be a moot point. 

(interestingly, fingerprinting my Browser (FF 17 Beta on XP) had it as unique out of about 2.5M computers even without the end of the user string)

Comment 11

[Henri Sivonen (:hsivonen)]

(In reply to Matthew Atkinson from comment #10)
> However, we are a mainly Windows site
...
> we block old Browsers at the proxy

What do you do to block people from accessing the Web with unpatched IE?

Comment 12

[Matthew Atkinson]

We block IE entirely at the firewall as it's not used. This stops dangerous things like Active-X.

Comment 13

[Ben Bucksch (:BenB)]

If you block FF 15 and below, you already catch the vast majority of lazy upgraders. The people who have 16.0.0, but not 16.0.1 will be minor. More importantly, this difference is absolutely neglectable compared to the threat from Java and Acrobat. Instead of keeping your hack at perfection, I suggest you concentrate on fixing these widely open ends. If you do solve Java and Flash and Acrobat, you will also have solved the Firefox patch level problem at the same time.