Hacker News Reader

Comment by sauere | Hacker News Reader

> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server?

Yes. Patch is out.

It appears that Linode changes /etc/apt/sources.list to point to their own mirror of Ubuntu repositories, and as far as I can tell those are not updated yet. So I guess the solution is to wait or edit sources.list. Just FYI if you're on their systems!

Just did an update on my Linode and one of the updates was

    replace bash 4.1-2ubuntu3

So seems like it's there now.

Depends on whether you have mirrors.linode.com or the ubuntu servers set up in sources.list. I had to swap mine out.

Well, I didn't even know about mirrors.linode.com. Mine were still the ubuntu default servers.

I guess apt-get from one of Linode's mirrors saves bandwidth? Or is it just more polite?

It probably ensures that you get the Linode-customized flavors of packages where such exist, so that, for example, you don't inadvertently upgrade your kernel to a build without the ability to mount Linode disks.

It's also meant to help you and Linlde save bandwidth!

Linode can't modify packages; they're signed by the upstream distro. (Unless Linode added a key of their own to your apt keychain (apt-key list), but I've never seen that.)

https://launchpad.net/ubuntu/+source/bash/4.3-7ubuntu1.1 seems to be at least one version of the fix, I'm unsure about LTS and other releases.

http://www.ubuntu.com/usn/usn-2362-1/

Ubuntu 14.04 LTS: bash 4.3-7ubuntu1.1

Ubuntu 12.04 LTS: bash 4.2-2ubuntu2.2

Ubuntu 10.04 LTS: bash 4.1-2ubuntu3.1

For releases in-between, you should be able to manually download one of those versions from http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ and install it. I wonder how many vulnerable boxes there are that won't get these updates because Ubuntu stops support after 9 months. There must be tons of boxes running 13.10, it's not even a year old yet.

It's for that reason that I just ignore anything that's not an LTS release. It's never worth the hassle for me.

For 13.10 do this, selecting correct architecture:

----------------------------------------------------------

amd64

wget archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.3_amd64.deb

sudo dpkg -i bash_4.2-2ubuntu2.3_amd64.deb

----------------------------------------------------------

i386

wget archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.3_i386.deb

sudo dpkg -i bash_4.2-2ubuntu2.3_i386.deb

Or just manually install the new version with dpkg.

If you just want to update that package then:

apt-get update

apt-get install --only-upgrade bash

fwiw, Linode's mirrors are up with the latest version yet Digital Ocean's are not. I lose faith in DO everytime I remote into my VM. They just seen like an amateurish shop.

I successfully upgraded bash on my droplets a couple minutes ago.

Seconded. I've been patched for ~40 minutes on DO.

My droplets in SFO have been updated. My droplets in nyc1 and nyc2 haven't.

And NY is updated for me as well now. Wondering why it took so long after the other DCs were updated.

Checking in 8 hours later - my droplet on nyc1 is still affected.

I am on linode and precise LTS. I did this, and I got no bash update. What am I doing wrong?

edit: and how do I know if I am still vulnerable?

edit2: ok, this is the test

  env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

and apparently I am already patched. So that's good.

dpkg -l | grep bash

WIll tell you which version of bash is installed, for precise you should have bash 4.2-2ubuntu2.2

DigitalOcean uses mirrors too, so you have to change your /etc/apt/sources.list file or wait.

I updated debian on DO like 25 minutes ago and had a crystal-clear bash update there. So I guess they updated their mirrors.

Debian security updates are distributed from security.debian.org, which is separate from the normal Debian mirror network, and Debian discourages the mirroring of security.debian.org because security updates are time sensitive. Hopefully Digital Ocean is not mirroring security.debian.org.

You should also reboot to ensure no running instances of bash are vulnerable.

Good point.

If I understood this bug correctly, it happens during bash's initialization. If I'm right, already running instances of bash are not vulnerable, and new instances will use the fixed executable, so no reboot would be necessary for this bug.

The vulnerability is in bash startup; any already-running shells should be safe.

  $ apt-cache show debian-goodies 
    <SNIP>
    checkrestart    - Help to find and restart processes which are using old
                      versions of upgraded files (such as libraries)

Reply on news.ycombinator.com