OT: "ShellShock" bash shell vulnerability...

[Nick]

Genuine 10/10 nastiness for web-servers that use Bash CGI - you have all probably heard about this one - its potentially far far worse than the OpenSSL HeartBleed one... This is what I sent to all our staff yesterday:

Introduction

Many of you will have read about this in the press. For those that haven’t, the simple summary is that the Bash shell that is used to execute CGI requests on most of the world’s web servers has had a huge and easily-exploitable hole in it for 20 years. As everyone uses the same version of the Unix toolchain, everyone uses the same “Bash” and thus all Unix-based are equally vulnerable.

Its rated as being far worse in real terms than the “HeatBleed” SSL issue, in that rather than “just” being able to trawl the memory space of the remote web server for username/password combos or private RSA keys, you can basically do what you like  - you can execute arbitrary command in the context of the remote shell – it’s really easy/trivial to exploit this bug – examples in the link below.

RedHat have probably the most concise description of this issue – see https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

Note that the fix that was originally posted was incomplete – a new fix is yet to be delivered.

How does this affect me?

Possibly a lot, in that sites that you access and which have your data stored on them may well be completely open to attack. If you run your own web sites (nearly all run some variant of Linux), you should replace your Bash as soon as an approved fix is available.

However, there is nothing you, as a client browser, can do to lessen your chances of being indirectly affected by such an attack – its server-side only and therefore up to each Unix-based website that used Bash-based CGI scripting to implement the fixes ASAP, or to simply disable Bash CGI until the fix is made.

This is being actively used in the wild already - a botnet was discovered within hours of the announcement - cunningly, it uses wget or curl to download the botnet precursor, does a chmod 777, then executes the downloaded code to subvert the host and add it to the botnet.

EDIT:Just had a thought about all this – most routers/firewalls run some form of embedded Linux – typically a version of BusyBox – if you have external (Internet-facing) HTTP or HTTPS access enabled for remote management etc., then you may well be vulnerable and should seriously consider disabling remote management on the router until the supplier provides a safe upgrade… specifically, if the shell in your router is "bash", then disable remote http[s] access; if its "ash", you should be ok - BusyBox uses "ash" by default.

Nick

[NeonJohn]

On 09/26/2014 05:57 AM, Nick wrote:
> Genuine 10/10 nastiness for web-servers that use Bash CGI - you have all
> probably heard about this one - its potentially far far worse than the
> OpenSSL HeartBleed one... This is what I sent to all our staff yesterday:

> Note that the fix that was originally posted was incomplete – a new fix is
> yet to be delivered.

What I love about Canonical/Ubuntu community. They pushed out their own
fix last night. And my web hosting service, Dreamhost.com, sent out an
announcement that they had engineered their own patch. NO waiting for
patch Tuesday or whatever.

John


--
John DeArmond
Tellico Plains, Occupied TN
http://www.fluxeon.com <-- THE source for induction heaters
http://www.neon-john.com <-- email from here
http://www.johndearmond.com <-- Best damned Blog on the net
PGP key: wwwkeys.pgp.net: BCB68D77

[Ben]

On Fri, Sep 26, 2014 at 5:57 AM, Nick <ni...@desmith.net> 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.

[Charles MacDonald]

On 14-09-26 11:45 AM, NeonJohn wrote:
>
>

> What I love about Canonical/Ubuntu community. They pushed out their own
> fix last night. And my web hosting service, Dreamhost.com, sent out an
> announcement that they had engineered their own patch.

SECOND update today. what is a concern is all the "appliance" type
systems which are not updated or even update-able in the normal course
of business..

--
Charles MacDonald Stittsville Ontario
cm...@zeusprune.ca Just Beyond the Fringe
http://Charles.MacDonald.org/tubes
No Microsoft Products were used in sending this e-mail.

[Dman777]

Of course, the news blows this out of proportion being it's full of non-tech apple users in the media.

Most embeded devices that use linux use busybox shell, not bash.

Also, the media fails to mention that a user first needs access to a system running bash...ssh itself does not run bash. 

Ya, that is a drag about web-servers using CGI being vulnerable. BUT...if people used Node.js, the most superior webserver/platform in world :), they would not have this issue since Node.js type web servers do not need any CGI...they sit behind a front end reverse proxy(Nginx, etc) and listen on localhost. No interface necessary at all! In addition...native non blocking I/O. Something CGI's require tweaking/bloating to accomplish.

-Darin 

On Friday, September 26, 2014 4:57:32 AM UTC-5, Nick wrote:

Genuine 10/10 nastiness for web-servers that use Bash CGI - you have all probably heard about this one - its potentially far far worse than the OpenSSL HeartBleed one... This is what I sent to all our staff yesterday:

[Matt]

On 09/26/2014 05:13 PM, Ben wrote:

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.

[Dman777]

I use dd-wrt firmware on my router. It's been about 4 years. I can't remember what shell is on it and I am to lazy to enable ssh to go and check :P Ether way...it's so old it would be before the vulnerability. 

Again, I wish the world would start using Node.js...no CGI required and it's the best platform for backend webservers. It's what LinkedIn uses for their there mobile website connections(50% of all connections). 

[Nick]

The world will never entirely switch to node.js - the simple fact is that most ISPs worldwide do not provide node as an option, let alone as the default option - Apache is the default, CGI is dominant due to its simplicity and Bash is the default shell. The sheer mass of Apache CGI sites means that node won't be dominant for many years yet, if at all.

I stated in the OP that embedded Unix tends to use ash rather than Bash by default (it matters not one jot that its BusyBox or some other Unix variant), and FWIW, the Bash vulnerability goes back way more than 4 years - its pretty much been there since inception - certainly more than 20 years in the GNU chain (which is the one that everyone, including Apple, uses).

FYI - dd-wrt is based on the original GPL'd Linksys f/w which uses ash as its shell.

Nick