On 09/26/2014 05:13 PM, Ben wrote:
On Fri, Sep 26, 2014 at 5:57 AM, Nick <[email protected]
<mailto:[email protected]>> wrote:
its server-side only
Word of advice - don't rely on that. Bash is in a lot of things, from consumer routers to desktop software like Git, Cygwin &
various terminal clients. I had three instances of vulnerable bash executables on my Windows desktop, and while the risk of attack
through those vectors may be slim, it can't be ignored.
I would consider a router to be server-side, although most people do not think of them as servers. They are just very tiny,
specialized servers. Some of them do more server stuff then usual, such as acting as print servers and network storage.
Keep in mind what the exploit does. It tricks Bash into running things by modifying the environment. For you to be at risk, you
must first have something untrusted modifying your environment before calling a Bash script. Then, that Bash script must be used in
such a way to have access to something that the original thing that modified the environment did not. Otherwise, this flaw is not
useful.
In other words, this exploit, by itself, does not leak any data. You must first have put Bash in a place of trust between an
untrusted environment and a trusted one. Experienced software administrators and software developers generally know better because
locking down shells requires knowing just about everything about them. Restricted shells exist for this purpose and should be used
for this reason. Unfortunately, not everyone got this warning.
CGI scripts and sudo Bash scripts are the first things that I think of that can place Bash between untrusted and trusted
environments, but sudo already filters the environment by default. For example:
Without sudo:
# env x='() { :;}; echo vulnerable' bash -c 'echo This is a test.'
vulnerable
This is a test.
With sudo:
# env x='() { :;}; echo vulnerable' sudo bash -c 'echo This is a test.'
This is a test.
If sudo was configured to let environment variables through, then any user that has sudo enabled (usually not on by default unless
you installed the operating system and generally requires your password to use) can run things as root.
So Bash scripts that are run as the same user that called them (and that user normally has access to a shell) are not at risk, which
is why I am not worried about desktop tools that happen to use Bash, such as git.
--
You received this message because you are subscribed to the Google Groups
"neonixie-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send an email to [email protected].
To view this discussion on the web, visit
https://groups.google.com/d/msgid/neonixie-l/5425E74F.3070308%40matthewc.net.
For more options, visit https://groups.google.com/d/optout.
