[Help-bash] Possible security issue (was: Variables in substitution replacements)

[David Niklas]

On Thu, 1 Sep 2016 07:04:44 <address@hidden> wrote:
> 
> On Thu, Aug 25, 2016 at 2:52 PM, Chet Ramey <address@hidden> wrote:
> > On 8/10/16 12:29 AM, Eli Barzilay wrote:  
> >> The following seems like a weird behavior, given the context I doubt
> >> that it's a bug but it seems good to confirm, just in case.
> >>
> >> I'm trying to replace a character given via a variable by something
> >> else, and I thought that this should do it:
> >>
> >>     "${str//$r/<>}"
> >>
> >> but it looks like this doesn't work, since ... the contents of $r is
> >> partially re-interpreted as a pattern??  That's the only explanation
> >> I have for...  
> >
> > I'll take a closer look at this after bash-4.4 is released.  
> 
> Well, just so it's clear -- the thing that threw me off is my assumption
> that the only place where a quoted context becomes unquoted is inside a
> "$(...)".  My conclusion from all of this is that in the above the $r is
> another such place and therefore it should be
> 
>     "${str//"$r"/<>}"
> 
> 
> > In some cases, since the variable expansion may contain characters
> > that are special to pattern matching, the $r may be interpreted as a
> > pattern.  Quoting the $r will suppress that.
> >
> > In case you're wondering, the outer quotes around the parameter
> > expansion don't have any effect on pattern matching characters in $r;
> > if you want them to be treated as literal characters, quote $r.  This
> > is how bash and ksh93 treat these examples.  
> 
> Yeah, that's clear to me now -- and like I said, I wonder how many
> scripts are broken with this.  As a quick test, I ran this:
> 
>     find . -type f | while read f; do
>       read -n 30 l < "$f"
>       if [[ "$l" != "#!"* ]]; then continue; fi
>       if [[ "$l" != *"/sh"* && "$l" != *"/bash"* ]]; then continue; fi
>       grep -nH -e '\${[a-zA-Z0-9_]*[/#%][^}"]*\$' "$f"
>     done
> 
> in /usr and my guess is that many of these should be quoted...
> 

I just did this and the list is a long one.
Shouldn't these be reported upstream or something?
Some of these are not quoted at all.
It looks like a crackers heaven, feed something into the unquoting shell
script, and boom, any user account might be compromised.
I'm thinking:
1. User downloads innocent file (even a debug log of some network program
could contain a malicious string (like a url (even an incorrect one)).
2. User runs cool command on it.
3. File exploits weakness.
And then (assuming that the cracker is a regular user),
1. Root runs command.
2. Command enters compromised dir.
3. Cracker is now root.

I don't think many admins are aware of this. I've never heard of it till
now. I always expected that the shell programmers knew what they were
doing.

Of course, I don't pretend to know how to perfectly quote a string in
bash automatically. When I have the need I use detox(1) or find >
list-of-files.txt edit list-of-files.txt.

Sincerely,
David