Is the vulnerability CVE-2017-11462 applicable to older MIT Kerberos 5 releases?

[Sergey Emantayev]

Hi,

We're using a 3rd party software integrated with the MIT Kerberos 5 library version 1.9.1. This is used to communicate to MS Active Directory in Linux. I found a fix is available for the latest versions 1.13, 1.14, 1.15: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8598. However should we apply (back port) the fix to our library 1.9.1? I know that they made few patches in the original MIT Kerberos code, I'm in doubt about an upgrade option.

Thanks,
Sergey Emantayev

_______________________________________________
krbdev mailing list ***@mi

[Greg Hudson]

We're using a 3rd party software integrated with the MIT Kerberos 5 library version 1.9.1. This is used to communicate to MS Active Directory in Linux. I found a fix is available for the latest versions 1.13, 1.14, 1.15: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8598. However should we apply (back port) the fix to our library 1.9.1? I know that they made few patches in the original MIT Kerberos code, I'm in doubt about an upgrade option.

The accept_sec_context part of the change affects 1.9, but the
init_sec_context part does not.

You may also be able to ignore this CVE, if your application correctly
uses the GSS-API. An exploitable vulnerability only arises when an
application incorrectly uses gss_init_sec_context() or
gss_accept_sec_context(). This was a weird case where we assigned a CVE
based on conformant but less-than-ideally-safe API behavior, because we
knew it had contributed to a vulnerability in at least one caller.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Sergey Emantayev]

Hi Greg,
Sorry for the delayed response. How can I identify an incorrect usage of gss_init_sec_context / gss_accept_sec_context?
Thanks,Sergey Emantayev

We're using a 3rd party software integrated with the MIT Kerberos 5 library version 1.9.1. This is used to communicate to MS Active Directory in Linux. I found a fix is available for the latest versions 1.13, 1.14, 1.15: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8598. However should we apply (back port) the fix to our library 1.9.1? I know that they made few patches in the original MIT Kerberos code, I'm in doubt about an upgrade option.

The accept_sec_context part of the change affects 1.9, but the
init_sec_context part does not.

You may also be able to ignore this CVE, if your application correctly
uses the GSS-API.  An exploitable vulnerability only arises when an
application incorrectly uses gss_init_sec_context() or
gss_accept_sec_context().  This was a weird case where we assigned a CVE
based on conformant but less-than-ideally-safe API behavior, because we
knew it had contributed to a vulnerability in at least one caller.

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman

[Greg Hudson]

Post by Sergey Emantayev
Sorry for the delayed response. 
How can I identify an incorrect usage of gss_init_sec_context
/ gss_accept_sec_context?

Both of these calls accept a pointer to a context handle (gss_ctx_id_t).
Both calls are permitted by RFC 2744 to delete an existing context
handle on error, setting the caller's handle to GSS_C_NO_CONTEXT;
alternatively, implementations may leave the context alone on error and
wait for the caller to delete it.

The danger arises if a caller copies the context handle and passes a
pointer to the copy to gss_init_sec_context() or
gss_accept_sec_context(), then passes a pointer to the original context
handle to gss_delete_sec_context(). If the caller uses the same pointer
to the context handle for all calls relating to a context, it should be
safe. (If it does use copies, it can still be safe if it updates all
copies of the context handle after each call to init/accept_sec_context,
on success or failure.)
_______________________________________________
krbdev mailing list ***@m