CVE or CWE for using/accepting wrong CA to certify a certificate?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

CVE or CWE for using/accepting wrong CA to certify a certificate?

Jeffrey Walton
I'm looking for the proper/correct CWE to use for a vulnerability. The
vulnerability is: the software selects the wrong CA to certify an
end-entity certificate (for example, server certificate). This is a
common problem when using, for example, the browser security model due
to the collection "pre-trusted" CAs the browsers carry around. But I'm
not worried about browsers.

While the browsers have a hard, generalized problem to solve, a lot of
client software does not suffer the generalized problem. That is, they
know exactly who they should be creating a secure channel with.

So I need a CVE or CWE to use when the client knows exactly who they
should be talking to (or who should certify the server), but choose to
select an incorrect parameter (i.e., selected the wrong CA to
certifythe site).

Here are some candidates, but they not are as good a fit as I would like:

 * CWE-295: Improper Certificate Validation
 * CWE-300: Channel Accessible by Non-endpoint
 * CWE-807: Reliance on Untrusted Inputs in a Security Decision

The more I look at it and think about it, I feel like there may be a
need for a new CVE or CWE because the application used the wrong
security model, which made them select the wrong parameter, and
resulted in an incorrect outcome.

What CVE or CWE I should be using?

Thanks in advance.

.
Reply | Threaded
Open this post in threaded view
|

Re: CVE or CWE for using/accepting wrong CA to certify a certificate?

Pascal Meunier
Jeffrey,

What you describe clearly seems to be an instance of CWE-295: "Improper
Certificate Validation", except that it has no child describing this particular
variant.  I believe creating such a child would make sense (something like
"Improper Validation of Certificate with valid but unwanted CA").  I think it's
a valid concept to not want to accept certificates from some CAs, or require
that a certificate come from a specific CA (or white list of CAs).

I also see that under CWE-254, "security features", there is no allowance made
for someone selecting an incorrect option or parameter when calling a security
library. Libraries can be complex, which increases the likelihood of using one
incorrectly.  It could be considered, in a way, similar to an off-by-one buffer
overflow in that using the library is error-prone.  Perhaps there could be a
CWE like "Incorrect use of a security library".  Does that match with your
thinking?  I think we should avoid having to define something subjective like
"error-prone" or "complex".

I would suggest using CWE-295 for now.  Do you have a specific CVE in mind that
could serve as an example?  It would help this discussion and CWE creation.

Regards,
Pascal

On Mon, 22 Dec 2014 17:34:59 -0500
Jeffrey Walton <[hidden email]> wrote:

> I'm looking for the proper/correct CWE to use for a vulnerability. The
> vulnerability is: the software selects the wrong CA to certify an
> end-entity certificate (for example, server certificate). This is a
> common problem when using, for example, the browser security model due
> to the collection "pre-trusted" CAs the browsers carry around. But I'm
> not worried about browsers.
>
> While the browsers have a hard, generalized problem to solve, a lot of
> client software does not suffer the generalized problem. That is, they
> know exactly who they should be creating a secure channel with.
>
> So I need a CVE or CWE to use when the client knows exactly who they
> should be talking to (or who should certify the server), but choose to
> select an incorrect parameter (i.e., selected the wrong CA to
> certifythe site).
>
> Here are some candidates, but they not are as good a fit as I would like:
>
>  * CWE-295: Improper Certificate Validation
>  * CWE-300: Channel Accessible by Non-endpoint
>  * CWE-807: Reliance on Untrusted Inputs in a Security Decision
>
> The more I look at it and think about it, I feel like there may be a
> need for a new CVE or CWE because the application used the wrong
> security model, which made them select the wrong parameter, and
> resulted in an incorrect outcome.
>
> What CVE or CWE I should be using?
>
> Thanks in advance.
>
> .
>


.
Reply | Threaded
Open this post in threaded view
|

Re: CVE or CWE for using/accepting wrong CA to certify a certificate?

Jeffrey Walton
Hi Pascal,

On Tue, Dec 23, 2014 at 12:48 PM, Pascal Meunier
<[hidden email]> wrote:
> Jeffrey,
>
> What you describe clearly seems to be an instance of CWE-295: "Improper
> Certificate Validation",

Perfect, thanks.

> except that it has no child describing this particular
> variant.

OK, that seems to be why I was having the trouble (finding a child
that represented the problem).

> I believe creating such a child would make sense (something like
> "Improper Validation of Certificate with valid but unwanted CA").  I think it's
> a valid concept to not want to accept certificates from some CAs, or require
> that a certificate come from a specific CA (or white list of CAs).

+1.

Its going to get even better. Public Key Pinning
(https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21) is
getting ready to go live, and its usually the preferred security
control to stop the CA Zoo games (among other problems, like
conferring trust). Unfortunately, the draft has a hole so large you
could drive a truck trough it.

