Earlier quoted context omitted.
> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server? Yes. Patch is out.
You should also reboot to ensure no running instances of bash are vulnerable.
Good point.
CVE-2014-6271: Remote code execution through bash
151–160 of 432 posts
Re: CVE-2014-6271: Remote code execution through bash
#152Earlier quoted context omitted.
> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server? Yes. Patch is out.
You should also reboot to ensure no running instances of bash are vulnerable.
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.
Re: CVE-2014-6271: Remote code execution through bash
#153Earlier quoted context omitted.
Any library anywhere in any application you run that calls out to bash that is called by any other library in that application, so long as that application is somehow hooked up to a web server, is potentially an unauthenticated GET request away from code execution; the exploit for this is potentially so simple that attackers can craft a single request, spider the Internet, and collect shells from applications you run…
So for example if you don't run web servers that are front facing on the internet (and you trust your (for example) intranet) then does this become an "asap" rather than a "drop everything"? "is potentially an unauthenticated GET request" Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?
Read "unauthenticated GET request" as "people who can do the very very simplest thing to your webserver will find this."
Re: CVE-2014-6271: Remote code execution through bash
#154Earlier quoted context omitted.
Are you certain that no method of invoking a dynamic script sets environment variables to values controlled by requests? If so, it sounds like even an innocent call to system("lame a.wav b.mp3") could lead to code execution. Edit: also, you may be surprised to find that some "libraries" are actually wrappers around external binaries (e.g. libgpgme). If any of them used a system() or exec() call that preserves environ…
Are you certain God doesn't exist? This is far from the first environment variable attack to impact CGI scripts, and CGI's successors have avoided passing data in environment variables. It's possible some moron decided to create their own CGI replacement using environment variables, but it's not going to be in widespread use.
How does nginx pass data to passenger?
Edit: also note that CUPS is vulnerable according to https://access.redhat.com/articles/1200223
Also dhclient (!)
Re: CVE-2014-6271: Remote code execution through bash
#155Earlier quoted context omitted.
> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server? Yes. Patch is out.
You should also reboot to ensure no running instances of bash are vulnerable.
The vulnerability is in bash startup; any already-running shells should be safe.
Re: CVE-2014-6271: Remote code execution through bash
#156env x='() { :;}; echo vulnerable' bash -c "echo this is a test" From https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
Whoa. I tried this, ran pacaur -Suy and .. it's patched. Arch was fast.
$ x='() { :;}; echo vulnerable' bash -c 'echo test'
vulnerable
test
$ pacman -Syu
...
$ x='() { :;}; echo vulnerable' bash -c 'echo test'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
test
Re: CVE-2014-6271: Remote code execution through bash
#157Earlier quoted context omitted.
As I understand this, any CGI script could be affected. Even if written in a different language if it turn does an os.system (or equivalent). More info here: https://securityblog.redhat.com/2014/09/24/bash-specially-cr... The permissions would only be as the web server user, but that allows all sorts of things to be run that are quite dangerous (resource exhaustion, attacking remote machines, downloading code and run…
You would still need to be able to pass arbitrary data to the bash command, and if your php (or whatever) script does that, you have a lot of other potential problems to worry about.
Because of the way cgi works you could just set a user agent or other http header to contain an 'rm' or'nc' command or something in to download and run an attack tool. E.g. You could run netcat to listen on a port or connect out to an attacker's system to provide a connection into an otherwise firewalled database server
Re: CVE-2014-6271: Remote code execution through bash
#158Earlier quoted context omitted.
Any library anywhere in any application you run that calls out to bash that is called by any other library in that application, so long as that application is somehow hooked up to a web server, is potentially an unauthenticated GET request away from code execution; the exploit for this is potentially so simple that attackers can craft a single request, spider the Internet, and collect shells from applications you run…
So for example if you don't run web servers that are front facing on the internet (and you trust your (for example) intranet) then does this become an "asap" rather than a "drop everything"? "is potentially an unauthenticated GET request" Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?
I'm sure that the people at Home Depot knew for certain that their network was secure right up until the moment they discovered they were hacked.
You can learn by experience, or you can try to leach the wisdom of others.
Re: CVE-2014-6271: Remote code execution through bash
#159Someone please ELI5 (Explain Like I'm 5)?
Re: CVE-2014-6271: Remote code execution through bash
#160Earlier quoted context omitted.
I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it. If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your…
The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. As long as you're not passing arguments from outside sources to the command, using system() should be OK.
> are not drop-in replacements since they don't take care of forking, changing the signals, and waiting.
I never claimed it as a drop-in replacement. I think you know the solution to these problems. (I guess maybe someone who naively uses system() might not, so perhaps I need to work on a better spiel.)
> As long as you're not passing arguments from outside sources to the command, using system() should be OK.
Personally I've seen too many bad uses of system() to make that a thing. Maybe they'll not realize it's subject to PATH and that PATH can be untrusted. Maybe they'll not realize they sometimes have asterisks and spaces in a filename. And so forth...