Two points Nathan.

Squid discourage the usage of bash helpers in general but there are couple nice codes which helps with that.
Let alone this using environmental variables is bad for storing all sorts of things!!.
Squid by itself do not use environmental variables at all else then in build and install times.
There are bash scripts that start and stop squid but they do not come from the squid project and most of them are pretty safe.

Also squid validates the user input quite good as far as I know and no it doesn't use environmental variables in any way to transfer them.

Squid log parsers should not use environmental variables since they are a bad choice and not only from the point of view of bash vulnerability.

It's common practice for squid helpers(and also for other purposes in general) to be in the form of a scripting language such as perl\python\other and only for "counters" in bash.

Squid logs can be used in two formats: escaped\unescaped urls (default unescaped) which can in a way be a trigger while the strict HTTP rfc is enforced and can prevent lots of these issues.

One script that can might be vulnerable is cache manager CGI script(which is written in perl) but this interface should not be needed due to the existence of squid-internal-mgr interface since squid 3.2.

Indeed there are so much scenarios out there but..
As long as your SSH is firewalled you can feel better.
As long as your httpd has fail2ban\FW\restrictions or uses php with no system calls you are quite safe there.
(with good FW rules)As long as your ssh users are aware of basic security constrains the system is pretty safe.

etc..

Indeed if you have a VYos or Vyatta.. protect it as you can.

Eliezer

On 09/28/2014 02:49 AM, Nathan Ward wrote:

On 28 September 2014 at 12:30:16 pm, Eliezer Croitoru
(eliezer@ngtech.co.il <mailto:eliezer@ngtech.co.il>) wrote:

>From the other hand once you have some grasp on the basic affected
scenarios (which should be listed somewhere) some of them can be
prevented using simple means while others cannot.

The point is that the scenarios are vast, so any such list is going to
give a false sense of security.

For example, you work with Squid. If someone wrote a log parser that
called some bash script with the content of the URL as an env var, you���d
potentially have problems.
Same if someone wrote an auth handler that set the username in an env
var and then called a bash script. This is perhaps unusual, but is
reasonable - perhaps some 3rd party auth database provides scripts that
can be used to authenticate users.

Given that, does Squid filter out all the possible ways to exploit this
bug? It is unreasonable to suggest that the person who wrote the auth
handler should have known that the 3rd party script was written in bash
- perhaps they upgraded recently, and the vendor changed how something
worked.

Worth noting, a quick scan of the source code suggests that Squid itself
doesn���t use env vars to pass things to ���program��� handlers, which means
Squid is not directly going to trigger this, which is handy.

These are some contrived examples, but, I think it illustrates the
point. Upgrade bash and fix the core of the problem, don���t mess about
patching stuff around it hoping you caught everything - and hoping you
catch everything in the future.

--
Nathan Ward

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog