Shellshock is worse than heartbleed

In part because, well, the patches don’t seem to cover all the exploits. For the gory details, look at the CVE list here. Then cut and paste the local exploits.

Even with the latest patched source, built from scratch, there are active working compromises.

With heartbleed, all we had to do was nuke keys, patch/update packages, restart machines, cross fingers.

This is worse, in that the fixes … well … don’t.

Many many years ago, I began my Unix journey on Unicos on an Cray XMP or YMP at Pittsburgh Supercomputer Center, running some code to generate MD trajectories and energies. I hated the native shell, so I pulled down tcsh, and built it. Stored it in the local small space they gave researchers. It made using the CLI tolerable.

In the late 90s I switched to bash as this is what Linux used as its default, and I was working mostly on Linux by the end of that decade.

I am thinking of switching back to tcsh (though this could be vulnerable as well, albeit to different exploits).


Viewed 63045 times by 7919 viewers


6 thoughts on “Shellshock is worse than heartbleed

  1. FWIW, x86_64 bash stable in Gentoo (app-shells/bash-4.2_p50) does not have any vulnerabilities. They’ve done a great job tracking this problem and I’ve almost always been able to instantly run emerge sync;emerge –update bash and any new vulnerability is patched right up on my servers. Gentoo doesn’t make me happy 24/7, but this time around I was really, really glad to be running that on all my systems.

  2. @Chris_bloke Yeah, you are right. I am just grousing. I am willing to bet that many other bugs exist that are similar in concept/impact, that aren’t quite known yet. And given the need/ubiquity for a shell structure, and the embedded nature of using environment variables to pass data (poor design choice now a permanent part of a stack), we need to look at this carefully. Way back in the day, I used lots of perl taint mode bits. It made programming a little more painful, and required regex extraction, but it was also much harder to cause problems like this. I wonder if we need a taint mode in shells.

  3. @Ellis CentOS/RHEL emitted a patch. Which didn’t cover everything. So they emitted another patch. Which didn’t cover everything. Rinse, repeat. Debian issued patches. Some of which would not install. Ubuntu followed the CentOS/RHEL model.

    Now I have nervous customers, exploit test cases that indicate existing vulnerability on “patched” systems.

    Good for Gentoo on this, but check out the page I linked to. Test some of the later CVEs. Its … unnerving … that we don’t really have the problem fully scoped/fixed yet.

    Going back to the source on this, and we’ll have to maintain this for customers until the distros can get their acts together, and the CVEs stop rolling in.

  4. Yea, I had already checked out that link. Thanks for sharing that. From my update two days back, it only failed the last exploit. The update to r50 this morning fixed that.

  5. On Debian and derived systems, /bin/sh has been non-bash (dash) for a long time. Lazy people who just write #!/bin/sh are safe there, no function exporting. Checking /etc/passwd… ugh, a few services default to using bash (gitolite, postgres). Those gotta change.

Comments are closed.