51–60 of 432 posts
Am I wrong in thinking that seems a bit worse than Heartbleed?
But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing.
Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge.
But as it is... I'm not sure?
Earlier quoted context omitted.
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.
> Most webservers put certain HTTP headers in environment variables. I legitimately don't understand why they might do such a thing. Can you explain?
Earlier quoted context omitted.
Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-securit...
Debian7 doesn't look to be vulnerable by default (if the code snippet can be trusted to work): [arch/testbed ~] uname -a Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux [arch/testbed ~] env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
For more info: http://www.csoonline.com/article/2687265/application-securit... This should be fun
CGI has always been an accident waiting to happen, but hardly anybody uses it anymore anyway, and even more rarely in a manner that invokes bash, of all things. I fail to see how "HTTP requests" generically are a vector, and its "Here is a sample" statement is not a link and is followed by... nothing. This article tells me nothing useful other than "don't allow untrusted data into your environment", which we've all k…
Yes, we've all known that. But we're slowly discovering all different ways the untrusted data can get there.
Earlier quoted context omitted.
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.
> Most webservers put certain HTTP headers in environment variables. I legitimately don't understand why they might do such a thing. Can you explain?
Earlier quoted context omitted.
> Most webservers put certain HTTP headers in environment variables. I legitimately don't understand why they might do such a thing. Can you explain?
They need to pass data into a CGI script somehow.
Not to say nobody will be bitten by that, but I don't think that's going to be all that widespread.
Earlier quoted context omitted.
Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-securit...
Debian7 doesn't look to be vulnerable by default (if the code snippet can be trusted to work): [arch/testbed ~] uname -a Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux [arch/testbed ~] env x='() { :;}; echo vulnerable' bash -c "echo this is a test" bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' this is a test
so 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.
Why, other than it is not the shell of the day?
foom:~ steve$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test