Am I vulnerable if using the Paperclip gem to manage file uploads on a Rails app (it internally fires up 'convert' to generate thumbnails, I believe).
What if there is an haproxy sitting in front of the Rails app?
CVE-2014-6271: Remote code execution through bash
171–180 of 432 posts
Re: CVE-2014-6271: Remote code execution through bash
#172Earlier 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 like the DHCP attack vector which was mentioned in the RedHat posting. DHCP clients invoke shell scripts.
Re: CVE-2014-6271: Remote code execution through bash
#173so basically turn off AcceptEnv in sshd_config?
Also don't use bash for running any scripts. You never should anyway, in a sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash which is not vulnerable. Unfortunately the Redhat derived distros do use bash as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash is for users not scripts.
Anyone able to express how this affects the default client configuration on Mac desktops and servers?
Re: CVE-2014-6271: Remote code execution through bash
#174Is it just me, or are the patches "fixing" the vulnerability woefully insufficient? With the patch, bash stops executing the trailing code, but it still allows defining arbitrary shell functions from environment variables. So, even though the patch fixes the ability to exploit this via SSH_ORIGINAL_COMMAND or HTTP_*, anything that can set environment variables can still override an arbitrary command. (Note that privi…
It's not just you. The fact that an environment variable can override e.g. "git" to do something else is a real problem requiring separate protection. However, that's effectively PATH injection rather than code injection so it's already addressed in many cases.
Re: CVE-2014-6271: Remote code execution through bash
#175Earlier quoted context omitted.
I think it comes down to a jargon vs technical language thing. In formal settings arbitrary code execution is a different thing from privilege escalation. In casual jargony talk though, security guys tend to equate code execution with privilege escalation with box ownage. Basically it goes "why would anyone not follow the execution -> escalation -> own path?" It's such an automatic assumption, combined with the basic…
None of this seems crazy unlikely, but I'd still like to hear a confirmation that that's what was meant. Especially since korzun was talking specifically about Debian and Ubuntu where bash is only used as a login shell and so presumably those with access could already just run the app.
There are unfortunately lots of bad scripts in the world that start with:
#!/bin/bash
#!/bin/bash
echo "loser!"
vagrant@ubuntu-14:~/bin$ X='() { :; }; echo foo' python
Python 2.7.6 (default, Mar 22 2014, 22:59:56)
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.system("./foo.sh")
foo
loser!
0
>>> import subprocess
>>> subprocess.Popen("./foo.sh")
>>> foo
loser!
https://wiki.ubuntu.com/DashAsBinSh
That recommends changing broken scripts to #!/bin/bash or changing to sh == bash as solutions. I would guess that there are going to be plenty of easily vulnerable debian/ubuntu systems.
More importantly though, it literally does not matter if this bug is "directly privilege escalating" or "1 step removed privilege escalating", the are fundamentally the same thing. It doesn't matter in any case where a script is executed with bash instead of dash.
Re: CVE-2014-6271: Remote code execution through bash
#176Earlier quoted context omitted.
Also don't use bash for running any scripts. You never should anyway, in a sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash which is not vulnerable. Unfortunately the Redhat derived distros do use bash as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash is for users not scripts.
Anyone able to express how this affects the default client configuration on Mac desktops and servers?
I guess I'll answer one part- so if you run this: $ env x='() { :;}; echo vulnerable' bash -c "echo test" in your terminal, you certainly appear to be vulnerable.
But I'm not knowledgable about all the default scripts that launch things on the mac. It's unclear to me if there are any standard processes on OSX that take advantage of Bash
Re: CVE-2014-6271: Remote code execution through bash
#177Earlier quoted context omitted.
Most code executions vulnerabilities aren't remotely accessible, which this is, which makes priv-escalation particularly nasty. (eg: incorrectly assuming that since www-data user doesn't have access to anything sensitive, this bug isn't a big deal)
Is it remotely accessible on systems where sh is dash, though? That's specifically what was under discussion.
Yes, potentially - if at any point during the execution of a program (or its descendents) a bash script gets called with an untrusted environment variable value from a remote source. The difference between a system with bash as /bin/sh and a system with dash as /bin/sh is that the bash system is implicitly executing bash all the time, whereas the dash system requires an explicitly-bash script to be executed. So the dash system has many fewer windows of opportunity for an exploit, but they could still be there.
Re: CVE-2014-6271: Remote code execution through bash
#178Earlier quoted context omitted.
I have a Debian Squeeze system. Just ran apt-get upgrade and bash wasn't upgraded at all. Just other things like CUPS, exim4, pgsql, ...
Make sure security.debian.org is in your apt sources list?
Thanks for the hint folks. My eyes glazed over when OSS people started using packages some 20 odd years ago.
My brain refuses to understand anything more than the beautiful simplicity of a tarball extracted from the / directory. :)
Re: CVE-2014-6271: Remote code execution through bash
#179Free BashBleed logo for tech journalists - http://i.imgur.com/ilJbM74.png
Re: CVE-2014-6271: Remote code execution through bash
#180Earlier quoted context omitted.
None of this seems crazy unlikely, but I'd still like to hear a confirmation that that's what was meant. Especially since korzun was talking specifically about Debian and Ubuntu where bash is only used as a login shell and so presumably those with access could already just run the app.
There are unfortunately lots of bad scripts in the world that start with: #!/bin/bash So for example, with a foo.sh script of: #!/bin/bash echo "loser!" Then for example: vagrant@ubuntu-14:~/bin$ X='() { :; }; echo foo' python Python 2.7.6 (default, Mar 22 2014, 22:59:56) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.system("./foo.sh") foo loser! 0 >…
'More importantly though, it literally does not matter if this bug is "directly privilege escalating" or "1 step removed privilege escalating", the are fundamentally the same thing. It doesn't matter in any case where a script is executed with bash instead of dash.'
It doesn't matter for security. It matters a lot for my understanding of what's going on.