The hole is the attacker can break a good pinset and intercept the
traffic using a non-genuine certificate. That's the exact problem
pinning usually stops! Its cloaked under Sections 2.6 and 2.7. Worse,
its not even mentioned in Security Considerations.

Related: here's the question that teased out the ability of an
attacker to break a good pinset: "Question on Pinning Overrides",
https://www.ietf.org/mail-archive/web/websec/current/msg02255.html.

Related: the discussion spilled over into the TLS Working Group
because of the IETF's propensity to accommodate/support interception.
The reason why the hole was inserted into PKP was browsers would not
implement it otherwise: "Re: Rethink TLS 1.3",
https://www.ietf.org/mail-archive/web/tls/current/msg14722.html.

(It came up under "Rethink TLS 1.3" because assumptions were made
about TLS's security goals and threat models (both of which don't
exist). So it was an incorrect assumption to think interception
resistance was a security goal. In fact, the IETF seems to accommodate
or promote interception. And folks like the NSA, GCHQ, and oppressive
regimes thanks them).

> I also see that under CWE-254, "security features", there is no allowance made
> for someone selecting an incorrect option or parameter when calling a security
> library. Libraries can be complex, which increases the likelihood of using one
> incorrectly.  It could be considered, in a way, similar to an off-by-one buffer
> overflow in that using the library is error-prone.  Perhaps there could be a
> CWE like "Incorrect use of a security library".  Does that match with your
> thinking?
I'm neutral on this (I'm probably not the person to ask). I'm happy
with CWE-295, especially if it has a child that specifically matches
the case of using the wrong CA to certify the certificate (i.e., the
binding of the name to the public key).

> I would suggest using CWE-295 for now.

Perfect, thanks.

> Do you have a specific CVE in mind that
> could serve as an example?  It would help this discussion and CWE creation.

One of the earliest example I found was on Rapid7's website from 2009,
but it does not have a CVE or CWE:
http://www.rapid7.com/db/vulnerabilities/tls-untrusted-ca

Rapid7's issue appears to be slightly different. It appears to state a
CA (self-signed with CA=TRUE) is used but the CA does not reside in
the trusted store. But I might be splitting hairs.

Jeff
Reply | Threaded
Open this post in threaded view
|

Re: CVE or CWE for using/accepting wrong CA to certify a certificate?

Pascal Meunier
Jeffrey,
        From the links you provided, it seems you are concerned about:

a) Social engineering attacks convincing users to install CA certificates or to
otherwise disable pinning in their UA as a configuration option;

b) Third parties who have administrative control over devices, modifying the
UA's configuration surreptitiously.
 
        My understanding is that you are advocating that UAs should not have a
        method to disable pinning, and you consider the above broken by design.
        However, I think this is a classic case of conflict between usability
        vs marginal security gains, and also a question of acceptability of
        security controls ("principle of psychological acceptability"). Many
        users and corporations legitimately want their UAs to work with SSL
        proxys regardless of pinning headers sent by a web site.  It seems to
        me that allowing pinning to be disabled is justifiable for the sake of
        usability.  How much this opens an opportunity for social engineering
        depends on the implementation.  Your concern is understandable, but we
        may just have to live with this.  Even if browser vendors provided by
        default a version that didn't allow disabling pinning, a version that
        did would be necessary (i.e., it would be strongly requested until the
        browser vendor agreed to provide it). At that point social engineering
        becomes possible again, by convincing users to install the version that
        allows disabling pinning. I believe there is no practical way to avoid
        this entirely.

        Regarding the second point, I believe that the battle was lost before
        it began, especially in the Nokia example.  If a device is under
        administrative control of a third party, the UA itself could be
        modified to disregard pinning while fooling the user, regardless of the
        IETF specification. That is, even if the IETF specification did not
        allow disabling pinning, an attacker with administrative control could
        presumably do it.  

        I still think a child CWE entry for using an unwanted CA would make
        sense, but I would question its use in this context.

Pascal


On Tue, 23 Dec 2014 15:26:30 -0500
Jeffrey Walton <[hidden email]> wrote:

> Hi Pascal,
>
> On Tue, Dec 23, 2014 at 12:48 PM, Pascal Meunier
> <[hidden email]> wrote:
> > Jeffrey,
> >
> > What you describe clearly seems to be an instance of CWE-295: "Improper
> > Certificate Validation",
>
> Perfect, thanks.
>
> > except that it has no child describing this particular
> > variant.
>
> OK, that seems to be why I was having the trouble (finding a child
> that represented the problem).
>
> > I believe creating such a child would make sense (something like
> > "Improper Validation of Certificate with valid but unwanted CA").  I think
> > it's a valid concept to not want to accept certificates from some CAs, or
> > require that a certificate come from a specific CA (or white list of CAs).
>
> +1.
>
> Its going to get even better. Public Key Pinning
> (https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21) is
> getting ready to go live, and its usually the preferred security
> control to stop the CA Zoo games (among other problems, like
> conferring trust). Unfortunately, the draft has a hole so large you
> could drive a truck trough it.
>
> The hole is the attacker can break a good pinset and intercept the
> traffic using a non-genuine certificate. That's the exact problem
> pinning usually stops! Its cloaked under Sections 2.6 and 2.7. Worse,
> its not even mentioned in Security Considerations.
>
> Related: here's the question that teased out the ability of an
> attacker to break a good pinset: "Question on Pinning Overrides",
> https://www.ietf.org/mail-archive/web/websec/current/msg02255.html.
>
> Related: the discussion spilled over into the TLS Working Group
> because of the IETF's propensity to accommodate/support interception.
> The reason why the hole was inserted into PKP was browsers would not
> implement it otherwise: "Re: Rethink TLS 1.3",
> https://www.ietf.org/mail-archive/web/tls/current/msg14722.html.
>
> (It came up under "Rethink TLS 1.3" because assumptions were made
> about TLS's security goals and threat models (both of which don't
> exist). So it was an incorrect assumption to think interception
> resistance was a security goal. In fact, the IETF seems to accommodate
> or promote interception. And folks like the NSA, GCHQ, and oppressive
> regimes thanks them).
>
> > I also see that under CWE-254, "security features", there is no allowance
> > made for someone selecting an incorrect option or parameter when calling a
> > security library. Libraries can be complex, which increases the likelihood
> > of using one incorrectly.  It could be considered, in a way, similar to an
> > off-by-one buffer overflow in that using the library is error-prone.
> > Perhaps there could be a CWE like "Incorrect use of a security library".
> > Does that match with your thinking?
> I'm neutral on this (I'm probably not the person to ask). I'm happy
> with CWE-295, especially if it has a child that specifically matches
> the case of using the wrong CA to certify the certificate (i.e., the
> binding of the name to the public key).
>
> > I would suggest using CWE-295 for now.
>
> Perfect, thanks.
>
> > Do you have a specific CVE in mind that
> > could serve as an example?  It would help this discussion and CWE creation.
>
> One of the earliest example I found was on Rapid7's website from 2009,
> but it does not have a CVE or CWE:
> http://www.rapid7.com/db/vulnerabilities/tls-untrusted-ca
>
> Rapid7's issue appears to be slightly different. It appears to state a
> CA (self-signed with CA=TRUE) is used but the CA does not reside in
> the trusted store. But I might be splitting hairs.
>
> Jeff
>
Reply | Threaded
Open this post in threaded view
|

Re: CVE or CWE for using/accepting wrong CA to certify a certificate?

Jeffrey Walton
>         My understanding is that you are advocating that UAs should not have a
>         method to disable pinning, and you consider the above broken by design.
>         However, I think this is a classic case of conflict between usability
>         vs marginal security gains,

I'm not sure I'd consider pinning a marginal security gain. Its like
SSH's StrictHostKeyChecking option. We either talk to the expected
server, or we don't (and fail).

>         users and corporations legitimately want their UAs to work with SSL
>         proxys regardless of pinning headers sent by a web site.  It seems to
>         me that allowing pinning to be disabled is justifiable for the sake of
>         usability.

As a user, I don't want the connection intercepted. Period. I'd rather
the connection fail.

As a website operator, I don't want the connection intercepted.
Period. I'd rather the connection fail.

I could switch to plain text if I wanted my traffic sprayed all over
the web and save the CPU cycles.

Also note: PKP also decided to forgo policy where the domain could set
the policy appropriate for its security posture. Instead, they choose
that everyone has an opportunity to be intercepted, whether they want
it or not.

>         I still think a child CWE entry for using an unwanted CA would make
>         sense ...

Yes, the CWE will be very helpful.

Jeff

On Tue, Dec 23, 2014 at 11:01 PM, Pascal Meunier
<[hidden email]> wrote:

> Jeffrey,
>         From the links you provided, it seems you are concerned about:
>
> a) Social engineering attacks convincing users to install CA certificates or to
> otherwise disable pinning in their UA as a configuration option;
>
> b) Third parties who have administrative control over devices, modifying the
> UA's configuration surreptitiously.
>
>         My understanding is that you are advocating that UAs should not have a
>         method to disable pinning, and you consider the above broken by design.
>         However, I think this is a classic case of conflict between usability
>         vs marginal security gains, and also a question of acceptability of
>         security controls ("principle of psychological acceptability"). Many
>         users and corporations legitimately want their UAs to work with SSL
>         proxys regardless of pinning headers sent by a web site.  It seems to
>         me that allowing pinning to be disabled is justifiable for the sake of
>         usability.  How much this opens an opportunity for social engineering
>         depends on the implementation.  Your concern is understandable, but we
>         may just have to live with this.  Even if browser vendors provided by
>         default a version that didn't allow disabling pinning, a version that
>         did would be necessary (i.e., it would be strongly requested until the
>         browser vendor agreed to provide it). At that point social engineering
>         becomes possible again, by convincing users to install the version that
>         allows disabling pinning. I believe there is no practical way to avoid
>         this entirely.
>
>         Regarding the second point, I believe that the battle was lost before
>         it began, especially in the Nokia example.  If a device is under
>         administrative control of a third party, the UA itself could be
>         modified to disregard pinning while fooling the user, regardless of the
>         IETF specification. That is, even if the IETF specification did not
>         allow disabling pinning, an attacker with administrative control could
>         presumably do it.
>
>         I still think a child CWE entry for using an unwanted CA would make
>         sense, but I would question its use in this context.
>
> Pascal
>
>
> On Tue, 23 Dec 2014 15:26:30 -0500
> Jeffrey Walton <[hidden email]> wrote:
>
>> Hi Pascal,
>>
>> On Tue, Dec 23, 2014 at 12:48 PM, Pascal Meunier
>> <[hidden email]> wrote:
>> > Jeffrey,
>> >
>> > What you describe clearly seems to be an instance of CWE-295: "Improper
>> > Certificate Validation",
>>
>> Perfect, thanks.
>>
>> > except that it has no child describing this particular
>> > variant.
>>
>> OK, that seems to be why I was having the trouble (finding a child
>> that represented the problem).
>>
>> > I believe creating such a child would make sense (something like
>> > "Improper Validation of Certificate with valid but unwanted CA").  I think
>> > it's a valid concept to not want to accept certificates from some CAs, or
>> > require that a certificate come from a specific CA (or white list of CAs).
>>
>> +1.
>>
>> Its going to get even better. Public Key Pinning
>> (https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21) is
>> getting ready to go live, and its usually the preferred security
>> control to stop the CA Zoo games (among other problems, like
>> conferring trust). Unfortunately, the draft has a hole so large you
>> could drive a truck trough it.
>>
>> The hole is the attacker can break a good pinset and intercept the
>> traffic using a non-genuine certificate. That's the exact problem
>> pinning usually stops! Its cloaked under Sections 2.6 and 2.7. Worse,
>> its not even mentioned in Security Considerations.
>>
>> Related: here's the question that teased out the ability of an
>> attacker to break a good pinset: "Question on Pinning Overrides",
>> https://www.ietf.org/mail-archive/web/websec/current/msg02255.html.
>>
>> Related: the discussion spilled over into the TLS Working Group
>> because of the IETF's propensity to accommodate/support interception.
>> The reason why the hole was inserted into PKP was browsers would not
>> implement it otherwise: "Re: Rethink TLS 1.3",
>> https://www.ietf.org/mail-archive/web/tls/current/msg14722.html.
>>
>> (It came up under "Rethink TLS 1.3" because assumptions were made
>> about TLS's security goals and threat models (both of which don't
>> exist). So it was an incorrect assumption to think interception
>> resistance was a security goal. In fact, the IETF seems to accommodate
>> or promote interception. And folks like the NSA, GCHQ, and oppressive
>> regimes thanks them).
>>
>> > I also see that under CWE-254, "security features", there is no allowance
>> > made for someone selecting an incorrect option or parameter when calling a
>> > security library. Libraries can be complex, which increases the likelihood
>> > of using one incorrectly.  It could be considered, in a way, similar to an
>> > off-by-one buffer overflow in that using the library is error-prone.
>> > Perhaps there could be a CWE like "Incorrect use of a security library".
>> > Does that match with your thinking?
>> I'm neutral on this (I'm probably not the person to ask). I'm happy
>> with CWE-295, especially if it has a child that specifically matches
>> the case of using the wrong CA to certify the certificate (i.e., the
>> binding of the name to the public key).
>>
>> > I would suggest using CWE-295 for now.
>>
>> Perfect, thanks.
>>
>> > Do you have a specific CVE in mind that
>> > could serve as an example?  It would help this discussion and CWE creation.
>>
>> One of the earliest example I found was on Rapid7's website from 2009,
>> but it does not have a CVE or CWE:
>> http://www.rapid7.com/db/vulnerabilities/tls-untrusted-ca
>>
>> Rapid7's issue appears to be slightly different. It appears to state a
>> CA (self-signed with CA=TRUE) is used but the CA does not reside in
>> the trusted store. But I might be splitting hairs.