Closed Bug 1468549 Opened 6 years ago Closed 4 years ago

BLRG-PT-18-007: Update via Insecure Channels

Categories

(Toolkit :: Application Update, defect, P5)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jvehent, Unassigned)

References

Details

(Keywords: sec-low, Whiteboard: [iu_tracking])

For the update process, an XML file was downloaded via HyperText Transfer Protocol Secure (HTTPS) which contained links to the update files itself. These files were downloaded via HyperText Transfer Protocol (HTTP).

This increased the attack surface since the transfer via HTTP was neither encrypted, nor authenticated. The process afterwards verified the signatures of the download, but this exposed additional code to an attacker, without the need to. Additionally, this leaked meta-data about the platform of the user.

Furthermore, no certificate pinning for the download of the XML file was implemented and Transport Layer Security (TLS) 1.3 was disabled in the code. This weakened the whole update process.

The testers are aware, that this feature was implemented in this manner to enable updates in organizations, where Man-in-the-middle Attack (MitM) attacks are implemented as a controlling measure. Nevertheless, this weakens the security for everyone, who is not residing in such a network.

X41 D-Sec GmbH advises to reduce the attack surface by implementing certificate pinning and HTTPS downloads with an option do disable this via e.g. group policies. If the update servers are not reachable for a period of time a warning should be displayed to the user with the option to try updating with the less secure method.
Priority: -- → P5
Julien, I see that you added a dependency on bug 1304782 which I prefer over certificate pinning since there is no transparent method to handle the known issues with certificate pinning that will prevent a client from updating. Are you satisfied with bug 1304782 as a solution for this bug? Thanks!
Flags: needinfo?(jvehent)
Yes, I think bug 1304782 and bug 1444399 (without cert pinning) together are the right solutions to this bug.
Depends on: 1444399
Flags: needinfo?(jvehent)
Group: toolkit-core-security → firefox-core-security
QA Contact: jmathies
Whiteboard: [iu_tracking]
Priority: P5 → P2
Priority: P2 → P5

I don't understand why pinning is an issue here: we already ignore pins for non-default roots precisely to enable this scenario. Otherwise, nobody behind an enterprise MITM box would be able to use any pinned site.

We recently started serving the update files over https on dev-edition (see bug 1444406). The intent is to monitor telemetry and expand the change out to other channels if everything looks good.

We completed the rollout for all channels to serve updates over https via 1444406 several weeks ago. As we haven't seen anything alarming in telemetry, I'm going to go ahead and close this out.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Group: firefox-core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.