Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: dirk+bash@testssl.sh
Newsgroups: gnu.bash.bug
Subject: bash sockets: printf \x0a does TCP fragmentation
Date: Fri, 21 Sep 2018 22:13:56 +0200
Lines: 46
Approved: bug-bash@gnu.org
Message-ID: <mailman.1111.1537562978.1284.bug-bash@gnu.org>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Trace: usenet.stanford.edu 1537562979 20146 208.118.235.17 (21 Sep 2018 20:49:39 GMT)
X-Complaints-To: action@cs.stanford.edu
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0
Content-Language: en-US
X-Df-Sender: NDM2MjM5
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 134.119.228.102
X-Mailman-Approved-At: Fri, 21 Sep 2018 16:49:37 -0400
X-BeenThere: bug-bash@gnu.org
X-Mailman-Version: 2.1.21
Precedence: list
List-Id: Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-bash/>
List-Post: <mailto:bug-bash@gnu.org>
List-Help: <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
Xref: csiph.com gnu.bash.bug:14628


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.

testssl.sh --assume-http -p testssl.sh

Starting from the SSLv3 ClientHello the first reassembled packet
ends with 0a.

See also discussion @ https://github.com/drwetter/testssl.sh/pull/1113.

One would assume that a bash socket connection cannot influence the TCP
fragmentation but obviously it does.

This behavior has a performance penalty and other strange effects, e.g.
if the first segment is really small, some devices reject the ClientHello.


If there's a workaround, please let me know. (tried to add "%b" with no
effect). Otherwise I believe it's a bug.

Cheers, Dirk


PS: Would ulimit -b <parameter> help?