[Samba] smbclient error talking to Netapp with SMB 3.11 / Samba 4.7.11

[Philipp Gesang]

Hi Rowland,

-<| Quoting Rowland Penny via samba <rpenny at samba.org>, on Wednesday, 2019-02-13 05:01:19 PM |>-
> On Wed, 13 Feb 2019 17:16:21 +0100
> Philipp Gesang via samba <samba at lists.samba.org> wrote:
> > -<| Quoting L.P.H. van Belle via samba <belle at bazuin.nl>, on
> > Wednesday, 2019-02-13 04:59:55 PM |>-
> > > DOM.AIN\foobar's password:
> > > ^^^^^^^^ 
> > > 
> > > No dot is allowed in the NTDOM 
> > > Fix that first, then try again.

Looking at the packet dumps, that value never even goes over the
wire.

> > Unfortunately we can’t just arbitrarily access the box in
> > question so before I schedule a call with the customer I’d
> > rather gather some more feedback first.
> 
> And before we can start to help you, we need more info. What you are
> connecting from, the smb.conf (if there is one) from the netapp etc

About the other side we only know there is a share reachable
through an IP address that the customer wants to connect to.
What kind of software it runs is completely unknown.

What we do have is the tcpdumps. They look roughly as follows
(N for the netapp box, I for our end):

    [TCP handshake]
    I → N: SMB Negotiate Protocol Request
    N → I: SMB2 Negotiate Protocol Response
    I → N: ACK
    I → N: SMB2 Negotiate Protocol Request
    N → I: SMB2 Negotiate Protocol Response
    [TCP teardown]
 
In the broken 3.11 version, second response message contains an
extra SMB2_PREAUTH_INTEGRITY_CAPABILITIES blob that is not in the
3.10 version. It looks like this (redacted):

    0000   01 00 26 00 00 00 00 00 01 00 20 00 01 00 2a 2a
    0010   2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a
    0020   2a 2a 2a 2a c6 26 94 20 ee 9c ac 68 31 38 00 00
    0030   02 00 0a 00 00 00 00 00 01 00 01 00 2b 06 01 04
    0040   01 82                                          

Note that wireshark stops dissecting after the cipherid of the
first cipher at byte 0x3b (which is byte 0x181 of 0x187 of the
packet), leaving six bytes unanalyzed.

A redacted excerpt of the diff from the (good) SMB 3.10 to the
(bad) 3.11 response:

    @@ -124,8 +124,8 @@
             Security mode: 0x01, Signing enabled
                 .... ...1 = Signing enabled: True
                 .... ..0. = Signing required: False
    -        Dialect: 0x0300
    -        NegotiateContextCount: 0
    +        Dialect: 0x0311
    +        NegotiateContextCount: 2
             Server Guid: 11111111-2222-3333-4444-555555555555
             Capabilities: 0x00000057, DFS, LEASING, LARGE MTU, PERSISTENT HANDLES, ENCRYPTION
                 .... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
    @@ -153,4 +153,18 @@
                                 MechType: 1.3.6.1.4.1.311.2.2.10 (NTLMSSP - Microsoft NTLM Security Support Provider)
                             negHints
                                 hintName: not_defined_in_RFC4178 at please_ignore
    -        NegotiateContextOffset: 0x0000
    +        NegotiateContextOffset: 0x0100
    +        Negotiate Context: SMB2_PREAUTH_INTEGRITY_CAPABILITIES 
    +            Type: SMB2_PREAUTH_INTEGRITY_CAPABILITIES (0x0001)
    +            DataLength: 38
    +            Reserved: 00000000
    +            HashAlgorithmCount: 1
    +            SaltLength: 32
    +            HashAlgorithm: SHA-512 (0x0001)
    +            Salt: ffffffffffffffffffffffffffffffffffffffffffffffff...
    +        Negotiate Context: SMB2_ENCRYPTION_CAPABILITIES 
    +            Type: SMB2_ENCRYPTION_CAPABILITIES (0x0002)
    +            DataLength: 10
    +            Reserved: 00000000
    +            CipherCount: 1
    +            CipherId: AES-128-CCM (0x0001)

Skimming smbXcli_negprot_smb2_done(), there is a check for the
data length:

        if (cipher->data.length != (2 + 2 * cipher_count)) {
                tevent_req_nterror(req,
                                NT_STATUS_INVALID_NETWORK_RESPONSE);
                return;
        }

Looks like Samba expects a value of 4 but the server sends 10 so
the above check fails. The difference appears to be the six
unaacounted for bytes above. Those bytes look unstructured, could
it be that the server pads the message to 8 bytes (the last byte
of the packet is 0x187)? The check is still the same on current
master btw.

I’m not really in a position to decide whether the server or
Samba is at fault here. Would it make sense to relax that check
and try again?

Thanks,
Philipp


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba/attachments/20190214/fbf3a200/signature.sig>