COMMAND
SMBwriteX
SYSTEMS AFFECTED
WinNT
PROBLEM
Luke Kenneth Casson Leighton found following (a new concept had
to be invented for this one: "the BSOD" - a problem that causes
an NT5 server's screen to go black).
Here is a harmless SMB request, prepared earlier from a netmon
capture:
SMB C write & X, FID = 0x1801, Write 0x73 at 0x00000000
SMB: C write & X, FID = 0x1801, Write 0x73 at 0x00000000
SMB: SMB Status = Error Success
SMB: Error class = No Error
SMB: Error code = No Error
SMB: Header: PID = 0xCAFE TID = 0x2801 MID = 0x0B00 UID = 0x4801
SMB: Command = C write & X
SMB: Word count = 12
SMB: Word parameters
SMB: Next offset = 0x0000
SMB: File ID (FID) = 6145 (0x1801)
SMB: File name = \samr
SMB: File offset = 0 (0x0)
SMB: Open timeout = -1
SMB: Write mode = 8 (0x8)
SMB: ...............0 = Allow write caching
SMB: ..............0. = Do not return bytes remaining
SMB: .............0.. = Do not use raw named pipe protocol
SMB: ............1... = Start of message mode named pipe message
SMB: Bytes left = 115
SMB: Data length = 115 (0x73)
SMB: Data offset = 59 (0x3B)
SMB: Byte count = 115
SMB: Byte parameters
SMB: Data: Number of data bytes remaining = 115 (0x0073)
00000: 00 10 4B 97 32 2E 00 A0 24 78 7B 3A 08 00 45 86 ..K.2...$x{:..E.
00010: 00 DA 69 00 40 00 80 06 79 99 0A 01 01 7F 0A 01 ..i.@...y.... ..
00020: 01 7E 04 02 00 8B 00 00 DF 21 24 7A E0 AD 50 18 .~.......!$z..P.
00030: 1F 26 E3 BB 00 00 00 00 00 AE FF 53 4D 42 2F 00 .&.........SMB/.
00040: 00 00 00 18 03 80 00 00 00 00 00 00 00 00 00 00 ................
00050: 00 00 01 28 FE CA 01 48 00 0B 0C FF 00 00 00 01 ...(...H........
00060: 18 00 00 00 00 FF FF FF FF 08 00 73 00 00 00 73 ...........s...s
00070: 00 3B 00 73 00 05 00 10 00 10 00 00 00 73 00 57 .;.s.........s.W
00080: 00 01 00 00 00 30 16 30 16 0A 06 00 00 18 54 15 .....0.0......T.
00090: 00 4E 54 4C 4D 53 53 50 00 03 00 00 00 01 00 01 .NTLMSSP........
000A0: 00 56 00 00 00 00 00 00 00 57 00 00 00 00 00 00 .V.......W......
000B0: 00 40 00 00 00 00 00 00 00 40 00 00 00 16 00 16 .@.......@......
000C0: 00 40 00 00 00 00 00 00 00 57 00 00 00 B5 82 01 .@.......W......
000D0: 00 42 00 52 00 4F 00 4F 00 4B 00 46 00 49 00 45 .B.R.O.O.K.F.I.E
000E0: 00 4C 00 44 00 53 00 00 .L.D.S..
Note the harmless Write Mode, which is 0x8 - start of named pipe
- at offset 0x69. Note also that the SMB data length of 0x73, at
offset 0x6b and 0x6f, match the byte count at 0x73.
This is a Normal DCE/RPC request (offset 0x75 to end) encapsulated
inside an SMB request. as an aside for those of you who care
about these things, it is an anonymous, encrypted DCE/RPC request
(a pointless but entertaining exercise in spinning CPU cycles).
There is also a harmless Write Mode, which is 0xC - start of named
pipe and raw message pipe.
OK. The 0xC mode reserves the first two bytes of the DCE/RPC data
stream to indicate the length of the DCE/RPC packet. Note, in
passing, the usefulness of telling a server five times how long a
piece of data is.
Note also, that there is no documentation absolutely anywhere in
the known world, including in my book, on the existence of this
length, which was why, when Luke was forced, after two years of
getting away with not implementing DCE/RPC requests (responses
have been known about for 18 months) that span multiple SMB
packets, he found this DoS.
In order so as not to have to bother coding up some stupid length
field that may, or may not, be related to some other stupid length
field in a different protocol layer, Luke allocated an SMB write
buffer of 2048 bytes, and then passed that down to the DCE/RPC
layer for it to play with and stuff its data into.
The result over-the-wire? In the SMB header, the data was
indicated as being 2048 bytes, and as a 0xC write mode. The
first two bytes in the SMB data section were 0x48 - the length of
the DCE/RPC PDU, followed immediately by the DCE/RPC PDU.
The consequences? A Black Screen Of Death. NT4 is, at least, a
little friendlier (for once). It brings up the familiar,
comforting blue screen that can be found on screen-saver programs
and NT boxes located in your office.
SOLUTION
Nothing yet.