Shivakumar Nadarajan -X (shinadar - HCL TECHNOLOGIES LIMITED at Cisco)
2018-09-21 06:04:54 UTC
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev