From: Luke Kenneth Casson Leighton [lkcl@SAMBA.ORG]
Sent: Sunday, June 04, 2000 2:29 PM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: anonymous SMBwriteX DoS

[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.  i do not have one of these hanging around handy in
my twenty-month-old to four-month-old collection of netmon captures, and i
do not feel like making it as blindingly obvious as the previous post as
to how to crash NT.

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

source code not available.  not even on request.

luke

<a href=" mailto:lkcl@samba.org" > Luke Kenneth Casson Leighton    </a>
<a href=" http://cb1.com/~lkcl"  > Samba and Network Development   </a>
<a href=" http://samba.org"      > Samba Web site                  </a>

ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals