smb_negotiate.c revision a90cf9f29973990687fa61de9f1f6ea22e924e40
/*
* CDDL HEADER START
*
* The contents of this file are subject to the terms of the
* Common Development and Distribution License (the "License").
* You may not use this file except in compliance with the License.
*
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
* See the License for the specific language governing permissions
* and limitations under the License.
*
* When distributing Covered Code, include this CDDL HEADER in each
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
* If applicable, add the following below this CDDL HEADER, with the
* fields enclosed by brackets "[]" replaced with your own identifying
* information: Portions Copyright [yyyy] [name of copyright owner]
*
* CDDL HEADER END
*/
/*
* Copyright 2015 Nexenta Systems, Inc. All rights reserved.
*/
/*
* Notes on the virtual circuit (VC) values in the SMB Negotiate
* response and SessionSetupAndx request.
*
* A virtual circuit (VC) represents a connection between a client and a
* server using a reliable, session oriented transport protocol, such as
* single underlying transport connection, i.e. a single NetBIOS session,
* which limited performance for raw data transfers.
*
* The intention behind multiple VCs was to improve performance by
* allowing parallelism over each NetBIOS session. For example, raw data
* could be transmitted using a different VC from other types of SMB
* requests to remove the interleaving restriction while a raw transfer
* is in progress. So the MaxNumberVcs field was added to the negotiate
* response to make the number of VCs configurable and to allow servers
* to specify how many they were prepared to support per session
* connection. This turned out to be difficult to manage and, with
* technology improvements, it has become obsolete.
*
* Servers should set the MaxNumberVcs value in the Negotiate response
* to 1. Clients should probably ignore it. If a server receives a
* SessionSetupAndx with a VC value of 0, it should close all other
* VCs to that client. If it receives a non-zero VC, it should leave
* other VCs in tact.
*
*/
/*
* SMB: negotiate
*
* Client Request Description
* ============================ =======================================
*
* UCHAR WordCount; Count of parameter words = 0
* USHORT ByteCount; Count of data bytes; min = 2
* struct {
* UCHAR BufferFormat; 0x02 -- Dialect
* UCHAR DialectName[]; ASCII null-terminated string
* } Dialects[];
*
* The Client sends a list of dialects that it can communicate with. The
* response is a selection of one of those dialects (numbered 0 through n)
* or -1 (hex FFFF) indicating that none of the dialects were acceptable.
* The negotiate message is binding on the virtual circuit and must be
* sent. One and only one negotiate message may be sent, subsequent
* negotiate requests will be rejected with an error response and no action
* will be taken.
*
* The protocol does not impose any particular structure to the dialect
* strings. Implementors of particular protocols may choose to include,
* for example, version numbers in the string.
*
* If the server does not understand any of the dialect strings, or if PC
* NETWORK PROGRAM 1.0 is the chosen dialect, the response format is
*
* Server Response Description
* ============================ =======================================
*
* UCHAR WordCount; Count of parameter words = 1
* USHORT DialectIndex; Index of selected dialect
* USHORT ByteCount; Count of data bytes = 0
*
* If the chosen dialect is greater than core up to and including
* LANMAN2.1, the protocol response format is
*
* Server Response Description
* ============================ =======================================
*
* UCHAR WordCount; Count of parameter words = 13
* USHORT DialectIndex; Index of selected dialect
* USHORT SecurityMode; Security mode:
* bit 0: 0 = share, 1 = user
* authentication
* USHORT MaxBufferSize; Max transmit buffer size (>= 1024)
* USHORT MaxMpxCount; Max pending multiplexed requests
* USHORT MaxNumberVcs; Max VCs between client and server
* USHORT RawMode; Raw modes supported:
* bit 0: 1 = Read Raw supported
* bit 1: 1 = Write Raw supported
* ULONG SessionKey; Unique token identifying this session
* SMB_TIME ServerTime; Current time at server
* SMB_DATE ServerDate; Current date at server
* USHORT ServerTimeZone; Current time zone at server
* USHORT EncryptionKeyLength; MBZ if this is not LM2.1
* USHORT Reserved; MBZ
* USHORT ByteCount Count of data bytes
* UCHAR EncryptionKey[]; The challenge encryption key
* STRING PrimaryDomain[]; The server's primary domain
*
* MaxBufferSize is the size of the largest message which the client can
* legitimately send to the server
*
* If bit0 of the Flags field is set in the negotiate response, this
* indicates the server supports the SMB_COM_LOCK_AND_READ and
* SMB_COM_WRITE_AND_UNLOCK client requests.
*
* If the SecurityMode field indicates the server is running in user mode,
* the client must send appropriate SMB_COM_SESSION_SETUP_ANDX requests
* before the server will allow the client to access resources. If the
* authentication, the client should use the authentication mechanism
* specified in section 2.10.
*
* Clients should submit no more than MaxMpxCount distinct unanswered SMBs
* to the server when using multiplexed reads or writes (see sections 5.13
* and 5.25)
*
* Clients using the "MICROSOFT NETWORKS 1.03" dialect use a different
* form of raw reads than documented here, and servers are better off
* setting RawMode in this response to 0 for such sessions.
*
* If the negotiated dialect is "DOS LANMAN2.1" or "LANMAN2.1", then
* PrimaryDomain string should be included in this response.
*
* If the negotiated dialect is NT LM 0.12, the response format is
*
* Server Response Description
* ========================== =========================================
*
* UCHAR WordCount; Count of parameter words = 17
* USHORT DialectIndex; Index of selected dialect
* UCHAR SecurityMode; Security mode:
* bit 0: 0 = share, 1 = user
* bit 1: 1 = encrypt passwords
* USHORT MaxMpxCount; Max pending multiplexed requests
* USHORT MaxNumberVcs; Max VCs between client and server
* ULONG MaxBufferSize; Max transmit buffer size
* ULONG MaxRawSize; Maximum raw buffer size
* ULONG SessionKey; Unique token identifying this session
* ULONG Capabilities; Server capabilities
* ULONG SystemTimeLow; System (UTC) time of the server (low).
* ULONG SystemTimeHigh; System (UTC) time of the server (high).
* USHORT ServerTimeZone; Time zone of server (min from UTC)
* UCHAR EncryptionKeyLength; Length of encryption key.
* USHORT ByteCount; Count of data bytes
* UCHAR EncryptionKey[]; The challenge encryption key
* UCHAR OemDomainName[]; The name of the domain (in OEM chars)
*
* In addition to the definitions above, MaxBufferSize is the size of the
* largest message which the client can legitimately send to the server.
* If the client is using a connectionless protocol, MaxBufferSize must be
* set to the smaller of the server's internal buffer size and the amount
* of data which can be placed in a response packet.
*
* MaxRawSize specifies the maximum message size the server can send or
* receive for SMB_COM_WRITE_RAW or SMB_COM_READ_RAW.
*
* Connectionless clients must set Sid to 0 in the SMB request header.
*
* Capabilities allows the server to tell the client what it supports.
* The bit definitions defined in smb.h. Bit 0x2000 used to be set in
* the negotiate response capabilities but it caused problems with
* Windows 2000. It is probably not valid, it doesn't appear in the
* CIFS spec.
*
* 4.1.1.1 Errors
*
*/
#include <smbsrv/smb_kproto.h>
static const smb_xlate_t smb_dialect[] = {
{ DIALECT_UNKNOWN, "DIALECT_UNKNOWN" },
{ PC_NETWORK_PROGRAM_1_0, "PC NETWORK PROGRAM 1.0" },
{ PCLAN1_0, "PCLAN1.0" },
{ MICROSOFT_NETWORKS_1_03, "MICROSOFT NETWORKS 1.03" },
{ MICROSOFT_NETWORKS_3_0, "MICROSOFT NETWORKS 3.0" },
{ LANMAN1_0, "LANMAN1.0" },
{ LM1_2X002, "LM1.2X002" },
{ DOS_LM1_2X002, "DOS LM1.2X002" },
{ DOS_LANMAN2_1, "DOS LANMAN2.1" },
{ LANMAN2_1, "LANMAN2.1" },
{ Windows_for_Workgroups_3_1a, "Windows for Workgroups 3.1a" },
{ NT_LM_0_12, "NT LM 0.12" },
{ DIALECT_SMB2002, "SMB 2.002" },
{ DIALECT_SMB2XXX, "SMB 2.???" },
};
/*
* Maximum buffer size for DOS: chosen to be the same as NT.
* Do not change this value, DOS is very sensitive to it.
*/
#define SMB_DOS_MAXBUF 0x1104
/*
* The DOS TCP rcvbuf is set to 8700 because DOS 6.1 seems to have problems
* with other values. DOS 6.1 seems to depend on a window value of 8700 to
* send the next set of data. If we return a window value of 40KB, after
* sending 8700 bytes of data, it will start the next set of data from 40KB
* instead of 8.7k. Why 8.7k? We have no idea; it is the value that NT uses.
* September 2000.
*
* IR104720 Increased smb_nt_tcp_rcvbuf from 40KB to just under 1MB to allow
* for a larger TCP window sizei based on observations of Windows 2000 and
* performance testing. March 2003.
*/
/*
* Maximum number of simultaneously pending SMB requests allowed on
* one connection. This is like "credits" in SMB2, but SMB1 uses a
* fixed limit, having no way to request an increase like SMB2 does.
* Note: Some older clients only handle the low byte of this value,
* so this value should be less than 256.
*/
static int smb_xlate_dialect(const char *);
/*
* "Capabilities" offered by SMB1 Negotiate Protocol.
* See smb.h for descriptions.
*
* CAP_RAW_MODE, CAP_MPX_MODE are obsolete.
* UNICODE support is required for long share names,
* long file names and streams.
*
* For testing, one can patch this, i.e. remove the high bit to
* temporarily disable extended security, etc.
*/
CAP_DFS |
/*
* SMB Negotiate gets special handling. This is called directly by
* the reader thread (see smbsr_newrq_initial) with what _should_ be
* an SMB1 Negotiate. Only the "\ffSMB" header has been checked
* when this is called, so this needs to check the SMB command,
* if it's Negotiate execute it, then send the reply, etc.
*
* Since this is called directly from the reader thread, we
* know this is the only thread currently using this session.
* This has to duplicate some of what smb1sr_work does as a
* result of bypassing the normal dispatch mechanism.
*
* The caller always frees this request.
*/
int
{
/*
* Decode the header
*/
&pid_hi,
&pid_lo,
return (-1);
return (-1);
/*
* Reserve space for the reply header.
*/
return (-1);
return (-1);
return (-1);
/* Store pointers for later */
if (sdrc == SDRC_SUCCESS)
if (sdrc != SDRC_NO_REPLY)
if (sdrc == SDRC_DROP_VC)
return (-1);
return (0);
}
{
int dialect;
int pos;
int rc = 0;
rc = -1;
break;
}
continue;
/*
* Conditionally recognize the SMB2 dialects.
*/
if (dialect >= DIALECT_SMB2002 &&
continue;
}
}
}
void
{
}
{
char *nbdomain;
int wclen;
int rc;
/* The protocol has already been negotiated. */
return (SDRC_ERROR);
}
/*
* Special case for negotiating SMB2 from SMB1. The client
* includes the "SMB 2..." dialects in the SMB1 negotiate,
* and if SMB2 is enabled, we choose one of those and then
* send an SMB2 reply to that SMB1 request. Yes, it's very
* strange, but this SMB1 request can have an SMB2 reply!
* To accomplish this, we let the SMB2 code send the reply
* and return the special code SDRC_NO_REPLY to the SMB1
* dispatch logic so it will NOT send an SMB1 reply.
* (Or possibly send an SMB1 error reply.)
*/
return (rc);
}
switch (negprot->ni_dialect) {
case PC_NETWORK_PROGRAM_1_0: /* core */
SO_RCVBUF, (const void *)&smb_dos_tcp_rcvbuf,
sizeof (smb_dos_tcp_rcvbuf), CRED());
break;
case PCLAN1_0:
case MICROSOFT_NETWORKS_1_03:
case MICROSOFT_NETWORKS_3_0:
case LANMAN1_0:
case LM1_2X002:
case DOS_LM1_2X002:
SO_RCVBUF, (const void *)&smb_dos_tcp_rcvbuf,
sizeof (smb_dos_tcp_rcvbuf), CRED());
"bwwwwwwlYww2.w#c",
13, /* wct */
secmode, /* security mode */
SMB_DOS_MAXBUF, /* max buffer size */
1, /* max MPX */
1, /* max VCs */
sesskey, /* session key */
/* reserved field handled 2. */
break;
case DOS_LANMAN2_1:
case LANMAN2_1:
SO_RCVBUF, (const void *)&smb_dos_tcp_rcvbuf,
sizeof (smb_dos_tcp_rcvbuf), CRED());
"bwwwwwwlYww2.w#cs",
13, /* wct */
secmode, /* security mode */
SMB_DOS_MAXBUF, /* max buffer size */
1, /* max MPX */
1, /* max VCs */
sesskey, /* session key */
/* reserved field handled 2. */
nbdomain);
break;
case NT_LM_0_12:
SO_RCVBUF, (const void *)&smb_nt_tcp_rcvbuf,
sizeof (smb_nt_tcp_rcvbuf), CRED());
/*
* Allow SMB signatures if using encrypted passwords
*/
if ((secmode & NEGOTIATE_ENCRYPT_PASSWORDS) &&
secmode |=
}
/*
* Does the client want Extended Security?
* (and if we have it enabled)
* If so, handle as if a different dialect.
*/
goto NT_LM_0_12_ext_sec;
/* Else deny knowledge of extended security. */
/*
* nbdomain is not expected to be aligned.
* Use temporary buffer to avoid alignment padding
*/
return (SDRC_ERROR);
}
"bwbwwllllTwbw#c#c",
17, /* wct */
secmode, /* security mode */
1, /* max VCs */
0xFFFF, /* max raw size */
sesskey, /* session key */
wcbuf); /* nbdomain (unicode) */
break;
/*
* This is the "Extended Security" variant of
* dialect NT_LM_0_12.
*/
"bwbwwllllTwbw#c#c",
17, /* wct */
secmode, /* security mode */
1, /* max VCs */
0xFFFF, /* max raw size */
sesskey, /* session key */
0, /* encryption key length (MBZ) */
break;
default:
break;
}
if (rc != 0)
return (SDRC_ERROR);
/*
* Save the agreed dialect. Note that the state is also
* used to detect and reject attempts to re-negotiate.
*/
/* Allow normal SMB1 requests now. */
return (SDRC_SUCCESS);
}
static int
smb_xlate_dialect(const char *dialect)
{
const smb_xlate_t *dp;
int i;
for (i = 0; i < smb_ndialects; ++i) {
dp = &smb_dialect[i];
}
return (-1);
}