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.

4 of 318 comments (clear)

  1. Re:"could be worse than Heartbleed" by jpvlsmv · · Score: 5, Insightful
    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.

  2. Re:Worse than Heartbleed? by Anonymous Coward · · Score: 5, Insightful

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

  3. How to disable CGI in Apache by Animats · · 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
    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"

  4. Re:So flog the bash developer who checked this in. by Aristos+Mazer · · 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.