CVE-2014-6271: Remote code execution through bash

So I took a great unix/linux systems programming class, http://sites.fas.harvard.edu/~lib215/ where you learn about all of the system software that you take for granted. Among other things, we had to write our own shell. There is an awful lot to consider, and most of it you are just trying to get to work properly. With regard to security, you feel like you are protected for the most part because the shell resides in userland and it's basically understood that you shouldn't trust foreign shell scripts.

Is the worry here that the code gets executed by the kernel or superuser, enabling privilege escalation? Otherwise it wouldn't be a big deal that extra code is executed by a function declaration.

Re: CVE-2014-6271: Remote code execution through bash

#7

Post by hijinks » Wed, Sep 24, 2014, 2:48 PM UTC

kalops wrote: post #3

so basically turn off AcceptEnv in sshd_config?

I don't think so. From what I've been reading it can be exploited via http requests. I'm sure a metasploit script is right around the corner.

Edit: oh looks like only like mod_cgi related stuff is.. thats good then sort of

Re: CVE-2014-6271: Remote code execution through bash

#8

Post by sauere » Wed, Sep 24, 2014, 2:50 PM UTC

No update out for Ubuntu Server 14.04 yet.

/edit: the Red Hat blog has a good overview https://securityblog.redhat.com/2014/09/24/bash-specially-cr...

Re: CVE-2014-6271: Remote code execution through bash

#9

Post by drzaiusapelord » Wed, Sep 24, 2014, 2:52 PM UTC

Oculus wrote: post #4

Have big security vulnerabilities been cropping up more often recently or does it seem that way because I've started to pay attention?

Its been a bad time for FOSS/Linux systems. Heartbleed, the occasional priv escalation, apt-get, bash, etc. Or whatever the hell happened at TrueCrypt. Or the recent AOSP browser bug in Android that probably won't be patched by any OEM/Carrier. These are all pretty serious issues. Not to mention the endless wave of malware targeting Windows systems, especially the evil cryptolocker ransomware.

I really do think heartbleed was a wake-up call for some people and a lot of extra auditing is being done, perhaps with some healthy paranoia fueled by the recent NSA allegations. Software, in general, imo, is pretty insecure. The exploits, bugs, etc are out there and if you'll find them if you look hard enough. Considering software is always being updated, that also means news bugs and security issues.

As a sysadmin, I've just seen too often how the sausage is made. I have zero illusions about security. There are just too many avenues to compromise, be it via software or via plain-jane social engineering. I think one day in the future we (or our children) are going to look back at the age of viruses and buffer overflows and wonder how the hell we managed to get by, the same way I look at cars from the 50s-60s that suffered from things like vapor lock, were incredibly unsafe, and other issues that really don't exist today.

Re: CVE-2014-6271: Remote code execution through bash

#10

Post by dtech » Wed, Sep 24, 2014, 2:53 PM UTC

khaki54 wrote: post #6

So I took a great unix/linux systems programming class, http://sites.fas.harvard.edu/~lib215/ where you learn about all of the system software that you take for granted. Among other things, we had to write our own shell. There is an awful lot to consider, and most of it you are just trying to get to work properly. With regard to security, you feel like you are protected for the most part because the shell resides in…

It allows arbitrary code execution if an attacker can modify environment variables through other software.

Most webservers put certain HTTP headers in environment variables. I can certainly see the how this could be exploited.