ShellShock love for OS X

Comments Off on ShellShock love for OS X

Bash Code Injection Vulnerability – CVE-2014-6271

The dangerous ShellShock ‘bug’ is here (#BashBug), following fast on the heels of the now-forgotten HeartBleed bug.  I’ve painlessly distributed it out to our 30+ macs and servers via Munki. This  newest ‘remote vulnerability problem’ is of concern to all OS X system administrators (read about how Chazelas discovered it).

In my situation (30+ macs and 3 servers) I just grabbed the packages (here) and rolled out using Munki. For my single Linux server I followed Steve’s blog (here).

If you want to know if you are vulnerable, try the following :

> env x='() { :;}; echo NOK vulnerable' bash -c 'echo hello'

Alternatively, use this: http://www.shellshocktest.com
Related vulnerabilities can be tested (read here):>curl https://shellshocker.net/shellshock_test.sh | bash

I’ve gathered a few resources here as notes to myself.

Move slowly; Some admins have lost access to Terminal by applying the wrong solution doing so incorrectly.

Patching may not be enough; The official Apple patch may still be vulnerable to environment clobbering of executables (aka ‘GameOver bug’:  @ake_ on twitter – rebuilding your own version of Bash against 3.2.55 is probably more secure than relying on Apple’s patch.).

Removing your web-server service is not sufficient. Although the most prevalent attack vector is through a web server (scripts in /cgi-bin or via SSI’s) other attacks may be via SIP, SMTP, FTP and TELNET.

Configuring your shell (for system or for accounts) to something else (like zsh or tcsh) does not preclude patching /bin/bash since any process can launch bash if it is there. Disabling Apache does not preclude patching (3rd-party apps my also use bash).

The bug is exploitable by a malicious DHCP server (e.g. WiFi hotspot) attacking your computer… but only if the DHCP client uses Bash scripts, which the OSX implementation does not (tx. AlBlue). If you’re a Hamachi user, beware, the DHCP client weakness may be buried inside that (tx. Bryan).

SOLUTIONS:

      • OS X Mavericks has a 1.0 Update you should install (here) for 10.9.5 or greater.
      • Other installers pkg installers from Apple are available for 10.7, 10.8 and 10.9.
      • Snow Leopard (10.6.8) Solutions
        1. Back up your system.
        2. Sit back and wait for Apple to come out with a fix for 10.6.8 <– not likely.
        3. Use the Missing Bash Update Installer for Snow Leopard – Jorge Chamorro – link.
        4. Possibly, the /bin/bash from a fixed Lion system can be dropped into SL.
        5. Re-compile your own /bin/bash replacement – link. – You may need to grab XCode 3.2.2 from the Apple developer downloads section – link (or from the AppStore – link) – search for Xcode 3.2.6 for 10.6.8 systems. You may run into these problems: ‘An unexpected error occurred.‘ or ‘Hunk #1 FAILED at 26.‘. Others have suggested that we can ignore the warnings ‘incompatible pointer type‘ and ‘format not a string literal and no format arguments‘.Remember that the version downloadable from the Apple opensource page has custom changes to make it work on OSX. So if the readline library included with the bash source you are compiling is not compatible with 10.6 you may need to install the GNU readline (kudos to Seth)(link) and hack the bash makefile to use it. In bash, after doing configure, in Makefile, set READLINE_LIB = /usr/local/lib/libreadline.a and do a clean compile. Then strip and copy the new bash binary on top of /bin/bash and /bin/sh. It is also necessary to set HISTORY_LIB = /usr/local/lib/libhistory.a. Otherwise bash will be dynamically linked to the /usr/local version of libhistory.When following this excellent walkthrough (link) you might encounter this error:
          * BUILD FAILED * PhaseScriptExecution ostype.h build/bash.build/Release/ostype.h.build/Script-59DC3C521120DC9C00B033EC.sh
          – You may only be missing some dependencies.
          – You may be forgetting to ‘sudo’ the xcodebuilt command.
          – You may be working in an external volume. Try working out of /tmp.
        6. Download the LION patch (link) and install it on SL with a trial of Pacifist (link). This has worked for many people
      • Tiger users (10.4) for G5 systems for example,..  look here: link and here: link.
      • MACPORTS gets you a bash version 4.3.28(1) which patched both vulnerabilities (CVE-2014-6271 and CVE-2014-7169) as well as some subsequently discovered ones but does not solve the issue of standard OS scripts as the have #!/bin/sh or #!/bin/bash.
      • HOMEBREW installs do this:
        Some users on 10.6.8 trying @AlBlue’s solution, had to give up because or these two errors:
        CodeSign /Users/bas/bash-fix/bash-92/build/Release/sh
        CodeSign /Users/bas/bash-fix/bash-92/build/Release/bash
        See the comments by CousinCocaine here – link.
        In his words, “this is the only comprehensible method for upgrading BASH on OS X 10.6.8 Snow Leopard.”
        ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”
        brew doctor
        brew update
        brew install bash
        sudo mv /bin/bash /bin/bash_old
        sudo mv /bin/sh /bin/sh_old
        sudo chmod a-x /bin/bash_old /bin/sh_old
        sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/bash
        sudo ln -s /usr/local/Cellar/bash/4.3.25/bin/bash /bin/sh
        reboot.

Also consider that most Routers (and even some printers) have Bash installed in them. OUCH. For example, the NAS’s from QNAP just got a new firmware pushed out from QNAP, so it’s not just OS X we need to be worried about. Most LINUX distros already have patches out.

Have fun.
/shawn

p.s. In my case upgrading our 30 Mac clients and 3 servers was frictionless. I populated our Munki-server with the installer packages collected from Apple. Managed Software Center on each client quietly implemented the patch.

Solutions to problems with SSH

Comments Off on Solutions to problems with SSH

Sometimes ‘ssh’ doesn’t behave as you were hoping. Here are some things to check when it goes awry.

Recall that you may have created your public/private key-pair like this:
ssh-keygen -t rsa -C "[email protected]"

You might have even gone for a heftier bit-length, or even used PKCS8:
ssh-keygen -t rsa -C "[email protected]" -b 4096 -m PKCS8

And you might have remembered to chmod the .ssh folder as 700, and any private keys as 600.

“Someone stole my laptop and got my private keys”
As quickly as you can, go delete the ~/.ssh/authorized_keys file on your destination computers. If your laptop was encrypted with FileVault you don’t have to rush.
1. update your authorised_keys file with new public keys
2. $ for host in machine1.com othermachine machine3.elsewhere.com; do scp ~/.ssh/authorized_keys $host:.ssh/; done

Do not trust the security you thought you had due to the passphrase on your private key (created by ssh-keygen) since brute forcing the passphrase only takes a few hours (read here) unless you upgraded to a more secure private key format like PKCS#8 (transparently supported by OpenSSL).
$ mv my_rsa_key my_rsa_key.old
$ openssl pkcs8 -topk8 -v2 des3 \
-in my_rsa_key.old -passin 'pass:snoopy loves secrets too' \
-out test_rsa_key -passout 'pass:snoopy loves secrets too'

Grab Brendan’s keycrypt script here.

“My private keys no longer work under 10.9 (Mavericks).”
Some suggest that Apple removed support for PKCS#8 private keys (sh-agent and keychain stopped supporting PKCS#8 ??).  You may need to undo your encryption or switch to AES256.
$ mv ~/.ssh/id_rsa_mykey ~/.ssh/id_rsa_mykey.pkcs8
$ openssl pkcs8 -in ~/.ssh/id_rsa_mykey.pkcs8 -out ~/.ssh/id_rsa_mykey
$ chmod 600 ~/.ssh/id_rsa_mykey
$ ssh-keygen -f ~/.ssh/id_rsa_mykey -p

A guy named ‘Joe’ suggested that manually adding the encrypted key, does work in 10.9:
# empty the ssh-agent and add the private encrypted key
ssh-add -D
ssh-add ~/.ssh/id_rsa

He then suggests that just reinstalling openssl solves the problem too:
brew update
brew install openssl
brew link openssl --force
brew install openssh

Finally, newer versions of ssh-keygen seem to handle PKCS#8 so openssl no longer needs to be called. Note that Windows users are out-a-luck using puttygen which doesn’t support PKCS#8.

“Roaming not allowed by server”
: Ensure that /etc/ssh/sshd_config has HostbasedAuthentication set to yes.
Remember to restart the ssh daemon: kill -HUP `cat /var/run/sshd.pid`

If you are dealing with a SynlogyDS5, and you don’t want to ssh into root, then you’ll quickly discover that ‘sudo’ won’t exist until you install it with ipkg update; ipkg install sudo. Of course, ‘ipkg’ isn’t available either (ipkg is for installing stuff that is not available in the package center), so start with that (link). Remember to add admin to the sudoers (link).

: Ensure your file permissions are correct.
As the default permissions on a SynlogyDS5 might be 777 (hard to believe) for the home folder of admin, set it them to 755 (in addition to 700 for .ssh/ and 600 for authorized_keys) and you’re good to go.