5 ms·

"Every time" for this use case is once per browser install, at the moment you perform the authentication with Firefox Sync, which is the same as the number of t

"Every time" for this use case is once per browser install, at the moment you perform the authentication with Firefox Sync, which is the same as the number of times you'd want to verify the binary right before authenticating. The tradeoff they made here has essentially zero impact on the number of times you need to verify their code, it's just a matter of whether you'd have to verify browser native authentication code or authentication code delivered through a website written in JS, at the moment you authenticate. A concern like the one raised in this thread is certainly valid for websites that have expiring sessions, where you can switch accounts and log in and out of. And we certainly do need better tools around signature verification and version pinning for websites like we do for binaries (content-addressed networks like IPFS may have good answers there). But for this use case, it's not a practical concern by any measure, and all this alarmism seems really misdirected.

jniedrauer 8y ago
You're still not addressing the ease with which a targeted attack can be directed at a single user. In order to compromise firefox native code, they would have to compile malicious code and ship it to everyone. My distro maintainers would need to include the malicious binary in their repos, including a signed hash of the compromised binary, and I'd need to install it, where my package manager would verify the hash. In order to compromise a single user's browser session, they'd simply need to fingerprint the user's browser and then serve them different content than everyone else gets. No hashes or signatures on javascript, no safety in numbers, etc.
- rocqua 8y ago
  if someone is using a package-manager that uses code signing then indeed, the binary is harder to attack than the JS. (only because the package-manager would need to collude). However, a lot of people get their software from downloaded .exe's or auto-upgrading installations. For them, JS or binary are equally vulnerable. (All it takes is a mozilla signature) Besides, it is undeniably better to only be vulnerable to an active attack from mozzila, than to be vulnerable against a passive attack from them.
  - cyphar 8y ago
    Most distributions disable auto-upgrade in Firefox, for many reasons (security and auditability being one of the main ones) so you won't get auto-upgrade from a distribution. And even the "download .exes from the internet" usecase is precisely as secure as downloading JS from the internet that is verified once per install. To attack someone who has an auto-updating Firefox and downloaded it from the internet, you need to intercept and attack TLS -- but only when the upgrade happens which is a fairly limited opportunity. The JS attack has the exact same properties if the above comment (that it only gets downloaded once per install) is true. So therefore it is strictly less secure in the optimal case, and it is no more secure in the sub-optimal case. So security really isn't a strong argument (the real argument is that it allows for more "agile development" -- which is an understandable argument if you cop to that being the only reason for such a design).
    - vbezhenar 8y ago
      If you can attack TLS, game is over, you can't trust anything. A huge majority of Firefox users use built-in update mechanisms. Making life harder for majority of users to improve security of the selected few is a questionable decision. And if you're really insisting, you can always install some addon which will calculate hashsum of JavaScript resources.
      - cyphar 8y ago
        > Making life harder for majority of users to improve security of the selected few is a questionable decision I agree in theory, though as an aside this isn't true for distribution packages because usually they are GPG signed with keys that are in TPMs on the release machines. Of course any other internet communication relies on TLS not being broken. But another attack would be modifying one of Firefox's mirrors to host malicious Firefox (not a TLS attack but an attack of a specific mirror). GPG detached signatures for distribution packages protect against this and many other such problems (obviously some attacks against the build servers of a distribution would be problematic, but the same applies for any software project). Though to be fair, I don't know if Firefox's auto-updater uses an update system like TUF or a distribution-style update system (which is mostly equivalent in terms of security) which would protect against these sorts of problems. > Making life harder for majority of users to improve security of the selected few is a questionable decision. I don't understand how logins being built-in to the browser is making life harder for the majority of users. It wouldn't make a difference to them. It would make a difference to the development team, but one could easily argue that the development team should be willing to make life slightly harder for themselves in order to make Firefox users more secure.
- martin-adams 8y ago
  >> then serve them different content than everyone else gets To help my understanding, to achieve an attack like this, would the attacker need to circumvent SSL on the client, or takeover the script serving web server? Or is there another attack vector that I'm not seeing?
  - jniedrauer 8y ago
    The attacker in this case would be Mozilla itself. No need for an MITM. In this hypothetical, a government agency contacts Mozilla and says "Here is a canvas/HSTS/other fingerprint. Please serve this malicious code when this fingerprint accesses the login." The point is that Mozilla can single out individual users for targeted attacks, whereas they could not do that if they had to put the malicious code into Firefox itself.
    - martin-adams 8y ago
      Right I see. So the barrier with Firefox itself, is that the malicious code wouldn't get built into the product and served as an update. However, in that scenario, Firefox could serve a malicious update to a single user, only that it's harder to fingerprint that.
- fulafel 8y ago
  The vast majority of Firefox users receive updates from Mozilla via the auto-update mechanism, which would also be vulnerable to the compromise in a similar way. (A Linux distribution could also be compromised and used in a targeted way of course)

jniedrauer 8y ago

You're still not addressing the ease with which a targeted attack can be directed at a single user. In order to compromise firefox native code, they would have to compile malicious code and ship it to everyone. My distro maintainers would need to include the malicious binary in their repos, including a signed hash of the compromised binary, and I'd need to install it, where my package manager would verify the hash. In order to compromise a single user's browser session, they'd simply need to fingerprint the user's browser and then serve them different content than everyone else gets. No hashes or signatures on javascript, no safety in numbers, etc.

rocqua 8y ago
if someone is using a package-manager that uses code signing then indeed, the binary is harder to attack than the JS. (only because the package-manager would need to collude). However, a lot of people get their software from downloaded .exe's or auto-upgrading installations. For them, JS or binary are equally vulnerable. (All it takes is a mozilla signature) Besides, it is undeniably better to only be vulnerable to an active attack from mozzila, than to be vulnerable against a passive attack from them.
- cyphar 8y ago
  Most distributions disable auto-upgrade in Firefox, for many reasons (security and auditability being one of the main ones) so you won't get auto-upgrade from a distribution. And even the "download .exes from the internet" usecase is precisely as secure as downloading JS from the internet that is verified once per install. To attack someone who has an auto-updating Firefox and downloaded it from the internet, you need to intercept and attack TLS -- but only when the upgrade happens which is a fairly limited opportunity. The JS attack has the exact same properties if the above comment (that it only gets downloaded once per install) is true. So therefore it is strictly less secure in the optimal case, and it is no more secure in the sub-optimal case. So security really isn't a strong argument (the real argument is that it allows for more "agile development" -- which is an understandable argument if you cop to that being the only reason for such a design).
  - vbezhenar 8y ago
    If you can attack TLS, game is over, you can't trust anything. A huge majority of Firefox users use built-in update mechanisms. Making life harder for majority of users to improve security of the selected few is a questionable decision. And if you're really insisting, you can always install some addon which will calculate hashsum of JavaScript resources.
    - cyphar 8y ago
      > Making life harder for majority of users to improve security of the selected few is a questionable decision I agree in theory, though as an aside this isn't true for distribution packages because usually they are GPG signed with keys that are in TPMs on the release machines. Of course any other internet communication relies on TLS not being broken. But another attack would be modifying one of Firefox's mirrors to host malicious Firefox (not a TLS attack but an attack of a specific mirror). GPG detached signatures for distribution packages protect against this and many other such problems (obviously some attacks against the build servers of a distribution would be problematic, but the same applies for any software project). Though to be fair, I don't know if Firefox's auto-updater uses an update system like TUF or a distribution-style update system (which is mostly equivalent in terms of security) which would protect against these sorts of problems. > Making life harder for majority of users to improve security of the selected few is a questionable decision. I don't understand how logins being built-in to the browser is making life harder for the majority of users. It wouldn't make a difference to them. It would make a difference to the development team, but one could easily argue that the development team should be willing to make life slightly harder for themselves in order to make Firefox users more secure.
martin-adams 8y ago
>> then serve them different content than everyone else gets To help my understanding, to achieve an attack like this, would the attacker need to circumvent SSL on the client, or takeover the script serving web server? Or is there another attack vector that I'm not seeing?
- jniedrauer 8y ago
  The attacker in this case would be Mozilla itself. No need for an MITM. In this hypothetical, a government agency contacts Mozilla and says "Here is a canvas/HSTS/other fingerprint. Please serve this malicious code when this fingerprint accesses the login." The point is that Mozilla can single out individual users for targeted attacks, whereas they could not do that if they had to put the malicious code into Firefox itself.
  - martin-adams 8y ago
    Right I see. So the barrier with Firefox itself, is that the malicious code wouldn't get built into the product and served as an update. However, in that scenario, Firefox could serve a malicious update to a single user, only that it's harder to fingerprint that.
fulafel 8y ago
The vast majority of Firefox users receive updates from Mozilla via the auto-update mechanism, which would also be vulnerable to the compromise in a similar way. (A Linux distribution could also be compromised and used in a targeted way of course)