Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14711 > unrolled thread

Re: bash sockets: printf \x0a does TCP fragmentation

Started byDirk Wetter <dirk+bash@testssl.sh>
First post2018-10-11 18:53 +0200
Last post2018-10-11 18:53 +0200
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: bash sockets: printf \x0a does TCP fragmentation Dirk Wetter <dirk+bash@testssl.sh> - 2018-10-11 18:53 +0200

#14711 — Re: bash sockets: printf \x0a does TCP fragmentation

FromDirk Wetter <dirk+bash@testssl.sh>
Date2018-10-11 18:53 +0200
SubjectRe: bash sockets: printf \x0a does TCP fragmentation
Message-ID<mailman.2024.1539276811.1284.bug-bash@gnu.org>

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.

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web