[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUB7AjH3tcwRytNKfEjCpjm968AGvhdDdt5AZQ7Q7UxHsA@mail.gmail.com>
Date: Wed, 24 Sep 2014 11:54:18 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security@...ts.openwall.com
Cc: Chester Ramey <chet.ramey@...e.edu>
Subject: Re: CVE-2014-6271: remote code execution through bash
> My main concern with the current patch is that still exposes the bash parser
> and function definition printer to attacks from the network. Bugs in those
> fairly large components could cause another critical issue.
Yup, that surprised me when testing the patch, too - I can still get a
function called HTTP_COOKIE, for example. I worry about potential side
effects of parsing even in absence of parser bugs. In most
object-oriented languages, such side effects are practically
guaranteed. Bash may be saved by simplicity, but not sure how robust
that assumption is.
I've written more code in bash than I should have and never used
function exports, or even realized that they exist. I wonder if they
can be made optional (e.g., gated by a flag on the subprocess) without
breakage.
Another option may be to export them through specially prefixed
variables, which should be transparent but minimize the risk of
interfering with web servers and such.
/mz
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
