[jcifs] SmbComNTCreateAndX bug?

Mon Mar 10 21:24:23 GMT 2008

Hi Michael,

I've attached an Ethereal trace. In the NT Create AndX Response,
Ethereal reports the byte count as 0x0000 starting at offset 0x9F.

But jcifs reports it as 0x3800 (14336) starting at offset 0xBF:

  SmbComNTCreateAndXResponse[...byteCount=14336...]

This causes jcifs to update the digest with more data than was
actually received on the wire. This can be seen in the debug output
below, in the 3rd update.

Thanks for your help,

Josh

New data read: Transport38[JCXP<00>/192.168.194.131:445]
00000: FF 53 4D 42 A2 00 00 00 00 98 07 C0 00 00 B0 2C  | SMBó......└..░,|
00010: 41 66 51 5A 3E 84 00 00 00 08 20 07 00 08 03 00  |AfQZ>..... .....|

update: 0 0:40
00000: 6B EC 28 9B 9B 36 4D 62 03 18 1D A2 35 B6 B8 EC  |k∞(..6Mb...ó5╢╕∞|
00010: 90 C7 D2 B2 0B 8E B6 34 E6 32 BC 70 E4 13 52 14  |.╟╥▓..╢4µ2╝pΣ.R.|
00020: 15 D7 73 0C 98 A5 FC D8                          |.╫s..Ñⁿ╪        |

update: 1 4:14
00000: FF 53 4D 42 A2 00 00 00 00 98 07 C0 00 00        | SMBó......└..  |

update: 2 0:8
00000: 03 00 00 00 00 00 00 00                          |........        |

update: 3 26:14449
00000: 00 00 00 08 20 07 00 08 03 00 2A FF 00 87 00 00  |.... .....* ....|
00010: 00 40 01 00 00 00 00 00 00 00 00 00 00 00 00 00  |. at ..............|
00020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  |................|
00030: 00 00 00 00 00 00 80 00 00 00 00 10 00 00 00 00  |................|
00040: 00 00 00 00 00 00 00 00 00 00 02 00 FF 05 00 00  |............ ...|
00050: 00 00 01 00 4A 9D DC 00 10 00 00 00 00 00 00 00  |....J.▄.........|
00060: 10 00 00 00 31 00 39 FF 01 1F 00 9B 01 12 00 00  |....1.9 ........|
00070: 38 50 43 00 00 00 6E 00 64 00 6F 00 77 00 73 00  |8PC...n.d.o.w.s.|
00080: 20 00 58 00 50 00 00 00 6A 00 43 00 49 00 46 00  | .X.P...j.C.I.F.|
00090: 53 00 00 00 04 FF 00 DE DE 00 00 01 00 1F 00 00  |S.... .▐▐.......|
000A0: 5C 00 5C 00 4A 00 43 00 58 00 50 00 5C 00 49 00  |\.\.J.C.X.P.\.I.|
000B0: 50 00 43 00 24 00 00 00 3F 3F 3F 3F 3F 00 69 00  |P.C.$...?????.i.|
000C0: 67 00 6E 00 61 00 63 00 6C 00 69 00 65 00 6E 00  |g.n.a.c.l.i.e.n.|
000D0: 74 00 5C 00 72 00 65 00 6D 00 6F 00 74 00 65 00  |t.\.r.e.m.o.t.e.|
000E0: 5C 00 77 00 69 00 6E 00 6C 00 61 00 75 00 6E 00  |\.w.i.n.l.a.u.n.|
000F0: 63 00 68 00 65 00 72 00 2E 00 65 00 78 00 65 00  |c.h.e.r...e.x.e.|

digest:
00000: D4 E2 CD 5D 03 44 BC 1C A3 55 55 38 8A F0 5D A4  |╘Γ═].D╝.úUU8.≡]ñ|

signature verification failure
00000: D4 E2 CD 5D 03 44 BC 1C                          |╘Γ═].D╝.        |

00000: B0 2C 41 66 51 5A 3E 84                          |░,AfQZ>.        |

On Fri, Feb 22, 2008 at 6:27 PM, Michael B Allen <miallen at ioplex.com> wrote:
>
> On Fri, 22 Feb 2008 23:22:41 +0000 (UTC)
>  Josh Cooper <josh.nw at gmail.com> wrote:
>
>  > Hi Michael,
>  >
>  > I'm connecting to the srvsvc via DCE/RPC pipe. I'm frequently, but not always
>  > get an error that the response has an invalid signature, even though the
>  > signature is actually correct.
>  >
>  > I'm using jcifs-1.2.18e, and connecting to an XP machine. The ACME domain in
>  > which the target machine lives requires NTLM clients to sign messages (as set
>  > through group policy), and I've set the corresponding
>  > jcifs.smb.client.signingPreferred property.
>  >
>  > In SmbFile, if CAP_NT_SMBS is true, and this is an instance of SmbNamedPipe,
>  > then we set response.isExtended = true. Then later in AndXServerMessageBlock,
>  > while reading the response, we advance the bufferIndex by 32 if isExtended is
>  > true:
>  >
>  >  if( wordCount > 2 ) {
>  >    bufferIndex += readParameterWordsWireFormat( buffer, bufferIndex );
>  >    /* required for signing verification
>  >     */
>  >    if (command == SMB_COM_NT_CREATE_ANDX) {
>  >      if (((SmbComNTCreateAndXResponse)this).isExtended)
>  >        bufferIndex += 32;
>  >    }
>  >  ...
>  >
>  >  byteCount = readInt2( buffer, bufferIndex ); bufferIndex += 2;
>  >
>  > In my case, it's advancing the bufferIndex to the end of the real SMB data, and
>  > reading 0x3800 as the byteCount. For comparison, Ethereal reports the byteCount
>  > as 0, which jcifs would have done if it hadn't incremented the bufferIndex.
>  >
>  > The bufferIndex is then incremented by the byteCount, and the response.length
>  > gets set incorrectly, which throws off signature verification.
>
>  If the client asks for an "extended" SMB_COM_NT_CREATE_ANDX response
>  (and from your debug output it did) the server should send one in which
>  case we have to consider the 32 bytes.
>
>  I would need to see a capture of the errant response to figure out what
>  is in fact going on.
>
>  Incedentally, the isExtended thing was added to make packets
>  identical to what was observed in captures with NetApp. But I don't
>  recall that it was something that NetApp actually required. It could
>  be that we could just but out the whole isExtended business in
>  SmbFile.open0(). Unfortunately I do not have access to a NetApp machine
>  so now we have to assume it's necessary :-(
>
>  Mike
>
>  PS: If any NetApp customers out there know how to download the NetApp
>  simulator for Linux or VMWare I would be delighted to know about that.
>
>  --
>  Michael B Allen
>  PHP Active Directory SPNEGO SSO
>  http://www.ioplex.com/
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baddigest-srvsvc2.pcap
Type: application/octet-stream
Size: 1495 bytes
Desc: not available
Url : http://lists.samba.org/archive/jcifs/attachments/20080310/a1bdf226/baddigest-srvsvc2.obj