14.2 SESSION SETUP ANDX REQUEST Data

14.2 SESSION SETUP ANDX REQUEST Data

The dissection of the SMB_PARAMETERS portion of the SESSION SETUP ANDX REQUEST cleared up a few issues and exposed a few others. Now we get to look at the SMB_DATA block and see what further mysteries may lie uncovered.

Fortunately, the Data block is much less daunting. It contains a few fields used for authentication and the rest is just useful bits of information about the client's operating environment. The structure looks like this:

 typedef struct   {   ushort ByteCount;   struct     {     union       {       uchar SecurityBlob[];       struct         {         uchar CaseInsensitivePassword[];         uchar CaseSensitivePassword[];         uchar Pad[];         uchar AccountName[];         uchar PrimaryDomain[];         } non_ext_sec;       } auth_stuff;     uchar NativeOS[];     uchar NativeLanMan[];     uchar Pad2[];     } Bytes;   } smb_SessSetupAndx_Req_Data; 

auth_stuff

As you may by now have come to expect, the structure of the auth_stuff field depends upon whether or not Extended Security has been negotiated. We have shown it as a union type just to emphasize the point. Under Extended Security, the blob will contain a structure specific to the type of Extended Security being used. The SecurityBlobLength value in the Parameter block indicates the size (in bytes) of the SecurityBlob .

If Extended Security has not been negotiated, the structure will contain the following fields:

CaseInsensitivePassword and CaseSensitivePassword

If these names seem familiar it's because the associated length fields were in the Parameter block, described above. These fields are, of course, used in authentication. Chapter 15 on page 257 covers authentication in detail.

Pad

If Unicode is in use, then the Pad field will contain a single nul byte ( 0x00 ) to force two-byte alignment of the following fields (which are Unicode strings).

As you know, the Parameter block is made up of a single byte followed by an array of zero or more words. It starts on a word boundary, but the WordCount byte knocks it off balance, so it never ends on a word boundary. That means that the Data block always starts misaligned . [8] Typically, that's not considered a problem for data in SMB messages. It is not clear why, but it seems that when Unicode support was added to SMB it was decided that Unicode strings should be word-aligned within the SMB message (even though they are likely to be copied out of the message before they're fiddled). That's why the Pad byte is there.

[8] I vaguely remember a conversation with Tridge in which he indicated that there was an obscure exception to the misalignment of the Data block. I'm not sure which SMB, or which dialect , but if I recall correctly there's one SMB that has an extra byte just before the ByteCount field. Keep your eyes open .

Note that if Unicode support is enabled the password fields will always contain an even number of bytes. Strange but true. Here's why:

  • On Windows server systems, plaintext passwords and Unicode are mutually exclusive. The password hashes used for authentication are always an even number of bytes.

  • Unlike Windows, Samba can be configured to use plaintext passwords and Unicode. In that configuration, the CaseInsensitivePassword field will be empty and the CaseSensitivePassword field will contain the password in Unicode format two bytes per character.

Note the subtle glitch here. If Samba is configured to send Unicode plaintext passwords, the CaseSensitivePassword field will not be word-aligned because the Pad byte comes afterward. It seems that the designers of the NT LM 0.12 dialect did not consider the possibility of plaintext Unicode passwords.

AccountName

This is the username field. If Unicode has been negotiated, then the username is presented in Unicode. Otherwise, the string is converted to uppercase and sent using the 8-bit OEM character set.

PrimaryDomain

As with the AccountName , this value is converted to uppercase unless it is being sent in Unicode format.

Whenever possible, this field should contain the NetBIOS name of the NT Domain to which the user belongs. Basically, it allows the client to specify the NT Domain in which the username and password are valid the Authentication Domain. A correct value is not always needed, however. If the server is not a member of an NT Domain, then it will have its own authentication database, and no Domain Controller need be consulted.

