Re: bash sockets: printf \x0a does TCP fragmentation

[Dirk Wetter]

On 23.09.18 20:29, Bob Proulx wrote:
> Robert Elz wrote:
>   $ { command printf "one\n"; sleep 1; command printf "two\n" ;} | strace -v 
> -o /tmp/dd.strace.out -e write,read dd status=none ibs=1M obs=1M ; head 
> /tmp/*.strace.out
>   one
>   two
>   ...
>   read(0, "one\n", 1048576)               = 4
>   read(0, "two\n", 1048576)               = 4
>   read(0, "", 1048576)                    = 0
>   write(1, "one\ntwo\n", 8)               = 8
>   +++ exited with 0 +++
> 
> And just for completeness I will show the above with both a large
> input buffer and a large output buffer of the same size and show that
> result too.  The required dd option, as you correctly insisted, really
> is obs= in order to set the output block size.  I stand corrected. :-)
> 
> I had missed the documented dd behavior:
> 
>   ‘bs=BYTES’
>      Set both input and output block sizes to BYTES.  This makes ‘dd’
>      read and write BYTES per block, overriding any ‘ibs’ and ‘obs’
>      settings.  In addition, if no data-transforming ‘conv’ option is
>      specified, input is copied to the output as soon as it’s read, even
>      if it is smaller than the block size.
> 
> It is always good to learn something new about fundamental behavior in
> a command one has been using for some decades! :-)

Thanks for the long mails!

This all -- including cat -- sounded reasonable. But it seems using sockets the 
internal printf
as opposed to the one from coreutils is still causing fragmentation other than 
expected with
strace  PoC:

bash 0$ exec 5<>/dev/tcp/81.169.199.25/443
bash 0$ printf
'\x16\x03\x01\x02\x00\x01\x00\x01\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\x0b\x85\x03\x90\x9f\x77\x04\x33\xd4\xde\x20\x44\xb8\x92\x56\xaf\x74\x52\x9e\xd8\xcf\x52\x14\xc8\xaf\xd8\x34\x0b\xe7\x7f\xeb\x86\x01\x84\x50\x5d\xe4\xa1\x6a\x09\x3b\xbf\x6e\x00\x0e\x13\x01\x13\x02\x13\x03\x13\x04\x13\x05\xc0\x30\x00\xff\x01\x00\x01\xa5\x00\x00\x00\x0b\x00\x09\x00\x00\x06\x66\x66\x66\x66\x66\x66\x00\x2b\x00\x17\x16\x03\x04\x7f\x1c\x7f\x1b\x7f\x1a\x7f\x19\x7f\x18\x7f\x17\x03\x03\x03\x02\x03\x01\x03\x00\x00\x23\x00\x00\x33\x74\x00\x00\x00\x0d\x00\x22\x00\x20\x04\x03\x05\x03\x06\x03\x08\x04\x08\x05\x08\x06\x04\x01\x05\x01\x06\x01\x08\x09\x08\x0a\x08\x0b\x08\x07\x08\x08\x02\x01\x02\x03\x00\x0a\x00\x10\x00\x0e\x00\x1d\x00\x17\x00\x1e\x00\x18\x00\x19\x01\x00\x01\x01\x00\x33\x00\x6b\x00\x69\x00\x1d\x00\x20\x4d\xfa\x57\x44\xb7\xf7\x48\xb8\x95\x77\x5a\xc1\xff\x86\xbf\xae\xf7\x3a\x33\x69\x54\xde\x6a\xf5\x2e\x89\x84\x6c\xf2\xd8\xb2\x43\x00\x17\x00\x41\x04\xb4\x24\xef\x11\x99\x9c\xa4\xe8\xce\x88\x25\xc3\x8e\x7c\x0c\x6a\x94\xde\x33\x6d\xff\xcd\x17\xb7\x5c\x65\xdb\xd1\x58\x46\x95\x69\x80\xc8\xbc\xfc\xe6\xd9\x22\x39\xbb\x3f\x63\xab\x3d\x5c\xba\xcc\xeb\x1a\x90\x1b\xd4\x75\xff\x58\xc4\x00\x58\x50\x21\xd0\xaa\xe4\x00\x0b\x00\x02\x01\x00\x00\x0f\x00\x01\x01\x00\x15\x00\xbb\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0^Cx00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
| dd obs=1M ibs=1M >&5
bash 0$

(Excuse the wrapping. The IP is mine from the project. Feel free to use another 
IP.
The servername encoded in there is anyway nonsense)

If you use wireshark you see in the ClientHello "TCP segment of a reassembled 
PDU" @ byte
173. That's where the first LF is encountered. The second one doesn't cause an 
additional
fragment here, other people spotted that.

The fragmentation is independent on the dd options used. Also "| cat" does the 
same.
stdbuf is not available on all platforms, especially on those who do not have a 
similar
external printf:

/usr/bin/printf  "\xf5\xee\xbe\xe5" | xxd
00000000: 7866 3578 6565 7862 6578 6535            xf5xeexbexe5

like FreeBSD and OS X. OpenBSD's /usr/bin/printf works surprisingly.


Cheers, Dirk


PS + @Bob: fd 5 is not a tty in the program -- but interactively in this PoC 
you want to make
sure it is not taken yet.