Shellshock

Open forum for security issues and info.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
robespierre
Posts: 1578
Joined: Mon Sep 12, 2011 2:28 pm
Location: Boston

Re: Shellshock

Unread postby robespierre » Sat Oct 18, 2014 1:02 pm

Code: Select all

x=0
echo onetime | while read line; do
    x=1
done
echo $x


this is a classic "led down the garden path" situation, which you do need to have some programming ability to notice.

you concluded that "It's something stupid related to pipes and processes"; in other words, that the statement "x=1" was not affecting the value of x, because it (surprisingly) executes in a different process. this is an unwarranted assumption, since it might not have affected x simply by never executing at all.

Code: Select all

x=0
echo onetime | while read line; do
    touch quux
done
ls quux

ls: quux: No such file or directory

for those who "do a lot of shell scripting" and are led astray by such basic mistakes, the greater danger may not be their choice of shell, but letting them near computers to begin with.

Code: Select all

echo foo bar | read line; echo $line

is a newline, because line is empty.

Code: Select all

echo foo bar |& read -p line; echo $line

and

Code: Select all

echo foo bar | exec 4<&0; read -u4 line; exec 4<&-; echo $line

and

Code: Select all

echo foo bar | read -N8 line; echo $line
work as expected. the read runs without spawning a subshell; where it differs from other shells is in its handling of stdin: by default, if stdin is not a terminal, read doesn't wait for its input, but returns immediately if there is no data.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:

User avatar
jwp
Posts: 156
Joined: Sun Nov 18, 2012 7:14 pm
Location: China

Re: Shellshock

Unread postby jwp » Mon Oct 20, 2014 6:34 am

robespierre wrote:this is a classic "led down the garden path" situation, which you do need to have some programming ability to notice.

you concluded that "It's something stupid related to pipes and processes"; in other words, that the statement "x=1" was not affecting the value of x, because it (surprisingly) executes in a different process. this is an unwarranted assumption, since it might not have affected x simply by never executing at all.

It might be an unwarranted assumption, except for the fact that I tested this pretty carefully years ago, and then again recently.

robespierre wrote:

Code: Select all

x=0
echo onetime | while read line; do
    touch quux
done
ls quux

ls: quux: No such file or directory

for those who "do a lot of shell scripting" and are led astray by such basic mistakes, the greater danger may not be their choice of shell, but letting them near computers to begin with.

Sorry, but your script results are wrong using all the shells I'm talking about. All of them create the file quux, and then list it successfully, as you can see here:

Code: Select all

$ cat > quux.sh
echo onetime | while read line; do
    touch quux
done
ls quux
$ dash quux.sh
quux
$ ksh93 quux.sh
quux
$ mksh quux.sh
quux
$ bash quux.sh
quux

So you posted bogus results, and then sneered that I shouldn't even be allowed near a computer? Okay... if you want an even simpler example:

Code: Select all

$ cat > inloop.sh
echo onetime | while read line; do echo inloop; done
$ for shell in dash ksh93 mksh bash; do $shell inloop.sh; done
inloop
inloop
inloop
inloop

The shell loops work just fine.

robespierre wrote:

Code: Select all

echo foo bar | read line; echo $line

is a newline, because line is empty.

Yeah, that's why the example scripts I gave never piped to "read", but rather to "while read", like this:

Code: Select all

$ echo foo bar | while read line; do echo $line; done
foo bar

So you didn't bother to notice the difference, yet you're the one with the "real programming ability" who is able to spot these things. Yeah, okay... :roll:

One last script to illustrate the incompatibility:

Code: Select all

$ cat > inloop2.sh
x=1
echo onetime | while read line; do
    x=2
    echo "inloop: $x"
done
echo "endloop: $x"
$ ksh93 inloop2.sh
inloop: 2
endloop: 2
$ mksh inloop2.sh
inloop: 2
endloop: 1

I'm not some big shell scripting guru, but I'm also not a bumbling idiot who just makes this stuff up because I just lack "real programming ability." I ran into this particular problem because real shell scripts I was writing for HP-UX servers would fail in Cygwin because pdksh and mksh are not faithful ksh88 clones. This sort of incompatibility is dangerous because there is no indication of it other than getting the wrong (old) variable values. Other people have run into it as well, usually when they try to migrate their ksh88 scripts to Linux, and then run into all sorts of errors.
Debian GNU/Linux on a ThinkPad, running a simple setup with FVWM.

robespierre
Posts: 1578
Joined: Mon Sep 12, 2011 2:28 pm
Location: Boston

Re: Shellshock

Unread postby robespierre » Sat Oct 25, 2014 12:53 pm

Those tests were all done using "sh (AT&T Labs Research) 1993-12-28 p". the point is that even "ksh93" does not run the example as expected.

I think that the behavior of bash/dash is informed by POSIX.2:
Additionally, each command of a multi-command pipeline is in a subshell environment; as an extension, however, any or all commands in a pipeline may be executed in the current environment.
They interpret it to require that the behavior as respects variable assignment be as if the command was executed in a subshell, even though it is not.
:PI: :O2: :Indigo2IMP: :Indigo2IMP:


Return to “SGI: Security”

Who is online

Users browsing this forum: No registered users and 1 guest