Re: bash sockets: printf \x0a does TCP fragmentation

[Chet Ramey]

On 9/22/18 4:21 AM, dirk+bash@testssl.sh wrote:
> 
> 
> On 9/22/18 1:34 AM, Chet Ramey wrote:
>> On 9/21/18 4:13 PM, dirk+bash@testssl.sh wrote:
>>>
>>> Hello there,
>>>
>>> we discovered a strange phenomenon in the project testssl.sh:
>>>
>>> After opening a TCP socket with a fd (here: 5), when writing to it,
>>> it seems that
>>>
>>> printf -- "$data" >&5 2>/dev/null
>>>
>>> does not do what it is intended. "$data" is  a ClientHello like
>>>
>>> '\x16\x03\x01\x2\x00\x01\x00\x1\xfc\x03\x03\x54\x51\x1e\x7a\xde\xad\xbe\xef\x31\x33\x07\x00\x00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0a\...'
>>>
>>> Each \x0a like the last one causes a new TCP fragment to begin which can be 
>>> easily
>>> spotted when using wireshark while running e.g.
>>
>> Newline? It's probably that stdout is line-buffered and the newline causes
>> a flush, which results in a write(2).
> 
> Anything one can do on the level of bash or non-syscall land? What about
> ulimit -b ?

Bash sets stdout and stderr to be line buffered. It's done this forever,
long before I added /dev/tcp and socket support. I'd expect this to have
shown up long ago.

I doubt stdio attempts to divine the buffer size of the underlying file
descriptor. Changing the socket buffer size would probably not be reflected
into stdio's buffering behavior.

> 
>>> If there's a workaround, please let me know. (tried to add "%b" with no
>>> effect). Otherwise I believe it's a bug.
>>
>> How? Does the emitted output not correspond to what's passed to printf
>> in some way?
> 
> "\x0a" is a legitimate byte which is send from time to time over the
> socket. It happens if the record layer is e.g. 522 bytes (\x02\x0a), if
> a standard cipher is included in the handshake like (\xc0\x0a) or DES-CBC3-SHA
> (\x00\x0a) ECDHE-ECDSA-AES256-SHA or at any other occasion.

That's the thing: 0x0a is a legitimate input byte and is faithfully
reproduced in the output. It's a bug if the output doesn't reflect the
input. We're talking about side effects you don't want, which happen at
a different layer.

> 
> Everything works as expected and like a charm for years now -- the only thing 
> isthe
> underlying TCP fragmentation which is caused as a side effect by sending
> \x0a.

So the newline has been an issue all along?

> As indicated a few servers under certain condition can't cope with it asif 
> the TCP
> first segment is too small they don't treat this as ClientHello
> and just drop the packet, see thread @
> https://github.com/drwetter/testssl.sh/pull/1113, specifically the hint wrt
> https://support.f5.com/csp/article/K53322151 .
> 
> My stance is simply if I use in the internal feature of bash for TCP socket
> programming I didn't expect to have side effects like this.

These side effects are well below bash's layer of abstraction. You can
unbuffer the output by using some kind of unbuffering program (as others
have noted, `dd' is probably the most portable) and avoid them.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/