bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash sockets: printf \x0a does TCP fragmentation


From: Dirk Wetter
Subject: Re: bash sockets: printf \x0a does TCP fragmentation
Date: Wed, 26 Sep 2018 08:17:39 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0


On 9/25/18 2:15 PM, L A Walsh wrote:
> 
> 
> On 9/24/2018 6:05 AM, Greg Wooledge wrote:
>> On Sat, Sep 22, 2018 at 11:50:17AM +0200, address@hidden wrote:
>>  
>>> On 9/22/18 7:30 AM, Bob Proulx wrote:
>>>    
>>>> address@hidden wrote:
>>>>      
>>>>> printf -- "$data" >&5 2>/dev/null
>>>>>         
>>>> What happens if $data contains % format strings?  What happens if the
>>>> format contains a sequence such as \c?  This looks problematic.  This
>>>> is not a safe programming proctice.
>>>>       
>>
>> Looking ONLY at this one line, there is an obvious bug, which Bob has
>> pointed out.  It should be
>>
>> printf %s "$data" >&5 2>/dev/null
>>   
> ----
>    This brings to mind a consideration:
> As %s says to print a string of data (presumably not
> including a NUL byte), 

it certainly does contain a null byte, and every other chars
between 1-255. That's the point of a network socket.

Also "$data" will NEVER contain user input in any way
with one exception being the hostname which is transferred
via hexdump into exactly this format.

Other than that "$data" is populated purely internally. It can't
contain anything else between '\x00' and '\xff' unless there's a
coding error which could be a good idea to catch before
and not here.

This is why I said you can't look only at one line of
code.

Code reviews requires to see the whole picture.

BTW: printf seems to be off the table. BSDish /usr/bin/printf
is completely different compared to the the coreutils incarnation.
OpenBSD has per default not even a printf outside bash.

> then what happens if "$data" is
> a paragraph of text with embedded newlines.  In that case,
> it sounds like bash might break apart the single printf
> output into smaller packets rather than transmitting the
> entirety of "$data" in 1 write (presuming it is less than
> the maximum data size for a network packet).

yup.

Wonder why the coreutils printf behaves (in my sense) better
than the bash-builtin.

>    Also, if you want to flush the data out at the end, it seems
> "%s\n" would be required to force out the last line of text if
> it wasn't nl terminated.
> 
>> That is utterly horrifying.
>>   

I take that as a compliment :-)

> ---
>    Hmmm....I didn't realize how sensitive some sensibilities were...
> :-)

LOL

There are JavaScript frameworks in the browser of similar size or
even bigger, the kernel I am using right now is written in a language
which is not known to be safe and whose parser after 25 years throws
sometimes utterly misleading errors -- which still remind me on the
first K+R c compilers -- this and other things I found rather horrifying.

Script languages have long evolved -- you should take this really as a 
compliment --
and as I started this project I never thought it would boldly go there :-)

Cheers, Dirk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]