| From: | "Pauly, Eric" <Eric_Pauly@bmc.com> |
| To: | "krb5-bugs@mit.edu" <krb5-bugs@mit.edu> |
| Subject: | Experiencing issues to Kerberize SMB protocol with MIT krb5-1.16.1 |
| Date: | Thu, 13 Sep 2018 09:46:45 +0000 |
Hi MIT Kerberos Team,
First I want to thank you for all the good work you have done to ease Kerberization of service. We were looking for a solution to help us Kerberizing SMB2/3 protocol from/to Linux and Windows OSes and we were able to do it with krb5-1.16.1 source code.
In addition we were challenging FIPS certification so it means we tried to use your libraries to achieve crypto through OpenSSL in FIPS mode and we found some little things that can be enhanced to ease those kind of project.
At this time we need to patch your sources to enforce OpenSSL crypto usage and an unexpected GSSAPI behavior (under Windows) and we want to share.
I have not worked OpenSSL crypto patch (but I can gather them later if you are interested) so I cannot describe it in details first but I can point you to a significant bug in GSSAPI:
- first considering a Windows machine CLIENT trying to reach SERVER over SMB2
- both can be joined to the same REALM.COM to ease the test
- we verify expected network traffic like this:
- checking for SMB2 Negotiate Protocol Request and Response: negTokenInit has expected MechType 1.2.840.48018.1.2.2 (KRB5 - Kerberos 5) OID
- see AS-REQ/AS-REP (UDP then TCP), DNS exchange for KDC, TCP TGS-REQ/TGS-REP soup
- reviewed our SMB2 Session Setup Request (packet we care of ourselves but containing your KRB5_AP_REQ ticket given by your GSS API)
- look at Session Setup Response consistency SERVER send us
- surprisingly see a GSS_S_FAILURE (major) with ENOMEM (minor) behind gss_inquire_sec_context_by_oid() call (which should just gather our SMB2 session key ready for use to end SMB2 Session Setup)
It happens from a Windows machine but not from a Linux OS.
I know you do not have our code in your hands but if you assume we pass well parameters (allocated in right way) the following footsteps resume what we use from KRB5 lib and GSS lib:
gss_import_name(GSS_C_NT_HOSTBASED_SERVICE)
krb5_init_context()
krb5_parse_name(REALM.COM)
krb5_cc_new_unique(MEMORY)
krb5_cc_initialize()
krb5_get_init_creds_password()
krb5_cc_store_cred()
gss_krb5_import_cred()
gss_init_sec_context(GSS_C_NULL_OID, GSS_C_MUTUAL_FLAG)
gss_inquire_sec_context_by_oid(GSS_C_INQ_SSPI_SESSION_KEY)
We were looking for root cause and its lying in the way you allocate gss_buffer_set_t->elements into
generic_gss_add_buffer_set_member(). (src/lib/gssapi/generic/util_buffer_set.c)
gssalloc_realloc() will call MS API HeapReAlloc() on a value pointer that remains NULL after call.
You can easily confirm with an instance of NULL pointer and pass it to
HeapReAlloc() and see pointer still NULL after call.
This is not explicit into MSDN but it is current behavior on most of Windows systems.
Feel free to point us to anyone that can handle such bug at least, and if you are interested to OpenSSL patches (on both Linux/Windows platforms) we can point you to appropriate contact.
Regards,
Eric Pauly