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

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

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

Serge 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 12/03/2017 05:10 AM, Sergey Emantayev wrote:
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Serge 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
 

    On Sunday, December 3, 2017, 8:22:28 PM GMT+2, Greg Hudson <[hidden email]> wrote:  
 
 On 12/03/2017 05:10 AM, Sergey Emantayev wrote:
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Greg Hudson
On 01/17/2018 06:42 AM, Sergey Emantayev wrote:
> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev