Re: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06

["Polk, William T." <[e-mail]>]

Hi Fernando,

My comments inline, text pruned to those issues I am responding to...


On 9/16/10 3:40 AM, "Fernando Gont" <[e-mail]> wrote:

 
>> The TCP urgent mechanism, as implemented, means that a single octet is
>> lost when the receiver handles the last "Urgent" data section. Thus
>> particularly when multiple urgent data segments are "in flight", it
>> becomes difficult to guess which octets will be lost by the receiver.
>> The SeolMa attack effectively uses these lost octets to pad strings used
>> in TCP based application protocols, thus defeating naïve NIDS pattern
>> matching.
>> 
>> There is no discussion in the draft about SeolMa, indeed there isn't
>> even a mention of it in the Security Considerations.
> 
> The security considerations does mention the problem of NIDS-evasion,
> although it only focuses on the semantics of the UP (but does not
> consider the OOB vs. in-band thing). Would re-writing the SecCons as
> follows address this point?:
> 
> ---- cut here ----
> Multiple factors can affect the data flow that is actually delivered to
> an application when the TCP urgent mechanism is employed; namely, the
> two possible interpretations of the semantics of the Urgent Pointer in
> current implementations (e.g., depending on the value of the tcp_stdurg
> sysctl), the possible implementation of the urgent mechanism as an
> Out-Of-Band (OOB) facility (vs. in-band as intenteded by the IETF
> specifications), and middle-boxes (such as packet scrubbers) or the
> end-systems themselves that could cause the "urgent data" to be
> processed "in band". This might make it difficult for a Network
> Intrusion Detection System (NIDS) to track the application-layer data
> transferred to the destination system, and thus lead to false negatives
> or false positives in the NIDS [CPNI-TCP] [phrack].
> ---- cut here ----
> 
I think this is a helpful change.

> 
>> It's not clear to
>> me if the recommendation to use SO_OOBINLINE would have an effect here -
>> my gut feeling is that it would defeat SeolMa by making these "lost"
>> octets part of the normal data flow again.
> 
> This wouldn't help for the challenge that NIDS face. This just helps in
> terms of interoperability: i.e., applications should still work if those
> "urgent data" are delivered in-band (whether because of setting
> SO_OOBINLINE or because a packet scrubber cleared the URG bit).
> 
> 
> 
>> Cisco's solution relies on simply forcing urgent data to be non-urgent,
>> which will have knock-on effects on TELNET and FTP by default. It's not
>> clear to me from this document (including reading the references)
> 
> How about if I replace this sentence of the SecCons:
> 
> ---- cut here ----
> However, this
>    might cause interoperability problems or undesired behavior in the
>    applications running on top of TCP.
> ---- cut here ----
> 
> with this one:
> 
> ---- cut here ----
> However, this might cause interoperability problems or undesired
> behavior in those applications that rely on the TCP urgent mechanism,
> such as Telner [telnet] and FTP [ftp]
> ---- cut here ----
> 
> ?
I think this is also a helpful change.
> 
> 
>> Specific Recommendations:
>> 
>> - An informative reference to FTP and TELNET, noting how and why the URG
>> pointer is used, would make it more obvious what is lost here.
> 
> Would the re-written text I indicated above do, or do you think we
> should get into the specifics of what the urgent mechanism is used for
> in FTP and telnet?
> 
> 
It might be worth highlight FTP and TELNET in Section 5, since these are
evidently common applications that use the urgent data feature.
> 
>> - A more detailed description of SeolMa, and its implications, would be
>> useful, and I think required in the Security Considerations section.
> 
> Please let me know if the change indicated above would do.
> 
> 
>> - I feel that further consideration of the proposed solution to SeolMa
>> is warranted.
> 
> You mean what we propose to fix this NIDS evasion technique?
> 

At a minimum, I think the implications of this document and any impact on
SeolMa are needed to complete the security considerations section.

> Thanks!
> 
> Kind regards,
> --
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> 

Thanks,

Tim