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

[Andrew Yourtchenko <[e-mail]>]

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]

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

I comment on this below at [*]

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

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


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

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 ?

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

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

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