Doesn't take them long...

There was a patch yesterday, run apt-get update && apt-get upgrade.

If I were (heaven for fend) looking for a Pi or three to compromise I would look at the headers in posts to comp.sys.raspberry-pi. Giganews helpfully includes your IP address.

So your RPi is directly accessible from the internet?

My xubuntu systems have been updated already from the ubuntu repositories.

But surely 99.99% of them will be behind NAT routers so no way to get to them at all.

Exactly so.

As I understand it you need to have a port open to a hacker, and a server process standing behind it that invokes, or can be caused to invoke, bash

So maybe you have an apache webserver online.

This a potential route, BUT you also need to have a cgi-script option enabled, and you need to have bash as the default script. In debian the default is usually dash.

I am not 100% clear on the details of how CGI works in a default apache setup.

But I am doing the research.

Most likely your /bin/sh is a link to dash, not bash. Try it again with "bash" instead of "sh".

Having a vulnerable bash but a /bin/sh that is not bash means you are much less at risk than if /bin/sh was bash, but it is still worth updating to a patched version of bash.

And, there (yet again!) is the main difference between Open Source and proprietry systems, the very fast response in fixing such critical security bugs.

The most notable prior examples were a critical security issue in the TCP/IP stack in the kernel which resulted in a patch becoming available for download just four _hours_ after its discovery versus the multimedia handling vulnerability discovered in Microsoft's web browser code that they'd embedded into their kernels ever since the days of win98.

This was a vulnerability that _couldn't_ be worked around by using a third party web browser - the _only_ work around being to stop browsing the internet beyond a few trusted web sites. In this case, Microsoft bust a gut[1] in making a patch available just one week later (one whole week!).

Ok but is my Raspberry Pi on the same IP address as I use to post news? Not for me...

The vulnerability affects zillions of routers, they're shouting. Although I don't suppose many will be running BASH (I did see a report that BT Home Hubs do!) they'll have a lightweight shell like BusyBox.

Exactly. Even my DVB receiver does not have bash.

Also, the fact that some box may use bash does not mean it is vulnerable. It also needs to have some way to call bash with environment variables defined, and under a user id that can modify the system.

Ahh. I made sure I was *running* from bash, but didn't change the 'sh' in the command. I'm clearer on how that command works now -- the 'BUG' has to be fed to a bash command.

Thanks,

-- Pete --

Correct, and on most systems that means the hacker either has to have logged in as a user already, or that apache is configured to use cgi-bin AND that contains shell scripts AND those shell scripts actually run bash.

In my case yes, I have a dodgy bash, but debian uses dash as the default shell and I don't use any shell scripts in cgi-bin anyway

So the only time my web server runs bash is when I log in.

Only a web server (lighttpd) has a pass-through from the router. ... Or had -- I took it off-line yesterday, the moment I discovered the probes.

It does have bash as its cgi shell, so it won't go up again until I've upgraded. (It's only for play, anyway.)

-- Pete --

There's talk that bash will eventually be altered so that it does not import the environment by default, breaking backwards compatibility, which wouldn't affect most Linux distros which generally have scripts written to posix standards, but it might cause a lot of trouble for heavy-bash-using end-users. It's a fix that looks obvious with hindsight since bash was never intended to be a secure system, but it's just something so obscure that nobody imagined that it would behave that way.

But yes, for home users this is a non-issue, so the real test is to checkest a website for vulnerability with http:

curl -i -X HEAD "http://website" -A '() { :;}; echo "Warning: Vulnerable"'

Again only if they have some sort of accessibility open to the internet. Most routers allow you to turn off any means of access from the outside (i.e. "remote management").

The issue with that is that it only checks one particular page. I know some websites I have would pass that test, but when logged in there are subsequent pages that do use system() and so on that would subsequently fail.

Hackers know this are are tagetting url's that they know land on shell scripts or pages which call bash, etc.

)-:

Gordon

There is no need at all to do system().

When you have only a single webpage that gets served using a cgi-bin that is in fact a shellscript, you are vulnerable. This could be some part of another page, or it could even be something like a 404-handler.

Yes - but....

How many people run a web browser on a Raspberry Pi which is accessible from the internet? I would have thought very few. Just having apache on your RPi visible to other computers on your home LAN won't expose you.

You'd have to explicitly open up port 80 on your router and point it at your Rpi to get the vulnerability via apache.

Well, my Raspberry Pi is on the internet (directly accessible, no NAT router), and several other Linux systems are as well. Each with webserver.

Fortunately I don't have cgi-bin shellscripts on those. I would not be surprised when many hobby projects for controlling something via a webserver use them.