In the wake of shellshock

So, shellshock. It’s big. I think it’s bigger than heartbleed, because the bug has been in the code for 22 years, so there are an awful lot of systems out there with a vulnerable shell installed and nobody maintaining them properly.

One misconception I’ve seen posted across the web is that you’re not in trouble if you don’t use bash as your shell, or that you’re safe if you have dash as /bin/sh. Sadly, that’s not true. GNU tools like env will use bash to execute other programs no matter what your personal shell is. Other programs you use may invoke bash too — for example, on Ubuntu the zcat utility is a bash script. So are Firefox and Chrome.

As for exploits, basically any program which sets environment variables based on user input and uses the shell to execute something can become a vector. There’s a working exploit for Linux DHCP, so you can get pwned simply by connecting to a WiFi network. There are at least two worms spreading via the web, where you can pwn servers just by setting your web browser’s user agent to something cunning. There’s an IRC worm active, and an exploit via email has been demonstrated for some server-side software. SSH restricted mode is affected, becoming SSH totally unrestricted mode. And that’s just the stuff I know about.

At work, a colleague just asked what needs to be upgraded. My answer: Every Linux system on the planet. Prioritize ones which accept data from outside your organization (no matter how they do it). You’ll eventually want to patch everything running a Linux distibution, because the bug is also perfect for use crafting local root exploits.

Yes, it really is that bad. Even Windows systems with Cygwin are affected. Many embedded systems use busybox rather than a full shell, so (for example) your router might be safe, but I advise that you check: See if /bin/bash exists and whether /bin/bash --version reports that it really is bash. One small silver lining is that Android phones aren’t affected unless the user has chosen to install a bash shell, so we aren’t looking at a mobile phone worm apocalypse yet.

Oh, and if you patched your Linux system yesterday, patch again, because the first patch didn’t completely solve the problem, and there was a second patch released this morning.

Apple, meanwhile, still doesn’t have a patch for their old forked version of bash. Instead, they have a statement that the issue is not a problem for Mac users, so I’m sure hackers are developing OS X exploits right now.

Some people have been warning about the dangers of bash scripting for years. I’ve been bash-averse for decades; in fact, I never write shell scripts unless I absolutely have to because shell in general has so many pitfalls compared to (say) Ruby.

Of course, I’ve still had to deal with the fallout from shellshock, but I must admit I’m chuckling about the fact that purely by chance, I decided last week was the week I would finally get to grips with using Ansible to push software updates to all the servers I look after.

Another bash basher is David Jones, who has now written about why bash is bad, and provides some tips on turning your bash scripts into standard shell scripts.

If you really must continue to use bash, use unofficial bash strict mode.

OSGI “Hello World” with Eclipse Luna

If you follow a simple tutorial to set up an OSGI project, there’s a good chance that running your project will cause the console window to fill up with errors and backtraces.

The root cause seems to be that by default, Eclipse assumes that your OSGI bundle wants to run inside a complete Eclipse runtime. So when you choose Run, Eclipse tries to run your bundle inside another instance of Eclipse running inside Eclipse. This doesn’t work very well.

To get a simple “Hello world” plugin running, you need to edit the run configuration (via Run > Run Configurations...) and uncheck everything on the Bundles tab under “Target Platform” except the bundles you plan to use. Typically that’s these five:



Then on the Settings tab, you need to check the box that says “Clear the configuration area before launching”, so Eclipse will actually remove previous cached configuration information and only load the plugins you ask it to load.

Hiding your WiFi network name is security theater

Christian Huitema explains why hiding the SSID of your wireless network is pointless at best.

In short: It makes every client that ever connects to your network broadcast your network’s ID in easily sniffable form, everywhere they go.

I’ve never hidden my WiFi network name, because it won’t present any kind of challenge to anyone who is capable of getting past the WPA password. It just makes life more awkward for people who do have the password.

gunes t via Compfight