321–330 of 432 posts
If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.
It doesn't have a nice catchy name and a logo, though
Earlier quoted context omitted.
IIUC, you're already pwned after the first line of your wrapper script, i.e. #!/bin/bash, as your CGI environment was already set before, and now you're running bash in it (unless FastCGI works differently, not by setting the environment as plain old CGI; I don't know FastCGI, but from a quick glance I think it works similarly)
FastCGI does work differently – it spawns a process which stays open and communicates with it over stdin / stdout – but that doesn't mean that his PHP script doesn't unexpectedly invoke system() somewhere.
So considering there are other variables in there that can be manipulated it would be possible to own a large chunk of servers on the Internet. However I'm not sure if there is caveat and I had hoped that someone can help me.
Edit: Looks safe. These variables are not even there. It's just an outdated script.
Earlier quoted context omitted.
I don't know if Ubuntu has pushed a patched version of bash, but bash is what you should update. Someone already posted a way to test whether your version is vulnerable. You might also look into changing the default shell (but beware, scripts with bashisms in them...).
Ubuntu pushed the update around noon 4.3-7ubuntu1.1
Earlier quoted context omitted.
DigitalOcean uses mirrors too, so you have to change your /etc/apt/sources.list file or wait.
I updated debian on DO like 25 minutes ago and had a crystal-clear bash update there. So I guess they updated their mirrors.
Earlier quoted context omitted.
Because this allows execution of arbitrary commands from any unsantized environment variable. Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string. GET / HTTP/1.0 User-Agent: () { :; }; rm -rf / Restricted SSH accounts (like the ones used by GitHu…
I'm a relative newcomer to the command line and have been Googling around for what exactly the () {:;} is doing with no luck. Does anyone have a good link or explanation?
Earlier quoted context omitted.
It doesn't have a nice catchy name and a logo, though
Fine. Now it's called BashSmash. Are you happy? Go make a logo.
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 an innocent sub process in 4.3.25(1)-release
2. Create an innocent sub process. Bash in this case. During initialization...
3. ...bash spots the specially formed variable (named badvar), prints a warning,
4. ...and apparently doesn't define the function at all?
5. But other than that, the child bash runs as expected.
And now the same two input lines on and OLD bash:
1. hobbes@metal:~$ export badvar='() { :;}; echo vulnerable'
2. hobbes@metal:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'"
3. vulnerable
4. I am an innocent sub process in 4.3.22(1)-release
2. Create an innocent sub process. Bash in this case. During initialization...
3. ...bash accidentally EXECUTES a snippet that was inside the variable named 'badvar'?!
4. But other than that, the child bash runs as expected. Wow, I should update that machine. :)
Earlier quoted context omitted.
If you just want to upgrade bash, and prevent services like nginx, fpm, and apache from being restarted in production, you can run `sudo apt-get update && sudo apt-get install --only-upgrade bash` 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?
> 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…
[citation needed] because that doesn't sound possible.
Here's how to patch Ubuntu 8.04 or anything where you have to build bash from source: #assume that your sources are in /src cd /src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 0 25);do patch -p0 Not sure if Ubun…
8.04 is unsupported, and situations like this justify the effort of upgrading it to the latest LTS.
Earlier quoted context omitted.
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.
And in some cases invoking the shell and letting it do its thing is expected, intended and desirable.
Defense must use different strategies than offense. An engineer's goal should be to reduce the problem space to something as small as possible, so he has a better chance at implementing a correct solution. Allowing the shell to be invoked is a good way to explode your exploitable surface area.
Anybody who coded in the 1990s knows to stay away from the shell like the plague, even though the syntax parsing and evaluation components in modern shells have improved considerably. Sadly this particular bug harks back to the bad days, when it was more difficult to tell how certain constructs would be evaluated.
It's not that you can't theoretically do it securely, it's just that you're gratuitously playing with fire--fire that has burned countless engineers in the past. The cost+benefit is so indisputably skewed toward little cost and huge risk that it's unprofessional to suggest otherwise.
The shell shouldn't come anywhere near network-facing software, period.