[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 5 on bug 2626 from Guy Harris

MS-RDPBCGR, "Remote Desktop Protocol: Basic Connectivity and Graphics
Remoting", says, in section 2.2.1.1 "Client X.224 Connection Request PDU", that
the lengths of the routingToken, cookie, and rdpNegData fields are "included in
the X.224 Connection Request Length Indicator field".

X.224/ISO 8073, "Information Technology - Open Systems Interconnection -
Protocol for providing the connection mode transport service", says, in section
13.2 "Structure", that the Length Indicator field is the length of the COTP
header, so that indicates that the routingToken, cookie, and rdpNegData fields
are therefore *not* user data in the Connection Request PDU.  However, that
means that, if these were *real* X.225 packets, they would be described by
section 13.2.3 "Variable part" - but that part consists of a bunch of TLVs
(similar to TCP options), and that's *not* what Microsoft are putting there.

I.e., Microsoft's not following the X.224/ISO 8073 COTP spec, and the dissector
will have to try to detect Microsoft's mutant "MS-COTP" and dissect it
differently.  (Sadly, the COTP spec says that "No user data are permitted in
class 0" for the CR PDU, and they're using class 0, given that they're running
COTP atop an already-reliable-and-in-order transport protocol, namely TCP, so
they couldn't use the user data field without, again, not following the spec.)

They also stuff extra weird stuff in the Connection Confirm PDU, as per 2.2.1.2
"Server X.224 Connection Confirm PDU".  (The CC PDU also can't have user data
in class 0.)

For the Connection Request PDU, MS-RDPBCGR seems to be saying (in effect) that
the fixed part of the CR PDU may be followed either by a routingToken field or
a cookie field and that one or the other, but not both, may be present.

Those fields are described as "variable" (length) but not as "optional" in the
packet diagram, but are described as "optional and variable" in the packet
description.  That *might* mean that one of those must be present but the other
of those need not (and, in fact, *must* not) be present.

The routingToken field is claimed to be described by "[MSFT-SDLBTS] "Routing
Token Format""; "MS-SDLBTS" is an old document named "Session Directory and
Load Balancing Using Terminal Server" ("S D (and) L B (Using) T S"), which can
currently be found at

   
http://download.microsoft.com/download/5/B/C/5BC37A4E-6304-45AB-8C2D-AE712526E7F7/TS_Session_Directory.pdf

(thank you, Bing, for giving me a URL unadorned by Google's self-promoting
"here's the Google search from which you got that link" crap).  It indicates
that:

    The routing token format is case sensitive ASCII text, as follows:
Cookie: + SPACE + msts=3640205228.15629.0000 + CR + LF

MS-RDPBCGR says that a cookie field looks like:

    Cookie: mstshash=IDENTIFIER

so *both* of those field types begin with "Cookie:".

*If* there must either be a routingToken or a cookie if there are any
parameters at all, then checking for "Cookie:" would be sufficient to determine
whether the packet is a valid X.224/ISO 8073 CR PDU, as "C", i.e. 0x43, is not
a valid optional parameter type code in a CR PDU.

If, however, neither of them need to be present, then the only other thing that
could be in the variable part would be an RDP Negotiation Request, as described
in section 2.2.1.1.1 of MS-RDPBCGR.  That begins with an 0x01 byte, which
cannot ever be a valid X.224/ISO 8073 parameter type value (to quote section
13.2.3 "Variable part", "No parameter code uses bits 8 and 7 with the value
00.", so all codes have one or both of the 0x80 and 0x40 bits set).

For the Connection Conform PDU, MS-RDPBCGR says (in effect) that the fixed part
of the CR PDU may be followed by an "an optional RDP Negotiation Response
(section 2.2.1.2.1) structure or an optional RDP Negotiation Failure (section
2.2.1.2.2) structure".  An RDP Negotiation Response begins with 0x02, and an
RDP Negotiation Failure begins with 0x03, and neither of those can ever be
valid X.224/ISO 8073 parameter type values (as per the above).

So fairly strong heuristics (which would be fooled only by packets with invalid
variable part parameters that either look like "Cookie" or have codes 0x01,
0x02, and 0x03) exist to detect Microsoft's non-standard COTP, and this reduces
to a Simple Matter of Programming.

---

      You are receiving this mail because:

• You are the assignee for the bug.
• You are watching all bug changes.