Illegal Transact2 response with bcc and wct zero, but extra 33 bytes of junk in data area

[Steven French]

I found a report of one other example in which Windows can send an illegal
length frame (with 33 bytes of junk at the end which presumably would have
been the t2 response data) and was able to reproduce Windows XP sending
such an illegal SMB response.    I will be relaxing the smb validation and
length check in the cifs vfs slightly to handle this case as well (a report
of a server sending an illegal smb length in a UlogoffX SMB response was
also made earlier).   I am not happy at the idea of having to relax the smb
buffer length validation but this seems low risk and not likely to open up
security exposures (certainly leads me to think that Windows should
validate more strictly).

It is a little harder than it sounds due to the optional packet signing (I
will have to verify whether the extra junk at the end of the frame is
included in what is used to calculate the digital signature).

Any idea what to do to verify the signature when an MS server sends a frame
of 68 bytes but with bcc=0 and wct=0 (instead of the proper length of 35
bytes)?


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com