Slashdot Mirror
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.
Bugs used to just be bugs, now we give them names like virii and terrorist cells
quit with the sensationalism already we don't *NEED* everything to have a dramatic (and frankly stupid) name
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.
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.
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.
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
I'm here EdgeKeep Inc.
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.
AntiFA: An abbreviation for Anti First Amendment.
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.
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.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
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?
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.