[jcifs] Bug in jCIFS Signing logic

[Michael B Allen]

Dean Povey said:
> 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).

If the server does not require signing then it will not be used (unless
you set signingPreferred=true) and everything should work fine. However
even if signing is negotiated, the signing state is established when the
first non-null, non-guest, authentication occurs. So the first successful
authenitcation doesn't actually *use* signing and so it will appear to
work. If you want to verify that signing is actually working you would
have to authenticate a *second* user with different credentials over the
same transport to trigger additional traffic [1]. If signing is used
additional session setups will fail with signature errors because a proper
MAC key cannot be established when using external hashes. This is why we
suggest using some default credentials to be used for
"pre-authentication".

[1] actually if you wait soTimeout for the transport to close you can also
see signatures used in the logoff requests.

> 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.

If that is true it is wrong. If credentials are not supplied it should not
try to do preauthentication. But I would check the latest because I'm
pretty sure I've tested the filter without creds.

> Because the GUEST account is disabled by default on Win2K3 this
> generates an error.

Yup.

> 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.

Ok. So it does check for default credentials. How are you getting "GUEST"?

>
> 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 "").

Oh, yeah, this is wrong.

> 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.

Naaahh. I think it would be better to have

static final String BLANK = "";
static final Srting DEFAULT_PASSWORD = Con....client.password", BLANK);

and then do:

if (NtlmP...DEFAULT_PASSWORD != NtlmP...BLANK) {
   /* do preauth */

Can you try it and tell me what happends?

Mike