Some testing was done with Windows NT 4.0 and Windows 2000 systems that were not members of an NT Domain. As clients , these systems sent their own NetBIOS machine names in the PrimaryDomain field. The smbclient utility sent the workgroup name, as specified in the smb.conf file. jCIFS just sent a question mark. All of these variations seem to work, as long as the server maintains its own authentication database. The PrimaryDomain field is really only useful when authenticating against a Domain Controller.

...and that's the end of the auth_stuff block. On to the rest of it.

NativeOS

This string identifies the host operating system. Windows systems, of course, will fill this field with their OS name and some revision information. This field will be expressed in Unicode if that format has been negotiated.

NativeLanMan

Similar to the NativeOS field, this one contains a short description of the client SMB software. Smbclient fills this field with the name "Samba." jCIFS used to just say "foo" here, but starting with release 0.7.0beta10 it says "jCIFS." The successful use of "foo" demonstrates , however, that the field is not used for anything critical on the server side. Just error reporting, most likely.

Email

graphics/email.gif

 From: Gerald (Jerry) Carter      To: Chris Hertel Subject: NativeLanMan Note that NT4 misaligns the NativeLanMan string by one byte (see Ethereal for details). Also note that Samba uses this string to distinguish between W2K/XP/2K3 for the %a smb.conf variable. So it is used by the server in some cases. 

Pad2

Some systems add one or two extra nul bytes at the end of the SESSION SETUP . Not all clients do this; it appears to be more common if Unicode has been negotiated. The extra bytes pad the end of the SESSION SETUP to the next word boundary. If these bytes are present, they are generally included in the total count given in the ByteCount field.

We have done a lot of work ripping apart packet structures and studying the internal organs. Don't worry, that's the last of it. You should be familiar enough with this stuff by now, so from here on out we will rely on the SNIA doc and packet traces to provide the gory details.

Don't Know When to Quit Alert

graphics/alert.gif

Some of the Windows systems that were tested did not place the correct number of nul bytes at the ends of some Unicode strings. Consider, for example, this snippet from an Ethereal capture:

 0000029F                         57 00 69 00 6e 00 64 00          W.i.n.d. 000002AF 6f 00 77 00 73 00 20 00 4e 00 54 00 20 00 31 00 o.w.s. . N.T. .1. 000002BF 33 00 38 00 31 00  00 00 00 00  57 00 69 00 6e 00 3.8.1... ..W.i.n. 000002CF 64 00 6f 00 77 00 73 00 20 00 4e 00 54 00 20 00 d.o.w.s.  .N.T. . 000002DF 34 00 2e 00 30 00  00 00 00 00  4...0... .. 

Look closely, and you will see that there are two extra nul bytes following each of the two Unicode strings in the hex dump. Under UCS-2LE encoding, the nul string terminator would be encoded as two nul bytes ( 00 00 ). In the sample above, however, there are four null bytes ( 00 00 00 00 ) following the last Unicode character of each string .

In this next excerpt, taken from a SESSION SETUP ANDX RESPONSE SMB, it appears as though one of the terminating nul bytes at the end of the PrimaryDomain field has been lost:

 0000008F                                           57 00                W. 0000009F 69 00 6e 00 64 00 6f 00 77 00 73 00 20 00 35 00 i.n.d.o. w.s. .5. 000000AF 2e 00 30 00 00 00 57 00 69 00 6e 00 64 00 6f 00 ..0...W. i.n.d.o. 000000BF 77 00 73 00 20 00 32 00 30 00 30 00 30 00 20 00 w.s. .2. 0.0.0. . 000000CF 4c 00 41 00 4e 00 20 00 4d 00 61 00 6e 00 61 00 L.A.N. . M.a.n.a. 000000DF 67 00 65 00 72 00 00 00 55 00 42 00 49 00 51 00 g.e.r... U.B.I.Q. 000000EF 58 00  00  X.. 

The first two bytes of the last line ( 58 00 ) are the letter 'X' in UCS-2LE encoding. They should be followed by two nul bytes... but there's only one .




Implementing CIFS. The Common Internet File System
Implementing CIFS: The Common Internet File System
ISBN: 013047116X
EAN: 2147483647
Year: 2002
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net