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

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Sep 2010 09:51:06 +0100

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and WG chairs should treat  
these comments just like any other last call comments.

In addition, I have been selected as the Apps Reviewer for this  
document. These comments are similarly written for the benefit of  
apps area directors, and document editors and WG chairs should treat  
these comments just like any other last call comments.

I have not made any distinction between the comments.

Summary:

Whilst I agree with the essential premise - that TCP URG is  
implemented in a different way to that specified, and should be  
homogenized in favour of the deployed implementations - I feel that  
both SeolMa and the proposed solution needs to be expanded upon.

Simply dropping TCP Urgent data facilities removes an aspect of TCP  
which - whilst not commonly used in most modern protocols - is  
nevertheless still used for useful gain in FTP and TELNET.

Specific recommendations are at the bottom.

Background:

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

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)

By instituting a blanket ban, in effect, for TCP Urgent data, this  
effectively deprecates the entire mechanism. This may prove to be the  
only solution, however my general feeling is that this may not be the  
case.

Niggle:

The Cisco-PIX reference does not describe the TCP Urgent behaviour  
except by implication (it mentions adding rules to allow its use for  
TELNET and FTP-PI, but that's it). I have a personal distaste for  
product placement in RFCs, and would prefer that this reference  
pointed at least at a Cisco paper describing default behaviour, etc.

As an aside, the Cisco instructions actually show the user how to  
enable urgent data on FTP-DTP, rather than FTP-PI, which is incorrect.

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.

- A more detailed description of SeolMa, and its implications, would  
be useful, and I think required in the Security Considerations  
section.

- I feel that further consideration of the proposed solution to  
SeolMa is warranted.

Dave.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Sep 2010 04:40:30 -0300

Hi, David,

Thanks so much for your feedback!

Please find my comments inline....

> nevertheless still used for useful gain in FTP and TELNET.

Actually, support for urgent data is not removed. We simply discourage
its use.

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

> 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 ----

?

> only solution, however my general feeling is that this may not be the case.

Not that I like it... but in practice, it probably is. As you correctly
mentioned before, when multiple segments are in flight, it becomes
virtually impossible for a NIDS to be able to do its job.

> product placement in RFCs, and would prefer that this reference pointed
> at least at a Cisco paper describing default behaviour, etc.
> 
> As an aside, the Cisco instructions actually show the user how to enable
> urgent data on FTP-DTP, rather than FTP-PI, which is incorrect.

I leave this one for Andrew to answer ;-)

I'd just note that the reason for which Cisco Pix is referenced is
probably because it's a widely deployed device that scrubs urgent
indications. (i.e., "this thing is widely deployed").

> - 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?

> - 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?

Thanks!

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

---

From: "Polk, William T." <[email-masked]>
Date: Wed, 22 Sep 2010 09:23:03 -0400

Hi Fernando,

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

> or false positives in the NIDS [CPNI-TCP] [phrack].
I think this is a helpful change.

> such as Telner [telnet] and FTP [ftp]
I think this is also a helpful change.
> should get into the specifics of what the urgent mechanism is used for
It might be worth highlight FTP and TELNET in Section 5, since these are
evidently common applications that use the urgent data feature.
> 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.

> Kind regards,

Thanks,

Tim

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 23 Sep 2010 00:28:59 +0200 (CEST)

Hi David,

sorry for the delay with the reply - I was off the grid
for a couple of weeks due to vacation.

On Thu, 16 Sep 2010, Fernando Gont wrote:

[snip]

>> at least at a Cisco paper describing default behaviour, etc.

I comment on this below at [*]

>> urgent data on FTP-DTP, rather than FTP-PI, which is incorrect.

Could you unicast me the URL where you saw it, so I can work to get it fixed ?

The ones in the command reference for the ASA talk about tcp/513, which is 
rlogin, e.g.:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/uz.html#wp1591004

> indications. (i.e., "this thing is widely deployed").

Exactly.

[*] - given the contents of the command reference above - would it correspond to 
what you had in mind if we give e.g. the link above to one of the command 
references ?

> You mean what we propose to fix this NIDS evasion technique?

SeolMa was in fact one of the initial triggers of this work, though we deemed 
the NIDS problem as not something practically solvable in a clean way.

I'll include the logic below:

First the "classic" NIDS:

The setup is as follows:

Alice --+-- Eva
         |
        Nick

Eva is trying to exploit Alice using the SeolMa technique.
Regardless of the setup, Nick can not do a lot anyway to help - maybe send a 
reset based on some heuristic, however the damage is possibly already done, 
might depend on the timing.

So we consider a more interesting case of an "inline" setup:

Alice -- Nick -- Eva

Here, Nick can have the power to reliably do something. But he 
needs to consider the following degrees of freedom that Alice has:

* /proc/sys/net/ipv4/tcp_stdurg setting.

This alters the behaviour box-wide, and Nick would need to know the value of 
this setting (manual configuration), to understand in which of the two ways
to interpret the data.

* The timing also plays a role, so Nick would need to 
somehow normalize the timing of the packets before passing them on to Alice. 
This can either impact the TCP connection itself (if done with bigger safety 
margins), or be again unreliable. Or the packets need to be sanitized.

* Meantime, Alice might have learned about the SO_OOBINLINE and added that to 
the code of the next version of the application - which gives another point of 
manual configuration for Nick.

Based on that, there are some approaches to tackling this:

* Nick manually configures his behavior to match the Alice's and then does the 
analysis based on that, trying to guess what Alice's stack would do - and then 
pass the "sanitized" packets to Alice.

==> while technically this looks sound, I think expecting the end user en masse
to know about the details about SO_OOBINLINE/tcp_stdurg is impractical.
Even if the "security" folks might know it, in a lot of organizations they are 
different from "application" folks - the latter not possessing the 
low-level transports knowledge. Side effect of this is the increase of the 
complexity of the task that Nick would do, therefore increasing the chances of 
it not emulating the Alice's behaviour correctly.

* Nick can evade the evasion by clearing the URG flag - breaking
the assumptions of Eve about the processing of the data by Alice.

==> This requires zero configuration, creates loud noise in the logs of Alice 
due to incorrect input, but breaks the apps that rely on
URG mechanism during the legitimate operation.

* Nick can be aggressive on those streams that he knows would not use urgent 
mechanism (e.g. HTTP), and try to handle the ones that may use it, in a more 
graceful manner.

==> This looks like a possibly ideal scenario, however, from the security point 
of view for the applications that use the urgent mechanism, it would need to be 
treated as the first one - i.e. require explicit manual configuration.

So the approach with simply clearing the URG looks like the simplest of all from 
several viewpoints (reliability, and maintenance overhead).

Hopefully this gives more details, would be very useful to know your 
opinion on the above.

Thank you very much!

kind regards,
andrew