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 known for 20 years.
Yeah this is true - a lot of hosting providers run PHP as a CGI as it allows them to run the PHP process under the user account (although it is very slow, and RUID2 is a better solution).
If you're not running mod_cgi can this affect the system in any way?
They would be too slow to be useful at any kind of real load. Are you sure you're not thinking of FastCGI? That doesn't pass data through the environment, it goes over a socket.
Unless you're using CGI, your system environment will not be contaminated. CGI is vulnerable because it relies on passing untrusted data in environment variables. No other gateway interface I'm familiar with does.
Are you certain that no method of invoking a dynamic script sets environment variables to values controlled by requests? If so, it sounds like even an innocent call to system("lame a.wav b.mp3") could lead to code execution.
Edit: also, you may be surprised to find that some "libraries" are actually wrappers around external binaries (e.g. libgpgme). If any of them used a system() or exec() call that preserves environment, and the binary or the library ever invokes bash (e.g. via system()), then trouble will ensue.
If you're using the nginx module, it gets the data from an instance of ngx_http_request_t. From there it gets passed around over sockets. Environment variables are not involved.
Using environment variables for request data would be quite insane when one of your marketing strategies is "fast" -- you'd either have to fork-per-connection just like CGI, or pre-fork processes that take input over a socket, deliberately deserialize it into the environment(!), and use getenv.
However overhyped Passenger might be, I don't know why you'd think the Phusion guys are that crazy.
Discovering that CUPS and dhclient may be vulnerable doesn't change anything. I'm talking about HTTP as an attack vector.
Almost all vendor-supplied web interfaces that don't come bundled with a web server are CGI so you can just run it from whatever web server you have. Even some very popular 'appliances' out there that have their own web server run CGI.
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.
It can potentially be exploited via anything that shells out to bash with an environment that contains environment variables with values (that ultimately comes from) an untrusted source.
mod_cgi is just one of the most obvious attack vectors.
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.
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.
/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"
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
> In the BSDs it is a standards compliant posix sh too.
In FreeBSD, it is tcsh in sh mode. Bash does the same too when invoked as sh[0]. It's POSIX compliant with extensions. There's still all the shell's code there, it's just that some of it is switched off by default, or its behaviour modified, to be compliant.
By the time AcceptEnv has any effect, the user is already logged in and can run whatever they want anyway. If you're allowing untrusted users to authenticate to ssh, then, yeah, sure, but you'd be in a niche (and know it).
Its been a bad time for FOSS/Linux systems. Heartbleed, the occasional priv escalation, apt-get, bash, etc. Or whatever the hell happened at TrueCrypt. Or the recent AOSP browser bug in Android that probably won't be patched by any OEM/Carrier. These are all pretty serious issues. Not to mention the endless wave of malware targeting Windows systems, especially the evil cryptolocker ransomware.
I really do think heartbleed was a wake-up call for some people and a lot of extra auditing is being done, perhaps with some healthy paranoia fueled by the recent NSA allegations. Software, in general, imo, is pretty insecure. The exploits, bugs, etc are out there and if you'll find them if you look hard enough. Considering software is always being updated, that also means news bugs and security issues.
As a sysadmin, I've just seen too often how the sausage is made. I have zero illusions about security. There are just too many avenues to compromise, be it via software or via plain-jane social engineering. I think one day in the future we (or our children) are going to look back at the age of viruses and buffer overflows and wonder how the hell we managed to get by, the same way I look at cars from the 50s-60s that suffered from things like vapor lock, were incredibly unsafe, and other issues that really don't exist today.
you're just paying attention. There have been some interesting ones the last year or two but this is really a trickle compared to early through mid 2000s
people started to pay attention. theres a bunch of new vulns being patched daily. if you follow cve's or oss list you can see that.
what's "new" (been done for a few years now) is that there's more marketing drive behind them. Fancy commercial names and websites dedicated and issues are often exaggerated.
Actually super critical vulns are still rare (like HB, codered, etc.)
Yeah, I was current yesterday and I'm current today, with both apt-get update and upgrades. Your version number is lower than mine, you must be on either stable or testing.
ii bash 4.3-9 i386 GNU Bourne Again SHell
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
From the FAQ:
> Does sid have security updates?
Not in the same sense that stable does. If the maintainer of a package fixes a security bug and uploads the package, it'll go into sid by the normal means. If the maintainer doesn't do that, then it won't. The security team only covers stable (and possibly testing... there's a pending issue for that case).
I've got a Debian VM I maintain for giggles, and just out of masochism I've been running "apt-get update" and "apt-get upgrade" for a while and watching nothing change.. Am I doing something wrong or is the whole process just slow?
deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free
I know you're just teasing, but I've got a machine with an arch install from over two years ago that's still running great. Just did an -Syyu to get bash updated.
So I took a great unix/linux systems programming class, http://sites.fas.harvard.edu/~lib215/ where you learn about all of the system software that you take for granted. Among other things, we had to write our own shell. There is an awful lot to consider, and most of it you are just trying to get to work properly. With regard to security, you feel like you are protected for the most part because the shell resides in userland and it's basically understood that you shouldn't trust foreign shell scripts.
Is the worry here that the code gets executed by the kernel or superuser, enabling privilege escalation? Otherwise it wouldn't be a big deal that extra code is executed by a function declaration.
Have you ever looked at the backend web interface of some of the most popular residential wifi routers? It's shell script. Why? It's a cheap and accessible interpreted language; no need to clutter up your tiny embedded OS with the huge requirements of php, perl, etc when you have all the tools you need in busybox.
CGI apps execute shell scripts all the time. Even if an app executes an app executes an app executes an app, if that app four layers down runs a shell script, the environment is still passed down. Turtles, dude.
It could be a simple one-line script that wraps the real command, setting memory limits and the like first. (I used a similar trick to prevent Skype using up all my memory in the past.)
It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by default, since /bin/sh is implicitly invoked all over the place (e.g. by system(3)). Distros which use /bin/bash for /bin/sh are gonna have a bad time.
Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.
You're right and my comment was unclear. I'm just saying that the impact on Debian will be less than on distros using /bin/bash for /bin/sh. Of course, even a lessened impact can still be really bad!
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
Last dist-upgrade was about a week ago, all indications point towards the bash released back in Jan 2013. It's fixed in 4.2+dfsg-0.1+deb7u1 and I'm running 4.2+dfsg-0.1
Well, that's very odd because that command reports vulnerable on an unpatched Debian system, but fails with exactly that error message on a patched system.
Squeeze doesn't have regular security support anymore. A subset of packages on i386 and amd64 are receiving long term security support, but you need to enable the Squeeze LTS repo:
That's true of any code execution vulnerability, though - it seems odd to call out the privilege elevation specifically. If that's all the GP meant, then sure, I fully grok.
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 premise of "there's no such thing as a secure computer", that the exact details are a hand-wave. This comes from the repeated demonstration that it's almost always true.
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.
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.
'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.
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)
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.
Well, sure. It seems a slightly odd way to phrase it if that's the entirety of what korzun meant, though. Is there somewhere that happens in a typical out-of-the-box Debian or Ubuntu box?
I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it.
If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your arguments. Cut out the middle man and pass the arguments directly. It will save you a lot of stupid bugs.
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.
Would you execute random Perl or Python code from the internet? No, you wouldn't, even if you tried to sanitize it a thousand ways from Sunday. So why would you do so for the shell?
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.
> are not drop-in replacements since they don't take care of forking, changing the signals, and waiting.
I never claimed it as a drop-in replacement. I think you know the solution to these problems. (I guess maybe someone who naively uses system() might not, so perhaps I need to work on a better spiel.)
> As long as you're not passing arguments from outside sources to the command, using system() should be OK.
Personally I've seen too many bad uses of system() to make that a thing. Maybe they'll not realize it's subject to PATH and that PATH can be untrusted. Maybe they'll not realize they sometimes have asterisks and spaces in a filename. And so forth...
> the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting.
Maybe not in C, but they are a drop-in replacement in just about every scripting language. Perl, Ruby, Python, all have nice high level calls that mostly mimic system() but use execve underneath—You simply pass system() multiple arguments instead of a single string. `system("")` in your production web app server code is almost certainly incorrect.
Sadly I think PHP still doesn't have this.
> As long as you're not passing arguments from outside sources to the command, using system() should be OK.
Very true, but think about whether you really need a shell to launch your command (are you using any shell features?). If not, why not just launch the command directly?
There's nothing wrong with using system anywhere you would happily cover your eyes and paste the string content into a shell. That shouldn't be many places, if anywhere, in production software. It's fine for simple things that would've been shell scripts anyway but for the need to XYZ.
/bin/sh depends on the system. It might be busybox or a minimal shell (this is common on embedded devices). On some systems like OSX and I think CentOS /bin/sh is just bash. You can check with `/bin/sh --version`.
Looks like it works. I guess it is okay that after the close quote the command still runs even though it is not terminated
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
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.
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?
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...).
It appears that Linode changes /etc/apt/sources.list to point to their own mirror of Ubuntu repositories, and as far as I can tell those are not updated yet. So I guess the solution is to wait or edit sources.list. Just FYI if you're on their systems!
It probably ensures that you get the Linode-customized flavors of packages where such exist, so that, for example, you don't inadvertently upgrade your kernel to a build without the ability to mount Linode disks.
Linode can't modify packages; they're signed by the upstream distro. (Unless Linode added a key of their own to your apt keychain (apt-key list), but I've never seen that.)
For releases in-between, you should be able to manually download one of those versions from http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ and install it. I wonder how many vulnerable boxes there are that won't get these updates because Ubuntu stops support after 9 months. There must be tons of boxes running 13.10, it's not even a year old yet.
If I understood this bug correctly, it happens during bash's initialization. If I'm right, already running instances of bash are not vulnerable, and new instances will use the fixed executable, so no reboot would be necessary for this bug.
$ apt-cache show debian-goodies
<SNIP>
checkrestart - Help to find and restart processes which are using old
versions of upgraded files (such as libraries)
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.
Debian security updates are distributed from security.debian.org, which is separate from the normal Debian mirror network, and Debian discourages the mirroring of security.debian.org because security updates are time sensitive. Hopefully Digital Ocean is not mirroring security.debian.org.
Looks like the patched version and the pre-patched version show the same version, or am I being stupid and missing something ?
ayourtch@mcmini:~/bash-patch$ ls
bash_4.2-2ubuntu2.2_amd64.deb bash-builtins_4.2-2ubuntu2.2_amd64.deb t
ayourtch@mcmini:~/bash-patch$ dpkg -x bash_4.2-2ubuntu2.2_amd64.deb t
ayourtch@mcmini:~/bash-patch$ diff -c t/bin/bash /bin/bash
Binary files t/bin/bash and /bin/bash differ
ayourtch@mcmini:~/bash-patch$ t/bin/bash --version
GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ayourtch@mcmini:~/bash-patch$ /bin/bash --version
GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ayourtch@mcmini:~/bash-patch$ sha1sum t/bin/bash
9eeed02173db163b013933eff3b8c6aa3697f67f t/bin/bash
ayourtch@mcmini:~/bash-patch$ sha1sum /bin/bash
3384fadf84146a4d4b6b7f529f615e9947b4ac99 /bin/bash
ayourtch@mcmini:~/bash-patch$
you should update all security updates, reliably, periodically, regardless of HN posts.
you're probably not directly vulnerable for this very vuln, but then again, maybe you are. with enough vulns it gets complex enough to check that its easier to just update with all the security updates..
We just updated our scanner and included this CVE. You can run Detectify to see if your setup is vulnerable. We offer a recurring service that runs continuously and alerts you if you are exposed to new emerging vulnerabilities. This removes some of the complexity of always being on top of security alerts.
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 prior to the upgrade.
Upgrades should not require any restarts, and no restarts are required for you to stop being vulnerable - as this only affects newly created bash sessions, not already running ones.
Debian's package manager has the nasty habit of stopping affected daemons before all the upgrades and starting them afterwards, leaving you with serious downtime.
"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 this is. [1]
Perhaps you could clarify with some examples of why (see child comment "So, as a amateur sysadmin of a decently popular side project") you think this applies to anyone who is "responsible for the security of any system"?
[1] Me for one because I'm not seeing the "Drop everything" priority for any of the systems that I have control over given the way they are configured. That said I'd like to hear more of course.
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 that you forgot you even ran, at which point they'll own your whole data center.
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?
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?
Usually no. This exploit should be vulnerable to any HTTP method. "unathenticed GETs" are the lowest security level of HTTP calls, so if they can be used as an attack vector, you should pay attention.
I ask because I've seen SSIDs with meaningful characters ()<>;? cause trouble with some network managers. I presumed at the time that this was due to the SSID string being passed as an argument to some script.
I've encountered this on my old Android phone and my old Debian laptop. I encountered it often because a friend of mine used to have an emoticon in the SSID for his home router. (Really annoying! I couldn't connect to anything when his router was in range.)
Note: it could very well have been a different problem. I didn't investigate.
Unauthenticated GET requests were just an example of something that can invoke this behavior. If you have any network-enabled service that's capable of spawning a shell, you can have attack vectors open.
Possible vectors include things like DHCP clients, SSH, web servers, etc. Lots of things open shells for reasons you wouldn't intuitively expect. It's very likely that there are many creative vectors for exploitation that will be discovered in the coming hours.
The attack surface of this bug may very well be the largest attack surface of any bug in history. Update bash. Just update bash. Everywhere. On everything you have it on. Don't think about whether, just think about how.
(Note I'm not claiming this is the "worst bug ever"... there's stiff competition for that claim. But most of the rest of the "worst bug ever"s I can think of are some point that failed, some particular thing you could do for full root access or something. I can't think of anything else with this sheer staggering surface area.)
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 GitHub) have a setting to restrict the user to a specific command (e.g. /usr/local/bin/run-git-only --github-user=octocat). The original command is passed in an environment variable SSH_ORIGINAL_COMMAND. If bash is used anywhere along the way (say, if /usr/local/bin/run-git-only --github-user=octocat is a shell script), then this is a problem:
ssh git@example.com '() { :; }; rm -rf /'
There are surely lots of other ways to get servers to run bash shells with arbitrary environment variables. That's why this is bad.
Edit: as others have pointed out, even non-bash CGI scripts that use a shell to run external processes are vulnerable For example, system("/usr/local/bin/whatever --some-fixed-option") would normally be considered safe since there's no untrusted data in the command-line (although perhaps it would be considered poor design), but it'll run a shell to do the whitespace splitting. If that shell is bash....
If bash is invoked at any point in the response cycle you are pwned; not just if you are directly exposing a shell script. How confident are you that this never happens on any computers anywhere on your network ever?
That's ridiculous. You may as well say that every time you put a python script up, you're exposing the entire Python runtime and deserve to get 'pwned'.
The scope of the risk is limited to script that you write, whether bash or Python.
To be fair, with all the various ways how shell scripts (not only in bash) interpolate, evaluate, substitute etc., the typical shell language is much, much harder to keep safe against code injection than say Python (or even PHP). After all, code injection/evaluation is actually what you want in a shell script, half of the time.
At least SCRIPT_FILENAME is user input isn't it? I'm really not sure but like to have some clarity. It should not work because it's likely impossible to have () at the beginning of the SCRIPT_FILENAME? but can someone give some hints? It's common to have bash/sh wrapper script: https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#exampl...
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.
This script here is run when the process is spawned and spawns the PHP process that listens to stdin/stdout. Similar scripts exist in most install of mod_fcgid. E.g. PLESK, Virtualmin, other ISP-Panels... It boils down to look at what environment variables are there when bash runs this script or not? Once bash starts and grabs the environment variables the exploit starts.
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.
There is a reason PHP is to be kept away and not touched with a ten meter stick, it seems to spawn a shell for weird reasons, I dont think python or groovy apps do that. They're safe, unless you somewhere specifically invoke System.getRuntime().run("bash");
PHP never "spawns shell for weird reasons" - it would spawn shell if you ask it to spawn shell. Just as any other language would, if you ask it. Still, many apps may use shell indirectly - e.g. to execute some system function, to call out to some tool, etc. - and those may be vulnerable even if original code was not CGI script. Moreover, you don't have to run specifically bash - any command execution may go through shell, which may be bash, e.g. Runtime.getRuntime().exec() in Java. Thus it may be not very easy to pinpoint all the places where this bug could sneak in.
> groovy apps do that [... if] you somewhere specifically invoke System.getRuntime().run("bash");
That's a one-liner in Groovy, written in the Java style of chained method calls, which is the direct equivalent of spawning a shell in non-JVM languages, so that's not an argument for using Groovy instead of PHP.
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?
Another attack surface is OpenSSH through the use of AcceptEnv variables. As well through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.
On most systems I've found this works:
LC_TIME='() { :;}; echo vulnerable' ssh <hostname>
Not sure of the impact of this, as the user would need to have a remote permissions anyway for the SSH login to occur. But if there was some form of restricted shell that then spawned bash it might potentially create an attack vector.
I was wondering about this too. My thinking was, if a user's laptop is compromised (and has the exploit in LC_TIME, TERM or similar), and the user then SSH in to a server with exploitable bash, the nefarious command will presumably be executed without the user knowing. But of course, if the laptop is compromised that badly, it could probably wreak havoc to the server anyway.
It is far worse in the sense that it can lead to remote code execution. However, the number of vulnerable sites is far far fewer. Like Heartblead this one will likely have a very long tail of systems remaining vulnerable. My guess is we will see this vulnerability used to compromise big targets in the next few months.
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.
You could search for *.cgi scripts indexed by Google. They may not be written IN Bash but maybe one of them opens up a shell to execute a command. Even if you are not explicitly passing any bad data to it, the environment will be passed and trigger this crazy vulnerability.
Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are not what we're looking for, mostly forum posts asking about how to make a bash cgi-bin. (Answer from the future: don't).
I _think_ putting quotes around the ".sh" is supported to force the result to really have the period before the sh in the url.
I have a feeling this is blown out of proportion.
Who's running bash setuid exactly? Right.
Who's running shell CGIs today? Right.
So.. who has an example of common scripts that are executed remotely in most servers while accepting remote environment? Til then, the panic seems unjustified...
Google brings up 410 .bash CGIs. Every one of them is almost guaranteed to be vulnerable at this point. Of the 1.2 million .sh CGIs, some are surely vulnerable. By this time, many of them are already be in the process of being owned.
CGIs are likely the smallest piece of the vulnerable hosts here. This is going to stick around as a local vulnerability on the plentiful supply of under-patched Linux boxes for a long time.
thats a really small number of servers actually.. i mean ppl get owned every day, every minute.
theres a bunch of more easily exploitable local bugs that actually elevate your privileges.
this one bug DOES NOT elevate privs. you need a service that passes unsanitized env vars (unchecked user input) to bash with another user id than yours.
As I understand this, any CGI script could be affected. Even if written in a different language if it turn does an os.system (or equivalent). More info here:
https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
The permissions would only be as the web server user, but that allows all sorts of things to be run that are quite dangerous (resource exhaustion, attacking remote machines, downloading code and running it)
You would still need to be able to pass arbitrary data to the bash command, and if your php (or whatever) script does that, you have a lot of other potential problems to worry about.
Because of the way cgi works you could just set a user agent or other http header to contain an 'rm' or'nc' command or something in to download and run an attack tool. E.g. You could run netcat to listen on a port or connect out to an attacker's system to provide a connection into an otherwise firewalled database server
Yes, you're right. We have perl running on our server, and I just verified that it is vulnerable if any shell scripts are run from perl. However I just quickly switched on modperl, and I verified that it is now not affected. (According to Redhat, mod_perl and php are not affected, but it's good to verify).
Even if the malicious code doesn't have superuser context, it can do damage to whatever context it is running under. If it's running as www-data, it can trash all your www-data-owned files. Or send your www-data-owned password files somewhere, etc. Unprivileged code can also attack other systems (firewalls permitting); you don't have to be root on system A, to be part of a bot net which attacks system B. Denial-of-service havok can be wreaked from a regular user context, too. Not to mention privacy violations. Pretty much all browser-related security and privacy issues are user space!
As an example of who might be impacted, since openssh preserves the original command line passed to the ssh server when authenticating a public key that has a fixed command associated in authorized_keys, GitHub and BitBucket security teams are probably both having a really exciting day.
This vulnerability is the kind of reason I would have a stripped-down OpenSSH for public users, if I were them. Hard-code to do what they need, don't use configuration files, remove any features not needed. For example, to print the "You've successfully authenticated, but GitHub does not provide shell access." a user gets trying to ssh to github.com, don't invoke anything, print it directly from the SSH server.
Maybe. Actually, it looks like Github is using libssh, which is along the lines of what I was thinking, without having to mess with crypto too much, as you say.
It does. I installed an up-to-date version with homebrew a few months ago, and it was vulnerable as well. After a `brew update && brew upgrade bash` I had the fix installed, though :)
My OSX was vulnerable too, but I use Homebrew, and the latest version of bash available via brew update && brew upgrade is patched against this.
If you haven't already been using Homebrew though, you will likely need to move /usr/local/bin infront of /usr/bin in your path, otherwise the old bash would still be used.
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
but failed to spot that the second command invokes bash not zsh.
My tests suggest that neither zsh 4.3.17 or 5.0.6 (the versions that ship with Debian stable & testing respectively) are vulnerable to this exploit - if you replace bash with zsh in the test oneliner then the code after the end of the function definition in the environment variable is not executed.
No, it's not printed in your trivial example, but if you replace the simple "echo" command with any bash script, or any executable that calls a bash script, or any executable that invokes another program that calls a bash script, or ... then you're screwed.
Even with the "zsh", this should print "vulnerable":
You don't have to use bash explicitly. It might be called by some application or library. For example, if your default shell is a bash, this will work too:
Right, the point being that bash is vulnerable, not zsh (as was suggested by the post I was replying to). I'm not claiming that using zsh as your interactive shell somehow makes you immune.
Passing executable code in environment variables is an incredibly bad idea.
The parsing bug is a red herring; there are probably ways to exploit the feature even when it doesn't have the bug.
The parsing bug means that the mere act of defining the function in the child bash will execute the attacker's code stored in the environment variable.
But if this problem is closed, the issue remains that the attacker controls the environment variable; the malicious code can be put inside the function body. Even though it will not then be executed at definition time, perhaps some child or grand-child bash can be nevertheless goaded into calling the malicious function.
Basically this is a misfeature that must be rooted out, pardon the pun.
At a glance, one interesting use of this is a potential local privilege escalation on systems with a sudoers file which restrict commands which can be run to ones that include a bash script, and allow you to keep some environment variables.
This is what happens when you have two different processes doing IPC using a human interface mechanism.
Another huge family of vulnerabilities that exists for the same reason are SQL injection vulnerabilities. SQL was invented as a way for humans at a terminal to do database operations. However, we started using it as a way of doing IPC. The problem with using human interfaces as an IPC mechanism is that human interfaces are rarely well-defined or minimal, so it is very hard to constrain behavior to what you expect.
The way to fix all of these bugs is to use well-defined, computer-oriented IPC mechanisms where there is a clear distinction between code and data. For example, database queries might be constructed by function call instead of string manipulation, which could pack them into a safe TLV format with no chance of malicious query injection. Generating web server content from a different language could be done via a proper FFI or message passing mechanism, rather than CGI scripts.
No, all sorts of other network-facing systems can be vulnerable. Anything that ends up shelling out might pass some environment variables causing the problem. These things pop up in surprising places.
431 comments
[ 3.4 ms ] story [ 326 ms ] threadThis should be fun
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 known for 20 years.
Lots of PHP setups do.
PHP was one of the first to have a dedicated apache module. Perl is much more likely to be CGI.
If you're not running mod_cgi can this affect the system in any way?
Thanks!
Edit: also, you may be surprised to find that some "libraries" are actually wrappers around external binaries (e.g. libgpgme). If any of them used a system() or exec() call that preserves environment, and the binary or the library ever invokes bash (e.g. via system()), then trouble will ensue.
This is far from the first environment variable attack to impact CGI scripts, and CGI's successors have avoided passing data in environment variables.
It's possible some moron decided to create their own CGI replacement using environment variables, but it's not going to be in widespread use.
Edit: also note that CUPS is vulnerable according to https://access.redhat.com/articles/1200223
Also dhclient (!)
Using environment variables for request data would be quite insane when one of your marketing strategies is "fast" -- you'd either have to fork-per-connection just like CGI, or pre-fork processes that take input over a socket, deliberately deserialize it into the environment(!), and use getenv.
However overhyped Passenger might be, I don't know why you'd think the Phusion guys are that crazy.
Discovering that CUPS and dhclient may be vulnerable doesn't change anything. I'm talking about HTTP as an attack vector.
Yes, we've all known that. But we're slowly discovering all different ways the untrusted data can get there.
Edit: oh looks like only like mod_cgi related stuff is.. thats good then sort of
mod_cgi is just one of the most obvious attack vectors.
Why, other than it is not the shell of the day?
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.
And don't shell out in eg. Perl, or PHP, or Python, through bash.
Or just take a patched bash.
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
In FreeBSD, it is tcsh in sh mode. Bash does the same too when invoked as sh[0]. It's POSIX compliant with extensions. There's still all the shell's code there, it's just that some of it is switched off by default, or its behaviour modified, to be compliant.
[0] http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX...
I really do think heartbleed was a wake-up call for some people and a lot of extra auditing is being done, perhaps with some healthy paranoia fueled by the recent NSA allegations. Software, in general, imo, is pretty insecure. The exploits, bugs, etc are out there and if you'll find them if you look hard enough. Considering software is always being updated, that also means news bugs and security issues.
As a sysadmin, I've just seen too often how the sausage is made. I have zero illusions about security. There are just too many avenues to compromise, be it via software or via plain-jane social engineering. I think one day in the future we (or our children) are going to look back at the age of viruses and buffer overflows and wonder how the hell we managed to get by, the same way I look at cars from the 50s-60s that suffered from things like vapor lock, were incredibly unsafe, and other issues that really don't exist today.
Its not like each year is an increase.. but it seems this year has had more major giant remote ones then in the past
what's "new" (been done for a few years now) is that there's more marketing drive behind them. Fancy commercial names and websites dedicated and issues are often exaggerated.
Actually super critical vulns are still rare (like HB, codered, etc.)
From https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
curl -H 'User-Agent: () { :;}; echo; echo vulnerable to CVE-2014-6271' <shell script CGI URL>
Tested and working against a shell script CGI.
Arch was fast.
[0] https://wiki.archlinux.org/index.php/Dash
Edited: Seems like jvreeland has a clearer picture: https://news.ycombinator.com/item?id=8362309
ii bash 4.3-9 i386 GNU Bourne Again SHell
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable this is a test
From the FAQ:
> Does sid have security updates?
Not in the same sense that stable does. If the maintainer of a package fixes a security bug and uploads the package, it'll go into sid by the normal means. If the maintainer doesn't do that, then it won't. The security team only covers stable (and possibly testing... there's a pending issue for that case).
Edit: I see that even those who got the patch are in fact still vulnerable.
squeeze. jessie and wheezy are still vulnerable.
https://security-tracker.debian.org/tracker/CVE-2014-6271
It's been uploaded to squeeze-lts but has not reached the mirrors.
You can get it manually from http://incoming.debian.org/debian-buildd/pool/main/b/bash/ if you can't wait.
If you have that line remove it or change it to squeeze-lts
https://www.archlinux.org/mirrors/status/
Still vulnerable.
env X='() { (lol)=>\' bash -c "echo id"; cat echo
Is the worry here that the code gets executed by the kernel or superuser, enabling privilege escalation? Otherwise it wouldn't be a big deal that extra code is executed by a function declaration.
Most webservers put certain HTTP headers in environment variables. I can certainly see the how this could be exploited.
I legitimately don't understand why they might do such a thing. Can you explain?
Not to say nobody will be bitten by that, but I don't think that's going to be all that widespread.
CGI apps execute shell scripts all the time. Even if an app executes an app executes an app executes an app, if that app four layers down runs a shell script, the environment is still passed down. Turtles, dude.
/edit: the Red Hat blog has a good overview https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.
[0] http://www.csoonline.com/article/2687265/application-securit...
My brain refuses to understand anything more than the beautiful simplicity of a tarball extracted from the / directory. :)
https://wiki.debian.org/LTS/Using
Still waiting on the i386 .deb for sid.
Your link and this link (https://security-tracker.debian.org/tracker/CVE-2014-6271) useful when considered together.
Aaaand now I'm done checking back on this thread. Have fun, folks! :)
I don't think anybody is worried about software on the system that is using /bin/bash .vs /bin/sh.
Edited to add: Also no differences in capabilities when I cat /proc/self/status
None of which is to say there is clearly no such vulnerability - I'd just like to understand it if there is.
Basically it goes "why would anyone not follow the execution -> escalation -> own path?" It's such an automatic assumption, combined with the basic premise of "there's no such thing as a secure computer", that the exact details are a hand-wave. This comes from the repeated demonstration that it's almost always true.
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.
It doesn't matter for security. It matters a lot for my understanding of what's going on.
I know systems where bash has been patched to allow execution by certain users, etc.
With this, you can inject commands before such check takes place.
Etc.
If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your arguments. Cut out the middle man and pass the arguments directly. It will save you a lot of stupid bugs.
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.
I never claimed it as a drop-in replacement. I think you know the solution to these problems. (I guess maybe someone who naively uses system() might not, so perhaps I need to work on a better spiel.)
> As long as you're not passing arguments from outside sources to the command, using system() should be OK.
Personally I've seen too many bad uses of system() to make that a thing. Maybe they'll not realize it's subject to PATH and that PATH can be untrusted. Maybe they'll not realize they sometimes have asterisks and spaces in a filename. And so forth...
Maybe not in C, but they are a drop-in replacement in just about every scripting language. Perl, Ruby, Python, all have nice high level calls that mostly mimic system() but use execve underneath—You simply pass system() multiple arguments instead of a single string. `system("")` in your production web app server code is almost certainly incorrect.
Sadly I think PHP still doesn't have this.
> As long as you're not passing arguments from outside sources to the command, using system() should be OK.
Very true, but think about whether you really need a shell to launch your command (are you using any shell features?). If not, why not just launch the command directly?
Verify your shasums before trusting a command line off the internet but:
rpm -Uvh http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/... http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/...
https://www.freebsd.org/doc/handbook/shells.html
https://security-tracker.debian.org/tracker/CVE-2014-6271
You might also look into changing the default shell (but beware, scripts with bashisms in them...).
4.3-7ubuntu1.1
Yes. Patch is out.
I guess apt-get from one of Linode's mirrors saves bandwidth? Or is it just more polite?
Ubuntu 14.04 LTS: bash 4.3-7ubuntu1.1
Ubuntu 12.04 LTS: bash 4.2-2ubuntu2.2
Ubuntu 10.04 LTS: bash 4.1-2ubuntu3.1
For releases in-between, you should be able to manually download one of those versions from http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ and install it. I wonder how many vulnerable boxes there are that won't get these updates because Ubuntu stops support after 9 months. There must be tons of boxes running 13.10, it's not even a year old yet.
----------------------------------------------------------
amd64
wget archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.3_amd64.deb
sudo dpkg -i bash_4.2-2ubuntu2.3_amd64.deb
----------------------------------------------------------
i386
wget archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.3_i386.deb
sudo dpkg -i bash_4.2-2ubuntu2.3_i386.deb
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.
edit: and how do I know if I am still vulnerable?
edit2: ok, this is the test
and apparently I am already patched. So that's good.WIll tell you which version of bash is installed, for precise you should have bash 4.2-2ubuntu2.2
http://hastebin.com/oraheyipug.hs
you're probably not directly vulnerable for this very vuln, but then again, maybe you are. with enough vulns it gets complex enough to check that its easier to just update with all the security updates..
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 prior to the upgrade.
[citation needed] because that doesn't sound possible.
I just tested this on Ubuntu 14.04 - it's vulnerable.
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 this is. [1]
Perhaps you could clarify with some examples of why (see child comment "So, as a amateur sysadmin of a decently popular side project") you think this applies to anyone who is "responsible for the security of any system"?
[1] Me for one because I'm not seeing the "Drop everything" priority for any of the systems that I have control over given the way they are configured. That said I'd like to hear more of course.
Helpful?
"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?
You can learn by experience, or you can try to leach the wisdom of others.
Usually no. This exploit should be vulnerable to any HTTP method. "unathenticed GETs" are the lowest security level of HTTP calls, so if they can be used as an attack vector, you should pay attention.
I ask because I've seen SSIDs with meaningful characters ()<>;? cause trouble with some network managers. I presumed at the time that this was due to the SSID string being passed as an argument to some script.
I've encountered this on my old Android phone and my old Debian laptop. I encountered it often because a friend of mine used to have an emoticon in the SSID for his home router. (Really annoying! I couldn't connect to anything when his router was in range.)
Note: it could very well have been a different problem. I didn't investigate.
Unauthenticated GET requests were just an example of something that can invoke this behavior. If you have any network-enabled service that's capable of spawning a shell, you can have attack vectors open.
Possible vectors include things like DHCP clients, SSH, web servers, etc. Lots of things open shells for reasons you wouldn't intuitively expect. It's very likely that there are many creative vectors for exploitation that will be discovered in the coming hours.
(Note I'm not claiming this is the "worst bug ever"... there's stiff competition for that claim. But most of the rest of the "worst bug ever"s I can think of are some point that failed, some particular thing you could do for full root access or something. I can't think of anything else with this sheer staggering surface area.)
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.
Restricted SSH accounts (like the ones used by GitHub) have a setting to restrict the user to a specific command (e.g. /usr/local/bin/run-git-only --github-user=octocat). The original command is passed in an environment variable SSH_ORIGINAL_COMMAND. If bash is used anywhere along the way (say, if /usr/local/bin/run-git-only --github-user=octocat is a shell script), then this is a problem: There are surely lots of other ways to get servers to run bash shells with arbitrary environment variables. That's why this is bad.Edit: as others have pointed out, even non-bash CGI scripts that use a shell to run external processes are vulnerable For example, system("/usr/local/bin/whatever --some-fixed-option") would normally be considered safe since there's no untrusted data in the command-line (although perhaps it would be considered poor design), but it'll run a shell to do the whitespace splitting. If that shell is bash....
You're killin' me here. If you expose a shell script directly to the network, you're exposing a shell and deserve to be pwned.
The scope of the risk is limited to script that you write, whether bash or Python.
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.
There is a reason PHP is to be kept away and not touched with a ten meter stick, it seems to spawn a shell for weird reasons, I dont think python or groovy apps do that. They're safe, unless you somewhere specifically invoke System.getRuntime().run("bash");
That's a one-liner in Groovy, written in the Java style of chained method calls, which is the direct equivalent of spawning a shell in non-JVM languages, so that's not an argument for using Groovy instead of PHP.
That's nice. I like this song.
https://www.youtube.com/watch?v=2pWZRJd4z8o
Another attack surface is OpenSSH through the use of AcceptEnv variables. As well through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.
Not sure of the impact of this, as the user would need to have a remote permissions anyway for the SSH login to occur. But if there was some form of restricted shell that then spawned bash it might potentially create an attack vector.
http://seclists.org/oss-sec/2014/q3/650
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?
Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are not what we're looking for, mostly forum posts asking about how to make a bash cgi-bin. (Answer from the future: don't).
I _think_ putting quotes around the ".sh" is supported to force the result to really have the period before the sh in the url.
inurl:cgi-bin inurl:".sh"
0 hits
So.. who has an example of common scripts that are executed remotely in most servers while accepting remote environment? Til then, the panic seems unjustified...
https://gist.github.com/joernchen/a7c031b6b8df5d5d0b61
Of course that was fixed a long time ago, but I wonder what other systems are just a thin veneer over pretending the user controls a shell.
CGIs are likely the smallest piece of the vulnerable hosts here. This is going to stick around as a local vulnerability on the plentiful supply of under-patched Linux boxes for a long time.
this one bug DOES NOT elevate privs. you need a service that passes unsanitized env vars (unchecked user input) to bash with another user id than yours.
> PHP scripts executed with mod_php are not affected even if they spawn subshells.
https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
If you haven't already been using Homebrew though, you will likely need to move /usr/local/bin infront of /usr/bin in your path, otherwise the old bash would still be used.
My tests suggest that neither zsh 4.3.17 or 5.0.6 (the versions that ship with Debian stable & testing respectively) are vulnerable to this exploit - if you replace bash with zsh in the test oneliner then the code after the end of the function definition in the environment variable is not executed.
Even with the "zsh", this should print "vulnerable":
You don't have to use bash explicitly. It might be called by some application or library. For example, if your default shell is a bash, this will work too:The parsing bug is a red herring; there are probably ways to exploit the feature even when it doesn't have the bug.
The parsing bug means that the mere act of defining the function in the child bash will execute the attacker's code stored in the environment variable.
But if this problem is closed, the issue remains that the attacker controls the environment variable; the malicious code can be put inside the function body. Even though it will not then be executed at definition time, perhaps some child or grand-child bash can be nevertheless goaded into calling the malicious function.
Basically this is a misfeature that must be rooted out, pardon the pun.
Another huge family of vulnerabilities that exists for the same reason are SQL injection vulnerabilities. SQL was invented as a way for humans at a terminal to do database operations. However, we started using it as a way of doing IPC. The problem with using human interfaces as an IPC mechanism is that human interfaces are rarely well-defined or minimal, so it is very hard to constrain behavior to what you expect.
The way to fix all of these bugs is to use well-defined, computer-oriented IPC mechanisms where there is a clear distinction between code and data. For example, database queries might be constructed by function call instead of string manipulation, which could pack them into a safe TLV format with no chance of malicious query injection. Generating web server content from a different language could be done via a proper FFI or message passing mechanism, rather than CGI scripts.
Eg, if you allow ANY environment variables in SSH rsync-only logins, or pass on any variables (for good or bad) in sudo scripts, etc.