[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[Random832]

https://groups.google.com/d/msg/net.unix/Cya18ywIebk/2SI8HrSciyYJ

Apparently the 8th Edition shell had the ability to export functions via
the environment.

I'm wondering - were there (are there?) any other shells other than bash
that picked up this feature? How was it implemented, considering this
was the cause of the "Shellshock" vulnerability?

[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[Random832]

Random832 <random832 at fastmail.com> writes:
> I'm wondering - were there (are there?) any other shells other than bash
> that picked up this feature? How was it implemented, considering this
> was the cause of the "Shellshock" vulnerability?

I was able to find the information on how it was implemented in 8th
edition: Environment strings of the form "name(){value}", contrary to
pre-shellshock bash's "name=(){value}" - the latter certainly looks like
it was inspired by the former, though.

http://man.cat-v.org/unix_8th/5/environ

[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[Brantley Coile]

Tom Duff's shell, rc, exports the functions as variables as well. You can find it in the Plan 9 Ports utilities. Byron Rakitzis also write a version of rc.

> On Nov 17, 2015, at 5:55 PM, Random832 <random832 at fastmail.com> wrote:
> 
> https://groups.google.com/d/msg/net.unix/Cya18ywIebk/2SI8HrSciyYJ
> 
> Apparently the 8th Edition shell had the ability to export functions via
> the environment.
> 
> I'm wondering - were there (are there?) any other shells other than bash
> that picked up this feature? How was it implemented, considering this
> was the cause of the "Shellshock" vulnerability?
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[Christian Neukirchen]

Brantley Coile <brantleycoile at me.com> writes:

> Tom Duff's shell, rc, exports the functions as variables as well. You
> can find it in the Plan 9 Ports utilities. Byron Rakitzis also write a
> version of rc.

Note that Plan 9 rc is susceptible to a Shellshock-style attack,
whereas Byron's rc is not.

https://bitbucket.org/rsc/plan9port/issues/187/shellshock-on-rc-1

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[Erik E. Fair]

That function export feature of bash was not the cause of the
Shellshock vulnerability.

The cause was idiot programmers who wrote CGI scripts for bash
without proper data sanitization.

See also
https://www.quora.com/Are-there-any-projects-to-replace-bash-the-Unix-shell/answer/Erik-Fair


	Erik <fair at netbsd.org>

[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[Kurt H Maier]

On Tue, Nov 17, 2015 at 05:56:28PM -0800, Erik E. Fair wrote:
>
> The cause was idiot programmers who wrote CGI scripts for bash
> without proper data sanitization.
>

No, the cause was "idiot programmers" who did not stop processing the
function definition when the function ended.  Bash was not conformant
to its own syntax specification.   Then they had to fix the same bug for
here documents.  While fixing that, someone discovered stack smash among
other bugs in the parser.

Data santitization is important, but that doesn't mean bash doesn't
suck.  The fix wasn't "stop exporting functions into the environemnt,"
the fix was to patch bash.  Several times.

khm

[TUHS] Interesting post by Rob Pike in 1985: Shells, features and interaction

[Random832]

"Erik E. Fair" <fair-tuhs at netbsd.org>
writes:
> That function export feature of bash was not the cause of the
> Shellshock vulnerability.
>
> The cause was idiot programmers who wrote CGI scripts for bash
> without proper data sanitization.

The manner in which bash (pre-shellshock) imported functions from the
environment, along with the vulnerability, made "proper data
sanitization" flatly impossible without deep knowledge of what kind of
strings it was looking for. It would import functions from absolutely
any variable, with any name, including variables explicitly designated
in the protocols involved to hold untrusted remote data.

Removing text in a format that triggers a feature of a particular shell
from HTTP_COOKIE is absolutely not the CGI script's responsibility (the
bug triggers before the script gets to execute a single line), and I
would argue it's not the HTTP server's problem either.

And if the bash feature had been implemented correctly, it would have
been mostly harmless (The remote client could still have caused a
function called HTTP_COOKIE to be defined, but the script's almost
certainly not going to execute it)