[jcifs] Unverifiable Signature when usingSmbFileInputStreaminWin2k3

[Michael B Allen]

Michael Kerley said:
>> > Also, did I hear Michael correctly that traffic to the server from a
>> > *different* host can cause signature varification failure? That's a
>> > troubling twist. Did you get a capture on the server for that one? Can
>>
>> Yes, unfortunately you heard right.
>
> I'm looking into the possibility that our router was corrupting the data.
> We were seeing other non-jCIFS-related problems that we were able to fix
> by
> replacing the router.

I looked at your capture. Actually I don't think it really proves anything
one way or the other. It cannot be claimed that client B is causing the
signature state to change for client A on the server. It could just be
that the extra traffic is perturbing the traffic enough to change the
packet sequences from client A which is no different from the behavior I
observed when I first diagnosed this problem which was that if I put a
delay at a strategic point in the signing code the verification would fail
right away. From looking at all failed captures the failure point was
always preceeded by a stand alone ACK. Maybe the whole thing assumes
certain socket options are used like TCP_NODELAY on or off or something.
It could be anything. Heres a (wild) list of possabilities:

Our crypto code is wrong.
The server code peices together the digest and
   NT status codes are assumed or
   NBT header length field isn't the smb header+words+bytes or
   ... countless other things
Some flag like vc_number affects signing behavoir
Some flag in TCP/IP headers are assumed that Java just doesn't use

But we know Windows clients work reliably with Windows servers. The
problem is we cannot compare the differences in packets to emulate that
behavior precisely because the server challenge used to generate the mac
signing digest is different every time we connect.

Can we somehow record a simple sequence of traffic and then play it back
so the challenge doesn't change in which case we might see the difference?

How long would it take to reconnect repeatedly until one of 10 captured
challenges are negotiated? Can we weaken the crypto on the server to
assist with this?

Does smbclient support signing and if so does it have a problem?

Does Samba support signing and if so does jCIFS have a problem with it?
Can we hack samba to use a challenge observed in a successful catpure so
we can reproduce the sequence precisely? Probably not as all packets are
not identical. If so much as one little flag is different the signing
digest will change.

We need a scientific method to apply that will draw something conclusive.

Stumped,
Mike