Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

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

Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco)
Hi,

We are using Kerberos (version 1.9) in one of our components. We came across the vulnerability CVE-2017-7562 being reported and fixed in Kerberos 1.16.1.
But we are having difficulty in moving to the latest version of Kerberos, as there are lot of customizations done over the version  of Kerberos (1.9) that we are using.
Hence we are forced to port only the vulnerability fix from Kerberos 1.16.1 to our customized version of Kerberos.

Please find the vulnerability details in the below link

https://nvd.nist.gov/vuln/detail/CVE-2017-7562

But we see a part of code that involves the fix for vulnerability has been refactored to a greater extent and below are some details about that


1.       The changes in the function crypto_retrieve_X509_sans()(In file pkinit_crypto_openssl.c<https://github.com/krb5/krb5/pull/694/commits/07243f85a760fb37f0622d7ff0177db3f19ab025#diff-94591ec7026b3a15b0a4ee416525c766>) hasn't changed much from 1.9 to 10.16.1 and hence it may be relatively easy to port the changes

2.       The changes done in the file pkinit_srv.c<https://github.com/krb5/krb5/pull/694/commits/07243f85a760fb37f0622d7ff0177db3f19ab025#diff-a8d503b19dfddd4a6278777df6276d19> is very tricky to be back ported to 1.9 from 1.16.1. Few details as below

What's done in 1.16.1


a.       The certificate authentication which is done in the function pkinit_server_verify_padata() calls a function authorize_cert().

authorize_cert() checks the certificate against each certauth module. There are three different cert auth modules as san check,

eku check and dbmatch check. Each cert auth module is tried in a loop to know the verification status. Function pointers for which

cert auth module to be called is established in the function load_certauth_plugins(). Now the vulnerability fix is involved in the functions

verify_client_san() and pkinit_eku_authorize() which are part of san check and eku check. eku check has been made to return

KRB5_PLUGIN_NO_HANDLE in success case instead of zero, which means that irrespective of eku succeeding still its return status will be

considered as KRB5_PLUGIN_NO_HANDLE and will be ignored as per the code logic in authorize_cert()






What's the difficulty in backporting this fix to Kerberos 1.9


a.       We don't have function pointers so that we can do the san check and eku check in a loop and port the fix easily and gracefully

b.      There is no dbmatch check in this version and hence can be ignored.

c.       First the san check is done and then the eku check is done which is kind of sequential operation and hence the output of both can't be correlated as it is done in the 1.16.1

What's my ask:


1.       Can there be any patch given for this vulnerability fix over Kerberos 1.9

Or


2.       If I want to backport the changes for this vulnerability fix to our customized version then below would be my approach. The changes done for the function verify_client_san() and can be ported directly

I am giving the details only for the changes that would happen in the file pkinit_srv.c<https://github.com/krb5/krb5/pull/694/commits/07243f85a760fb37f0622d7ff0177db3f19ab025#diff-a8d503b19dfddd4a6278777df6276d19> and in the function pkinit_server_verify_padata() where verify_client_san and verify_client_eku are invoked sequentially



if (is_signed) {



+        krb5_boolean accepted = TRUE;

        retval = verify_client_san(context, plgctx, reqctx, request->client,

                                   &valid_san);

+        if (retval == ENOENT)

+        {

+            accepted = FALSE;

+        }

+        else

+        {

            if (retval)

                goto cleanup;

            if (!valid_san) {

                pkiDebug("%s: did not find an acceptable SAN in user "

                         "certificate\n", __FUNCTION__);

                retval = KRB5KDC_ERR_CLIENT_NAME_MISMATCH;

                goto cleanup;

            }

+        }

        retval = verify_client_eku(context, plgctx, reqctx, &valid_eku);

        if (retval)

            goto cleanup;



        if (!valid_eku) {

            pkiDebug("%s: did not find an acceptable EKU in user "

                     "certificate\n", __FUNCTION__);

            retval = KRB5KDC_ERR_INCONSISTENT_KEY_PURPOSE;

            goto cleanup;

        }



+        if (accepted != TRUE)

+        {

+            retval = KRB5KDC_ERR_CLIENT_NAME_MISMATCH;

+            goto cleanup;

+        }

    }


Any help on this is much appreciated and most required.

Thanks and Regards!
Shiva





_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

Greg Hudson
On 09/21/2018 02:04 AM, Shivakumar Nadarajan -X (shinadar - HCL
TECHNOLOGIES LIMITED at Cisco) wrote:> We are using Kerberos (version
1.9) in one of our components. We came across the vulnerability
CVE-2017-7562 being reported and fixed in Kerberos 1.16.1.

CVE-2017-7562 does not apply to version 1.9, so you should not need to
address it.

This vulnerability actually never appeared in any released version of
MIT krb5.  It was introduced on the master branch and then fixed before
the release of 1.16.  The CVE was assigned because the Fedora package
contained a backport of the feature before it was fixed.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco)
Hi Greg,

        Thanks for your interest in this issue. But I am still not clear that how this vulnerability is not applicable to kerberos 1.9 .
Because as per the git link https://github.com/krb5/krb5/pull/694 it seems that this functionality is present in kerberos 1.9 also.

Please can you help in elaborate more on how the fix is not applicable for kerberos 1.9

Thanks and Regards!
Shiva

-----Original Message-----
From: Greg Hudson [mailto:[hidden email]]
Sent: 21 September 2018 19:48
To: Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco) <[hidden email]>; [hidden email]
Subject: Re: Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

On 09/21/2018 02:04 AM, Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco) wrote:> We are using Kerberos (version
1.9) in one of our components. We came across the vulnerability
CVE-2017-7562 being reported and fixed in Kerberos 1.16.1.

CVE-2017-7562 does not apply to version 1.9, so you should not need to address it.

This vulnerability actually never appeared in any released version of MIT krb5.  It was introduced on the master branch and then fixed before the release of 1.16.  The CVE was assigned because the Fedora package contained a backport of the feature before it was fixed.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

Greg Hudson
On 09/21/2018 10:37 AM, Shivakumar Nadarajan -X (shinadar - HCL
TECHNOLOGIES LIMITED at Cisco) wrote:
> Thanks for your interest in this issue. But I am still not clear that how this vulnerability is not applicable to kerberos 1.9 .
> Because as per the git link https://github.com/krb5/krb5/pull/694 it seems that this functionality is present in kerberos 1.9 also.

The certauth pluggable interface was introduced in commit
b619ce84470519bea65470be3263cd85fba94f57 (February 2017).  It replaced
some of the existing logic for validating client certificates with two
built-in modules.  The first, "pkinit_san", checks the Subject
Alternative Name values in the client certificate against the requested
principal; the second, "pkinit_eku", checks the Extended Key Usage
values in the client certificate to see if it was issued for use with
PKINIT.

The vulnerability was that these two new modules were not always
returning the correct results to the pluggable interface accumulator.
The hardcoded logic used prior to commit
b619ce84470519bea65470be3263cd85fba94f57 did not have the same problem.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

RE: Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco)
Hi Greg,

        Based on your previous information, I did go through the details of the commit b619ce84470519bea65470be3263cd85fba94f57. After some analysis still I am not able to convince myself that this vulnerability doesn't exist for the versions before this commit. Please find my argument as below

Before commit(b619ce84470519bea65470be3263cd85fba94f57):
        1. It’s a sequential checks that are done against the certificate, meaning that first san check is done using verify_client_san()
        2. Then eku check is done using verify_client_eku()

After commit:
        1. The code has been refactored such that san and eku check are done through function pointers pkinit_san_authorize() and pkinit_eku_authorize()
        2. Both these function pointers still call verify_client_san() and verify_client_eku() and do the same checks as before commit.
        3. Additional check related to db match is been added after the commit
       
Common note: Either before the commit or after the commit, the retrieve san information is done in crypto_retrieve_X509_sans() which hasn't changed before or after the commit.
And the main vulnerability fix is done in crypto_retrieve_X509_sans() and hence its applicable for all the versions which has this code.
Please correct me if I am wrong and also request you to help me further on this.

Also please refer the below link specific to Cisco

https://tools.cisco.com/security/center/viewAlert.x?alertId=58543

It mentions the affected version as  1.9 (Base, .1, .2) | 1.9.1 (Base) | 1.9.2 (Base) | 1.9.3 (Base) | 1.9.4 (Base) | 1.9.5 (Base)

Thanks and Regards!
Shiva

-----Original Message-----
From: Greg Hudson [mailto:[hidden email]]
Sent: 21 September 2018 20:42
To: Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco) <[hidden email]>; [hidden email]
Subject: Re: Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

On 09/21/2018 10:37 AM, Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco) wrote:
> Thanks for your interest in this issue. But I am still not clear that how this vulnerability is not applicable to kerberos 1.9 .
> Because as per the git link https://github.com/krb5/krb5/pull/694 it seems that this functionality is present in kerberos 1.9 also.

The certauth pluggable interface was introduced in commit
b619ce84470519bea65470be3263cd85fba94f57 (February 2017).  It replaced some of the existing logic for validating client certificates with two built-in modules.  The first, "pkinit_san", checks the Subject Alternative Name values in the client certificate against the requested principal; the second, "pkinit_eku", checks the Extended Key Usage values in the client certificate to see if it was issued for use with PKINIT.

The vulnerability was that these two new modules were not always returning the correct results to the pluggable interface accumulator.
The hardcoded logic used prior to commit
b619ce84470519bea65470be3263cd85fba94f57 did not have the same problem.

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Need suggestion/help in back porting the fix for vulnerability CVE-2017-7562 (backporting from Kerberos 1.16.1 to Kerberos 1.9)

Greg Hudson
On 09/23/2018 03:40 AM, Shivakumar Nadarajan -X (shinadar - HCL
TECHNOLOGIES LIMITED at Cisco) wrote:
> Before commit(b619ce84470519bea65470be3263cd85fba94f57):
> 1. It’s a sequential checks that are done against the certificate, meaning that first san check is done using verify_client_san()
> 2. Then eku check is done using verify_client_eku()

The vulnerability was that a client certificate with an Extended Key
Usage attribute indicating that it was issued for PKINIT, but no Subject
Alternative Name attributes at all, would be allowed to authorize any
client principal, even though there is nothing in the certificate naming
the client.

The old code does not contain this vulnerability because
pkinit_server_verify_padata() returns an error if either
verify_client_san() returns with *valid_san == 0 or if
verify_client_eku() returns with *valid_eku == 0.  It does not allow a
valid EKU to override the lack of a valid SAN.

There was a second bug concomittant with the bug creating the
vulnerability: a certificate with SAN attributes that have nothing to do
with PKINIT would be rejected even if another module (like the new
dbmatch module) would have authorized it.  This second bug does not
create a vulnerability; in fact, it created an over-restrictiveness
which reduced the impact of the vulnerability.

> After commit:
> 1. The code has been refactored such that san and eku check are done through function pointers pkinit_san_authorize() and pkinit_eku_authorize()
> 2. Both these function pointers still call verify_client_san() and verify_client_eku() and do the same checks as before commit.
> 3. Additional check related to db match is been added after the commit
>
> Common note: Either before the commit or after the commit, the retrieve san information is done in crypto_retrieve_X509_sans() which hasn't changed before or after the commit.

Actually, crypto_retrieve_X509_sans() did change in this commit, to
return ENOENT if there are no SAN fields.

> And the main vulnerability fix is done in crypto_retrieve_X509_sans() and hence its applicable for all the versions which has this code.

The vulnerability fix is in pkinit_eku_authorize(), where it returns
KRB5_PLUGIN_NO_HANDLE (meaning "I don't see any reason to reject the
cert, nor any reason to accept it") instead of returning 0 (meaning "I
see a reason to accept the cert").  Everything else in the same commit
fixes the second bug.

To fix the second bug, crypto_retrieve_X509_sans() needed to change to
make it easier to determine when a certificate contains no
PKINIT-related SAN attributes (as opposed to no SAN attributes at all).
So the change in commit b619ce84470519bea65470be3263cd85fba94f57 was
reverted (it no longer returns ENOENT if there are no SAN attributes)
and it is instead changed to return null lists instead of empty lists.
verify_client_san() is then changed to look for both lists of
PKINIT-related SAN attributes being null, instead of looking for an
ENOENT result.

For the pre-certauth code, the old behavior of
crypto_retrieve_X509_sans() was sufficient because there was no way to
authorize a client certificate except via a PKINIT-related SAN attribute
matching the client principal.  Therefore there was no need to determine
whether any PKINIT-related SAN attributes were present.

> Please correct me if I am wrong and also request you to help me further on this.
>
> Also please refer the below link specific to Cisco
>
> https://tools.cisco.com/security/center/viewAlert.x?alertId=58543

That page is wrong.  No upstream versions of MIT krb5 are affected by
the vulnerability, and 1.16.1 does not contain a fix for the
vulnerability (because 1.16 already had the fix).
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev