Re: A possible small bug in SPNEGO handling when dealing with NETAPP servers
On Mon, Jun 29, 2020 at 4:29 PM Greg Hudson wrote: > > On 6/29/20 6:22 PM, Richard Sharpe wrote: > > 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. > > RFC 4178 section 4 specifies that "the encoding of the SPNEGO protocol > messages shall obey the Distinguished Encoding Rules (DER) of ASN.1, as > described in [X690]." Yes, you are correct, but everywhere else in the code it uses gssint_get_der_length to extract the length, which just happens to work with non-DER BER encoded fields. > X.690 section 10.1 (Distinguished Encoding Rules, length forms) > specifies that "The definite form of length encoding shall be used, > encoded in the minimum number of octets." > > So this is pretty clearly a NetApp bug. Has a report been filed with them? It probably has been just not by me. NetApp likely feels that since it works with Windows, and has been in the field for a long while now it is not a high priority. From a compatibility point of view the change would make developers' lives easier. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A possible small bug in SPNEGO handling when dealing with NETAPP servers
On 6/29/20 6:22 PM, Richard Sharpe wrote: > 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. RFC 4178 section 4 specifies that "the encoding of the SPNEGO protocol messages shall obey the Distinguished Encoding Rules (DER) of ASN.1, as described in [X690]." X.690 section 10.1 (Distinguished Encoding Rules, length forms) specifies that "The definite form of length encoding shall be used, encoded in the minimum number of octets." So this is pretty clearly a NetApp bug. Has a report been filed with them? Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: A possible small bug in SPNEGO handling when dealing with NETAPP servers
On Mon, Jun 29, 2020 at 03:22:22PM -0700, Richard Sharpe wrote: > 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.0 + > +++ b/src/lib/gssapi/spnego/spnego_mech.c 2020-06-29 > 21:07:05.749062072 + > @@ -3256,6 +3256,7 @@ > gss_OID_desctoid; > gss_OID mech_out = NULL; > unsigned char *start, *end; > + unsigned intbytes; > > 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, ); > + > + 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? Probably, for visibility if nothing else. Do you know if the length is getting encoded in non-DER BER (i.e., with a longer encoding) or if the actual length is large enough that it cannot fit in a single byte? Thanks, Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
A possible small bug in SPNEGO handling when dealing with NETAPP servers
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.0 + +++ b/src/lib/gssapi/spnego/spnego_mech.c 2020-06-29 21:07:05.749062072 + @@ -3256,6 +3256,7 @@ gss_OID_desctoid; gss_OID mech_out = NULL; unsigned char *start, *end; + unsigned intbytes; 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, ); + + 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 (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者) Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
