Wireshark · Wireshark-dev: Re: [Wireshark-dev] Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit

["Kukosa, Tomas" <tomas.kukosa@xxxxxxxxx>]

Hi Richard,

I do not know how to decide (and where) whether it is request or response as I have never seen SPNEGO.

But the second half of the problem to switch between NegTokenInit and NegTokenInit2 can be solved in following way:

#.FN_BODY NegotiationToken/negTokenInit
  gboolean is_response = FALSE;  /* get this information from somewhere */
  if (is_response) {
    return dissect_spnego_NegTokenInit2(%(IMPLICIT_TAG)s, %(TVB)s, %(OFFSET)s, %(ACTX)s, %(TREE)s, %(HF_INDEX)s);
  } else {
    return dissect_spnego_NegTokenInit(%(IMPLICIT_TAG)s, %(TVB)s, %(OFFSET)s, %(ACTX)s, %(TREE)s, %(HF_INDEX)s);
  }
#.END

Best regards,
  Tomas

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Richard Sharpe
Sent: Wednesday, May 21, 2014 16:04
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Fixing the problem where Wireshark misdissects the SPNEGO negTokenInit

On Fri, May 16, 2014 at 1:12 AM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
> Hi folks,
>
> Simo Sorce informed me that there are some other SPNEGO sequences that 
> Wireshark does not deal with. They turned up in some HTTP traffic.
>
> So, I decided to look at the issue of fixing the problem I am already 
> aware of (it's in bugzilla somewhere.)
>
> This problem is that [MS-SPNG].pdf defines an negTokenInit2:
>
> NegHints ::= SEQUENCE {
>  hintName[0] GeneralString OPTIONAL,
>  hintAddress[1] OCTET STRING OPTIONAL
> }
> NegTokenInit2 ::= SEQUENCE {
>  mechTypes[0] MechTypeList OPTIONAL,
>  reqFlags [1] ContextFlags OPTIONAL,
>  mechToken [2] OCTET STRING OPTIONAL,
>  negHints [3] NegHints OPTIONAL,
>  mechListMIC [4] OCTET STRING OPTIONAL,  ...
> }
>
> and they coyly say:
>
> "Note In the ASN.1 description in the preceding, the NegTokenInit2 
> message occupies the same context-specific ([X690] section 8.1.2.2) 
> message ID (0) as does NegTokenInit in SPNEGO. "
>
> They also pointed out that hintAddress is never actually used.
>
> Now, these are only emitted by the server in a NegotiateResponse.
>
> I notice that the spnego.cnf file says this:
>
> #.FN_BODY NegTokenInit/mechListMIC
>
>   gint8 ber_class;
>   gboolean pc;
>   gint32 tag;
>   tvbuff_t *mechListMIC_tvb;
>
>   /*
>    * There seems to be two different forms this can take,
>    * one as an octet string, and one as a general string in a
>    * sequence.
>    *
>    * Peek at the header, and then decide which it is we're seeing.
>    */
>   get_ber_identifier(tvb, offset, &ber_class, &pc, &tag);
>   if (ber_class == BER_CLASS_UNI && pc && tag == BER_UNI_TAG_SEQUENCE) {
>     /*
>      * It's a sequence.
>      */
>     return dissect_spnego_PrincipalSeq(FALSE, tvb, offset, actx, tree,
>                                        hf_spnego_mechListMIC);
>   } else {
>
>   ...
>   }
>
> So, the problem is that we have to dissect as if it is a netTokenInit2 
> if we are in the appropriate context, otherwise as a negTokenInit, and 
> the above stuff is one giant hack.
>
> Does anyone have any suggestions on how we can massage the .cnf file 
> to determine this?
>
> I also have to get some captures showing these new SPNEGO things 
> before making any changes.

The problems with SPNEGO dissection in HTTP requests and responses seems to be related to mishandling the mechListMIC.

Here are the changes I think are needed for the ASN1 defn:

diff --git a/asn1/spnego/spnego.asn b/asn1/spnego/spnego.asn index 190b3f1..1f1dcf7 100644
--- a/asn1/spnego/spnego.asn
+++ b/asn1/spnego/spnego.asn
@@ -24,10 +24,6 @@ MechTypeList ::= SEQUENCE OF MechType
 -- to some flavor of "embrace, extend, expectorate" sequence from
 -- Microsoft.
 --
-PrincipalSeq ::= SEQUENCE {
-       principal [0] GeneralString
-}
-
 NegTokenInit ::= SEQUENCE {
                             mechTypes       [0] MechTypeList  OPTIONAL,
                             reqFlags        [1] ContextFlags  OPTIONAL,
@@ -35,6 +31,19 @@ NegTokenInit ::= SEQUENCE {
                             mechListMIC     [3] OCTET STRING  OPTIONAL
                          }

+NegHints ::= SEQUENCE {
+        hintName        [0] GeneralString OPTIONAL,
+        hintAddress     [1] OCTET STRING OPTIONAL
+}
+
+NegTokenInit2 ::= SEQUENCE {
+        mechTypes       [0] MechTypeList OPTIONAL,
+        reqFlags        [1] ContextFlags OPTIONAL,
+        mechToken       [2] OCTET STRING OPTIONAL,
+        negHints        [3] NegHints OPTIONAL,
+        mechListMIC     [4] OCTET STRING OPTIONAL
+}
+
 ContextFlags ::= BIT STRING {
         delegFlag       (0),
         mutualFlag      (1),
----------------------------------------------------

Then, I think what I have to do is to replace the current #.FN_XXXX
NegTokenInit* entries with one simply for NegTokenInit that looks at whether we are dealing with a request or a response, and if a request, uses negTokenInit else uses negTokenInit2.

Not sure how to do this at the moment, though.

Can anyone provide a hint?

--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe