Doesn't take them long...

Reading about the Shellshock bug on the BBC this morning, I immediately went and checked the logs of lighttpd running on my RPi.

Sure enough there were half a dozen probes of the bash vulnerability!

Interestingly, though, if I try the published test command [1] directly, it shows the Pi (running bash 4.2.37(1)) not to be vulnerable -- even though the version is supposedly in the buggy range! The output is different from a patched bash, though. It just ignores the trap and goes on to execute the following command (so I only see "this is a test").

-- Pete --

[1] env BUG='() { :;}; echo vulnerable' sh -c 'echo this is a test'
Reply to
Pete
Loading thread data ...

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

Reply to
A. Dumas

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.

--
Graham. 

%Profound_observation%
 Click to see the full signature
Reply to
Graham.

So your RPi is directly accessible from the internet?

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

--
Chris Green
Reply to
cl

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

--
Chris Green
Reply to
cl

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.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

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.

--
Geoff Clare
Reply to
Geoff Clare

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!).

[1] Microsoft's record prior to that event was not good in regard of speedy deployment of critical patches and updates (in fact, the matter of even addressing such issues was such that, according to Secunia's stats, IE had a total of 75 known vulnerabilities of which 25 remained unaddressed some of which were several years old (Firefox at that time had 25/5 and Opera 0/0).
--
J B Good
Reply to
Johny B Good

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

Reply to
Rob

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.

Reply to
Rob Morley

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.

Reply to
Rob

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 --

Reply to
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.

--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher

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 --

Reply to
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"'

Reply to
Dave Farrance

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").

--
Chris Green
Reply to
cl

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

Reply to
Gordon Henderson

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.

Reply to
Rob

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.

--
Chris Green
Reply to
cl

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.

Reply to
Rob

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.