867928 - clickjacking certificate install dialog can add untrusted root certificate.

Status: RESOLVED FIXED

(Core :: Security: PSM, defect, P5)

Description

[Jordi Chancel]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130409194949

Steps to reproduce:

with a double click , it's possible to instal a malicious secure certificate.


Actual results:

go to http://alternativ-testing.fr/Research/Mozilla/0daysslcertificateclickjacking57ef5758uybtuyb/Critical%20clickjacking%20install%20SSL%20certificate2.htm and doubleclick on the link . the secure certificate will be instaled automatically after the doubleclick.


Expected results:

the secure certificate will be instaled automatically after the doubleclick.

Comment 1

[Jordi Chancel]

Attachment: Exploit in the ZIP

Comment 2

[Jordi Chancel]

video of the exploit : http://www.youtube.com/watch?v=nKj6Ct9Z8qQ&feature=youtu.be

Comment 3

[Jordi Chancel]

Attachment: 0day in the zip

Comment 4

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: PoC php

Comment 5

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: Poc HTML

Comment 6

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

Attachment: PoC pem/cert

Comment 7

[David Chan [:dchan]]

This is similar to the set of bugs that Jesse reported against the UI and double clicking. See bug 162020. I think this is a sec-moderate or sec-vector. The impact / damage increases once a user installs the certificate.

Comment 8

[Jordi Chancel]

it's not only moderate , instal a malicious certificate with a double click is high or critical but not moderate !
view this bug => https://bugzilla.mozilla.org/show_bug.cgi?id=825022

Comment 9

[Jordi Chancel]

I'm sure that this vulnerability is high at worst !

Comment 10

[David Chan [:dchan]]

Jordi:

We'll reevaluate the rating at the bug-bounty meeting this week. I don't believe this bug is at the same level as the TurkTrust issue. The TurkTrust issue resulted in all FireFox users with the TurkTrust cert being vulnerable to SSL interception.

Your attack has a much smaller affected userbase. The worst case scenario that I see is a rogue ISP injecting this code onto HTTP sites to MITM their users. This could be a sec-high.

Comment 11

[Jordi Chancel]

Yes David Chan , I'm sure that this vulnerability is HIGH.

Comment 12

[Jordi Chancel]

(In reply to David Chan [:dchan] from comment #10)
> Jordi:
> 
> We'll reevaluate the rating at the bug-bounty meeting this week. 
> 
> The worst case scenario that I see is a rogue ISP injecting this
> code onto HTTP sites to MITM their users. This could be a sec-high.

Comment 13

[Daniel Veditz [:dveditz]]

It's installed (potentially--your PoC is off for me but I assume that can be fixed) but it's not trusted for anything unless you also check one or more of the trust boxes. It could be confusing and scary for users to find a unknown root in their certificate database but it's not actually harmful. An attacker /might/ be able to convince someone to then go through the steps to trust the cert, but it seems just as likely that if you found a victim that trusting/gullible you could just get them to accept the cert without the clickjacking issue.

Comment 14

[Daniel Veditz [:dveditz]]

This bug does not qualify for a bug bounty unless there's some additional trick to make this a trusted root.

Comment 15

[Kai Engert (:KaiE:)]

We should investigate if this could be used for denial-of-service attack.

If an attacker installs a CA cert that uses the same subject name as one of the trusted roots, but contains a newer date, then NSS *might* prefer it when searching for certificates. I'm not sure, but I'm worried that NSS might select an invalid issuer cert with a newer date, even if the newer one isn't trusted.

Comment 17

[Dana Keeler (she/her) (use needinfo) [:keeler]]

We could add a delay to the "OK" button or something (although see also bug 1024871).

Comment 18

[Daniel Veditz [:dveditz]]

making this bug visible to more developers (specifically the front-end security folks)

Comment 19

[:Gijs (he/him)]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #17)
> We could add a delay to the "OK" button or something

From the looks of this, on the assumption the dialog uses commonDialog.xul, this is just an extra arg away. Even if not using commonDialog.xul, it looks like the functionality was abstracted into a jsm that *should* be easily adaptable, see:

https://dxr.mozilla.org/mozilla-central/rev/45fde181a497a187d01d5412f5b72897c7520517/toolkit/components/prompts/src/CommonDialog.jsm#169-175

and resource://gre/modules/SharedPromptUtils.jsm .

Comment 20

[Daniel Veditz [:dveditz]]

This was fixed by removing the underlying feature in bug 1024871