Re: [tcpm] On the implementation of TCP urgent data (IETF Internet Draft)

[James Chacon <[e-mail]>]

On Feb 27, 2009, at 5:13 PM, Bill Squier wrote:

>
> On Feb 27, 2009, at 5:29 PM, Christos Zoulas wrote:
>
>> In article <[e-mail]> you write:
>>> Hello, folks,
>>>
>>> We have published a revision of our IETF Internet-Draft entitled  
>>> "On the
>>> implementation of TCP urgent data". The document is available at:
>>> http://tools.ietf.org/id/draft-gont-tcpm-urgent-data-01.txt (you can
>>> also get the document in other fancy formats, such as PDF, at
>>> http://www.gont.com.ar/drafts).
>>>
>>> This document describes current issues relevant to the  
>>> implementation
>>> and use of TCP urgent data, aims to change the IETF specifications  
>>> so
>>> that they accommodate what virtually all implementations have been  
>>> doing
>>> wrt urgent data.
>>>
>>> The TCPM working group of the IETF is currently deciding whether to
>>> adopt this document as a working group item, so that your input  
>>> will be
>>> very much appreciated.
>>>
>>> To voice your opinion, please send it to [e-mail], and CC me
>>> ([e-mail]), so that I make sure that your post makes  
>>> it to
>>> the mailing-list, even if you are not subscribed to it.  
>>> (Alternatively,
>>> you can send me your input, and I could forward it to the [e-mail]
>>> mailing-list).
>>
>> The behavior on Windows is more complex than this. I think that it  
>> maintains
>> much more data than a single byte and this can lead to resource  
>> exhaustion.
>> This behavior is used and required to be present by SQL Server, so  
>> Microsoft
>> is unwilling to change it. Bill Squier <[e-mail]> discovered  
>> this and
>> can provide you with details.
>
> I haven't had time to read the article completely, but I did skim  
> the Windows section, and Christos is correct.  Windows exhausts a  
> non-paged fixed size pool of kernel memory (leading to a crash)  
> whenever the receiver does not drain OOB data.  Thus, any Windows  
> TCP receiver which does not expect OOB data is an avenue of attack.   
> For example, the NetBIOS listener.  I refer here to Windows versions  
> <= XP.  I have not performed any testing on Vista and later.   
> Microsoft has been aware of this issue for years.  Jerry and James  
> can speak to whether they have ever addressed it.
>
> Further, I noticed that some of your analysis discusses OOB data  
> bleeding in-line.  This is almost certainly caused by an interaction  
> (on the _sender_) of Nagle and the fact that TCP defines only a  
> single OOB pointer.  The receiver is not returning bytes which it  
> knows to be OOB bytes inline, the _sender_ is accidentally placing  
> more than a single byte of OOB in each packet that it sends.
>
> The receiver has no way to know that, as the only means of  
> communication about OOB data between sender and receiver is a single  
> pointer.
>

Actually we have seen leaks in-band when simply sending one byte at a  
time of OOB. It appears if the distance between 2 bytes exceeds the  
available OOB marker (which from memory was 16 bits) and nothing reads  
on the receiving end then on some impls the bytes leak in-band.

We've seen that on linux and on Solaris to my recollection.

James