A possible small bug in SPNEGO handling when dealing with NETAPP servers
Richard Sharpe
realrichardsharpe at gmail.com
Mon Jun 29 18:22:22 EDT 2020
Hi folks,
I have recently had to deal with a problem when calling
gss_init_sec_context after receiving an SPNEGO negTokenTarg from
NetApp C-Mode and 7-Mode servers.
After some investigation, I tracked it down to
src/lib/gssapi/spnego/spnego_mech.c in get_mech_oid when handling the
supportedMech OID.
The code was directly extracting the length from the buffer but (as
you can see from the capture attached in the Session Setup Response)
NetApp encodes the length of the OID in a longer form as 0x82 0x00
0x09 instead of the short-form 0x09.
To fix this I simply changed the code to call gssint_get_der_length to
retrieve the OID length. The following patch shows the change:
------------------------------------------
--- a/src/lib/gssapi/spnego/spnego_mech.c.orig 2017-03-02
22:06:02.000000000 +0000
+++ b/src/lib/gssapi/spnego/spnego_mech.c 2020-06-29
21:07:05.749062072 +0000
@@ -3256,6 +3256,7 @@
gss_OID_desc toid;
gss_OID mech_out = NULL;
unsigned char *start, *end;
+ unsigned int bytes;
if (length < 1 || **buff_in != MECH_OID)
return (NULL);
@@ -3264,9 +3265,11 @@
end = start + length;
(*buff_in)++;
- toid.length = *(*buff_in)++;
- if ((*buff_in + toid.length) > end)
+ /* Get the length in a way that allows more impls to work */
+ toid.length = gssint_get_der_length(buff_in, length - 1, &bytes);
+
+ if (toid.length < 0 || (*buff_in + toid.length) > end)
return (NULL);
toid.elements = *buff_in;
-------------------------------
With this change my test program (based on libsmb2) now works against
both Windows 2012 and NetApp C-Mode servers.
Should I file a bug about this?
--
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者)
More information about the Kerberos
mailing list