[jcifs] Bug in jCIFS Signing logic

[Dean Povey]

Hi Guys,

I have been looking at using jCIFS to authenticate hashes generated by 
NTLM over HTTP and have noticed what I think is a bug when using this 
with Windows 2003.

The documentation mentions that Win2K3 requires SMB signing and talks 
about some issues with working around this in Win2K3 (by setting the 
username and password properties). However, I am pretty sure that if you 
are only doing authentication signing should not be required. If I use 
an old jCIFS version which doesn't support signing I am able to 
authenticate to a Win2K3 server without signing (I verified this with a 
packet trace).

However, this doesn't work with jCIFS 1.1.0 (and I think the problem 
code hasn't been touched since then) because of a bug in the logic that 
  checks whether signing is required. What happens is by default jCIFS 
attempts to generate signatures as "GUEST" with an empty password. 
Because the GUEST account is disabled by default on Win2K3 this 
generates an error.

The code does something like:

1. Do we need to setup signing for this session?
    - This looks at some preferences and flags it got setting up the
session
2. Do we have exernal hashes (i.e. did we get hashes via HTTP NTLM or 
NTLMSSP over SPNEGO)
3. Is the _default_ password non null

If all these conditions are met, it uses the default username and 
password to preauthenticate the connection.

Unfortunately jCIFS does:

SmbSession:256: if (... NtlmPasswordAuthentication.DEFAULT_PASSWORD != null

to check condition 3, and yet does the following to set this up:

NtlmPasswordAuthentication:54:static final String DEFAULT_PASSWORD =
             Config.getProperty("jcifs.smb.client.password", "");

What this means is: if I haven't set the default password the code above 
suggests the behaviour I will get is to not do signing. However, because 
of the broken logic jCIFS thinks I _have_ set the default password and 
as a result attempts to sign messages using the default username and 
password ("GUEST" and "").

The correct fix (assuming it doesn't break anything) is probably have 
the line in NtlmPasswordAuthentication set DEFAULT_PASSWORD to null 
although I haven't tested this yet.

Thoughts?
Dean.