17 Nov
2015
17 Nov
'15
11:55 p.m.
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?
18 Nov
18 Nov
1:38 a.m.
Random832 <random832(a)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
1:50 a.m.
New subject: Interesting post by Rob Pike in 1985: Shells, features and interaction
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(a)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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
1:47 p.m.
Brantley Coile <brantleycoile(a)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(a)gmail.com> http://chneukirchen.org
2:56 a.m.
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…
Erik <fair(a)netbsd.org>
6:15 a.m.
New subject: Interesting post by Rob Pike in 1985: Shells, features and interaction
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
6:36 a.m.
"Erik E. Fair" <fair-tuhs(a)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)
3288
days inactive
3289
days old
6 comments
5 participants
participants (5)
-
Brantley Coile -
Christian Neukirchen -
Erik E. Fair -
Kurt H Maier -
Random832