Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

331–340 of 432 posts

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

#331

Earlier quoted context omitted.

> Related to that, does anyone else know if upgrading bash will require a restart of other services kind of like upgrading openssl requires restarting things? I don't think it will, for a couple of reasons. OpenSSL is integrated into other services as a library, while bash would be called as an external application. I also noticed that once I upgraded bash, the proof of concept stopped working in a terminal I opened…

> I also noticed that once I upgraded bash, the proof of concept stopped working in a terminal I opened prior to the upgrade. [citation needed] because that doesn't sound possible.

Not if the issued commands spawned a new copy of Bash.

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

#332

Earlier quoted context omitted.

If you just want to update that package then: apt-get update apt-get install --only-upgrade bash fwiw, Linode's mirrors are up with the latest version yet Digital Ocean's are not. I lose faith in DO everytime I remote into my VM. They just seen like an amateurish shop.

My droplets in SFO have been updated. My droplets in nyc1 and nyc2 haven't.

And NY is updated for me as well now. Wondering why it took so long after the other DCs were updated.

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

#333
post #321

Earlier quoted context omitted.

Fine. Now it's called BashSmash. Are you happy? Go make a logo.

Someone already made on a few hours ago... https://i.imgur.com/ilJbM74.png

That's really ugly and not a real logo.

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

#336

Earlier quoted context omitted.

Doesn't OSX ship the 8-year-old bash 3.2 (2006) i.e. the last version available as GPLv2? (Apple hates GPLv3)

For me in 10.9.5: $ bash --version GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13) Copyright (C) 2007 Free Software Foundation, Inc.

[deleted]

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

#337

Earlier quoted context omitted.

> Related to that, does anyone else know if upgrading bash will require a restart of other services kind of like upgrading openssl requires restarting things? I don't think it will, for a couple of reasons. OpenSSL is integrated into other services as a library, while bash would be called as an external application. I also noticed that once I upgraded bash, the proof of concept stopped working in a terminal I opened…

> I also noticed that once I upgraded bash, the proof of concept stopped working in a terminal I opened prior to the upgrade. [citation needed] because that doesn't sound possible.

[deleted]

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

#338

There's some misunderstanding of how the one-liner works, so here's a writeup. You can break the one-liner into two lines to see what is happening. 1. hobbes@media:~$ export badvar='() { :;}; echo vulnerable' 2. hobbes@media:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'" 3. bash: warning: badvar: ignoring function definition attempt 4. bash: error importing function definition for `badvar' 5. I am…

I finally understand how it can be used.

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

#339

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…

FastCGI accepts name/value pairs from the server and most default language bindings against it will turn them into environment variables for the benefit of code that expects to be able to reference them. This can get tricky if you do anything that spawns a process with your code later.

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

#340

Earlier quoted context omitted.

First it encourages people to use bash specific stuff that is non Posix. Second it is a huge bloated bit of code thats ok as user interface, but scripts should use something that is more minimal. To avoid this sort of issue.

> scripts should use something that is more minimal. To avoid this sort of issue. Are you also against Perl and Python or does this scripts should be minimal only apply to bash? > First it encourages people to use bash specific stuff that is non Posix That's not a problem for most people. These are reasons you don't like bash, not reasons to not use bash.

/bin/sh is the shell called by system(3) and used by portable scripts bundled with packages. Those things can't use anything but standard sh anyway, so having them run bash is overkill. "Don't use bash as your /bin/sh" isn't the same as "don't use bash as your interactive shell" or "don't write bash scripts"
Post reply on HN