Unix/Linux Bash: Critical security hole uncovered and it seems to be all around in the news. The claim is that popular Linux and Unix shell has a serious security problem that means real trouble for many web servers. Let’s check the facts fist, is this real from some reliable source. There is Vulnerability Summary for CVE-2014-6271 (and updates) so this is real:
“GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment.”
This means that the flaw involves how Bash evaluates environment variables. With specifically crafted variables, a hacker could use this hole to execute shell commands. The vulnerability arises from the fact that you can create environment variables with specially-crafted values before calling the bash shell. These variables can contain code, which gets executed as soon as the shell is invoked.
Does not look good. The repost says that there are vectors involving OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations.RedHat has an extended list of situations that involve Bash in a remote context.
The bash flaw seem to have gotten names. This CVE-2014-6271 is also known as “Shellshock” or Shell Shocked.
Remember Heartbleed? If you believe the hype today, Shellshock is in that league. The claims that Bash bug as big as Heartbleed seem to be some real justification for that:
The first reason is that the bug interacts with other software in unexpected ways. An enormous percentage of software interacts with the shell in some fashion.
This bash bug has been around for a long, long time. The vulnerability affects versions 1.14 through 4.3 of GNU Bash. That means there are lots of old devices on the network vulnerable to this bug. The number of systems needing to be patched, but which won’t be, is much larger than Heartbleed.
It’s things like CGI scripts that are vulnerable, deep within a website. Nobody knows how many of them are in use and where. For many Unix or Linux Web servers, it’s a major problem. The root of the problem is that Bash is frequently used as the system shell. Thus, if an application calls a Bash shell command via web HTTP or a Common-Gateway Interface (CGI) in a way that allows a user to insert data, the web server could be hacked. Is pretty ‘point and click’ simple to attack. Shellshock Bash Vulnerability Online Checkers Available.
This exploit is really nasty, because it doesn’t require a username or password to trigger it. The major attack vectors that have been identified in this case are HTTP requests and CGI scripts.
This is not only Linux problem. This problem could allow attackers to execute code on Linux, Unix, and Mac OS X.
Internet-of-things devices like video cameras and some SCADA/ICS devices are especially vulnerable because a lot of their software is built from web-enabled bash scripts.They are less likely to be patched. It’s embedded webserves on odd ports that are the real danger.
Bash ‘shellshock’ bug is wormable article says that this thing is clearly wormable, and can easily worm past firewalls and infect lots of systems. Bash bug fallout: Shell Shocked yet? You will be … when this becomes a worm article says that experts warn much carnage to come.
The race is on. Will you be able to patch before Metasploit has a working exploit? There are coders busy at work putting together a Metasploit module that demonstrates the bash bug (CVE-2014-6271).
Much of the impact of the Shell Shocked vulnerability is unknown and will surface in the coming months as researchers, admins and attackers (natch) find new avenues of exploitation. It’s not just web, but there are other services that are vulnerable, such as the DHCP service reported in the initial advisory. This is the sort of exploit that will be lurking around in all various and sundry sorts of software, both local and remote.
How can I test the system vulnerability?
First you can lock into your Linux system and run the following command to see the version of the bas you have:
bash –version
Red Hat recommends to use the following command to check bash version:
rpm -qa bash
Bug in Bash shell creates big security hole on anything with *nix in it article has simple shell test command (which I could not get working as expected). How do I recompile Bash to avoid the remote exploit CVE-2014-6271 and CVE-2014-7169? discussion has test code that seems to work. It used the same idea as in Fedora test code.
CVE-2014-6271 / Shellshock & How to handle all the shells!article has one test code. Everything you need to know about the Shellshock Bash bug article has some web request example. Bash ‘shellshock’ scan of the Internet has some example configuration.
There are Shellshock Bash Vulnerability Online Checkers Available, for example CVE-2014-6271/CVE-2014-7169 tes page.
What can you do?
Unix/Linux Bash: Critical security hole uncovered article tells that first you should sanitize the web applications’ inputs. If you’ve already done this against such common attacks as cross-site scripting (XSS) or SQL injection, you’ll already have some protection. Akamai’s recommendation is to switch “away from using Bash to another shell” if possible (the problem could be that alternative shell will not use exactly the same syntax and it may not have all the same features).
Because bash is the system shell other services are in danger. OpenSSH is also vulnerable via the use of AcceptEnv variables, TERM, and SSH_ORIGINAL_COMMAND. However, since to access those you already need to be in an authenticated session, you’re relatively safe. Consider limiting SSH access if you have many users. Switching to zsh only helps if you also removed bash and sh from your system.
Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169) article gives some tips for temporary work-around for web services using mod_security and IPtables.
The real fix will be to replace the broken Bash with a new, secure one. This means lots of work for many administrators to install update. Bash’s developers have patched all current versions of Bash, from 3.0 to 4.3. Most people invest heavily in Windows patching and are utterly awful at patching Linux. Your Linux systems need to apply this patch. Patches have been issued by many of the major Linux distribution vendors for affected versions. You have also option to recompile Bash to avoid the remote exploit CVE-2014-6271 and CVE-2014-7169 because this is open source software. Fedora has instructions how to download and compile. You will need to patch ASAP.
58 Comments
Tomi Engdahl says:
Shellshock Bash bug patch is buggy: ‘Millions of systems’ still at risk
But don’t delay – update your gear now to avoid early attacks hitting the web
http://www.theregister.co.uk/2014/09/25/shellshock_bash_worm_type_fears/
A patch for the severe Shellshock security vulnerability in Bash is incomplete – as hackers exploit the hole to compromise computers.
The flaw affects the GNU Bourne Again Shell – better known as Bash – which is a command interpreter used by many Linux and Unix operating systems – including Apple’s OS X.
It allows miscreants to remotely execute arbitrary code on systems ranging from web servers, routers, servers and Macs to various embedded devices that use Bash, and anything else that uses the flawed open-source shell.
The Bash flaw – designated CVE-2014-6271 – is being exploited in the wild against web servers, which are the most obvious targets but not by any means the only machines at risk.
Tomi Engdahl says:
Hackers thrash Bash Shellshock bug as world races to patch hole
Update your gear now to avoid early attacks hitting the web
http://www.theregister.co.uk/2014/09/25/shellshock_bash_worm_type_fears/
Sysadmins and users are urged to patch the severe Shellshock vulnerability in Bash on Linux and Unix systems – as hackers ruthlessly exploit the flaw to compromise or crash computers.
But as “millions” of servers, PCs and devices lay vulnerable or are being updated, it’s emerged the fix is incomplete.
It allows miscreants to remotely execute arbitrary code on systems ranging from web servers, routers, servers and Macs to various embedded devices that use Bash, and anything else that uses the flawed open-source shell.
An attacker needs to inject his or her payload of code into the environment variables of a running process – and this is surprisingly easy to do, via Apache CGI scripts, DHCP options, OpenSSH and so on. When that process or its children invoke Bash, the code is picked up and executed.
The Bash flaw – designated CVE-2014-6271 – is being exploited in the wild against web servers, which are the most obvious targets but not by any means the only machines at risk.
New packages of Bash were rolled out on the same day, but further investigation made it clear that the patched version is still exploitable, and at the very least can be crashed due to a null-pointer exception. The incomplete fix is being tracked as CVE-2014-7169.
Red Hat, at time of writing, is urging people to upgrade to the version of Bash that fixes the first reported security hole, and not wait for the patch that fixes the secondary lingering vulnerability – designated CVE-2014-7169.
“CVE-2014-7169 is a less severe issue and patches for it are being worked on,”
The main CVE-2014-6271 flaw was discovered by Stephane Chazelas of Akamai before it was responsibly disclosed. A Metasploit module leveraging the bug is already available. A blog post by Metasploit developers Rapid7 explains the grim state of play.
Bigger than Heartbleed? Yes, it is
Secunia warns that Shell Shock is “bigger than Heartbleed” because it enables hackers to execute commands to take over servers and systems. Heartbleed, by contrast, leaked users’ passwords and other sensitive information, and did not allow third parties to directly hijack affected systems.
“Compared to Heartbleed, the vulnerability in OpenSSL from earlier this year, Bash is worse: Heartbleed ‘only’ enabled hackers to extract information. Bash enables hackers to execute commands to take over your servers and systems,” explained Kasper Lindegaard, head of vulnerability intelligence specialist Secunia’s research team.
The National Institute of Standards and Technology (NIST) rates the flaw as 10 out of 10 in terms of severity, particularly as it is relatively simple to exploit. It’s rated at the maximum CVSS score of 10 for impact and ease of exploitability.
Joe Hancock, cyber security specialist with Lloyd’s of London insurance syndicate AEGIS London, commented: “The bug has existed for over 25 years in the Bash software, making it exceptionally pervasive. An exploit for the vulnerability was released within hours of the bug being announced, which directly enables the targeting of vulnerable web servers.”
“The new bash vulnerabilities are certainly very serious, and have an impact on many different types of systems, from straightforward Unix servers, to routers and industrial control systems using Unix as a back end,”
“So the real issue is more in the other applications, like CGI scripts on web servers, which could be manipulated to inject the code as part of their usual process. The point is that these attacks only work in combination with other attack vectors; and as with malware infections, multiple methods are required to compromise a system.”
Party like it’s 1999 – this is going to turn into a worm
“The potential for attackers utilizing Shell Shock is huge with millions of Unix and Linux servers vulnerable,” Millard warned.
“The major concern of Shell Shock is the staggering amount of systems that have Bash installed – almost every Unix platform and many of the ‘Internet of Things’ devices we now have in our homes and businesses.
“Unfortunately, due to the ease of exploit, Shell Shock is a prime candidate for a worm. We could be looking at another SQL Slammer-like worm but instead of 100,000 servers being affected, it could be more like 100,000,000, which would be catastrophic.
“Every organisation should be scanning for this vulnerability today and patching everything they can. On a scale of one-10, 10 being critical, this bug is an 11 and should be treated as such.”
Tomi Engdahl says:
Bash-ing Into Your Network – Investigating CVE-2014-6271
https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271
Should I panic?
The vulnerability looks pretty awful at first glance, but most systems with Bash installed will NOT be remotely exploitable as a result of this issue.
What is vulnerable?
This attack revolves around Bash itself, and not a particular application, so the paths to exploitation are complex and varied. So far, the Metasploit team has been focusing on the web-based vectors since those seem to be the most likely avenues of attack. Standard CGI applications accept a number of parameters from the user, including the browser’s user agent string, and store these in the process environment before executing the application. A CGI application that is written in Bash or calls system() or popen() is likely to be vulnerable, assuming that the default shell is Bash.
Secure Shell (SSH) will also happily pass arbitrary environment variables to Bash, but this vector is only relevant when the attacker has valid SSH credentials
There are likely many other vectors (DHCP client scripts, etc), but they will depend on whether the default shell is Bash or an alternative such as Dash, Zsh, Ash, or Busybox, which are not affected by this issue.
The two most likely situations where this vulnerability will be exploited in the wild:
Diagnostic CGI scripts that are written in Bash or call out to system() where Bash is the default shell
PHP applications running in CGI mode that call out to system() and where Bash is the default shell
A DDoS bot that exploits this issue has already been found in the wild by @yinettesys
Is it as bad as Heartbleed?
There has been a great deal of debate on this in the community, and we’re not keen to jump on the “Heartbleed 2.0” bandwagon. The conclusion we reached is that some factors are worse, but the overall picture is less dire.
A DDoS bot that exploits this issue has already been found in the wild by @yinettesys
https://twitter.com/yinettesys/status/515012126268604416
Tomi Engdahl says:
A DDoS bot that exploits this issue has already been found in the wild by @yinettesys
https://twitter.com/yinettesys/status/515012126268604416
https://gist.github.com/anonymous/929d622f3b36b00c0be1
Tomi Engdahl says:
Bad boy builds beastly Bash bug botnet, brutally batters boxes
DDoS zombie army found in the wild hours after flaw surfaces
http://www.theregister.co.uk/2014/09/26/bad_guy_builds_beastly_bash_botnet/
Mere hours after its discovery, the Shell Shock Bash vulnerability was exploited by an attacker to build a botnet.
The bot was discovered by researcher known as Yinette, who reported it on her Github account and said it appeared to be remotely controlled by miscreants.
Rapid 7 researcher Jen Ellis noted in a blog the discovery of the distributed denial of service bot, and described the Shellshock bug in detail.
Ok, shits real. Its in the wild… src:162.253.66.76
https://gist.github.com/anonymous/929d622f3b36b00c0be1
Tomi Engdahl says:
Some notes on vulnerability in Finnish:
Haavoittuvuus Bash-komentotulkissa
https://www.viestintavirasto.fi/tietoturva/haavoittuvuudet/2014/haavoittuvuus-2014-106.html
Tomi Engdahl says:
Critical Vulnerability Discovered in Bash
https://www.duosecurity.com/blog/critical-vulnerability-discovered-in-bash
As for a workaround, unfortunately, aside from nixing bash altogether and breaking things you didn’t know would break, there’s not a great workaround for this. While some network services, such as OpenSSH, may allow for restricting which environment variables are honored, a proper fix to bash is really the best solution. (Note: even removing all the AcceptEnv directives in OpenSSH would still allow for SSH_ORIGINAL_COMMAND to be passed through, so that’s pretty much moot).
Tomi Engdahl says:
Bash-komentotulkin Shellshock-haavoittuvuus mahdollistaa laajan hyväksikäytön
https://www.viestintavirasto.fi/tietoturva/varoitukset/2014/varoitus-2014-02.html
Tomi Engdahl says:
Shellshock DHCP RCE Proof of Concept
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
Replace the portion of the string “echo ‘foo’” with whatever command you want the client to execute. Keep in mind most clients will run dhcp hook scripts as root, but may not have a full environment defined in terms of PATH variables etc.
Test on client by trigging a DHCP address renew, this would normally happen to victims when the interface comes up.
Shellshock DHCP Remote Code Execution – Proof of Concept
https://news.ycombinator.com/item?id=8369443
Tomi Engdahl says:
Is connecting to an open WiFi router with DHCP in Linux susceptible to Shellshock?
http://security.stackexchange.com/questions/68156/is-connecting-to-an-open-wifi-router-with-dhcp-in-linux-susceptible-to-shellshoc
The dhclient-script network-configuration shell script is run during the DHCP process, and a number of parameters from the server (such as domain-name) are passed to it in environment variables. The script is set to be interpreted by /bin/sh, so if your system has that symlinked to /bin/bash (which is quite common), you’re vulnerable.
What’s more, on Debian (and possibly many of its myriads of offsprings like Ubuntu), which uses dash as /bin/sh, dhclient-script is explicitely shebanged to /bin/bash, and it does seem to contain a bashism, too.
Both dhclient and dhcpcd call configuration scripts that invoke a system shell, so they are vulnerable.
However, based on my testing it looks like you can run at least dhcpcd successfully without the config script (if you rename/move the script)
Tomi Engdahl says:
Confused about Shellshock? Patch what you can or be PUNISHED
UK data watchdog rolls up its sleeves, polishes truncheon
http://www.theregister.co.uk/2014/09/26/ico_shellshock_warning/
UK data privacy watchdogs are urging organisations to protect their systems against the infamous Shellshock vulnerability even though the full scope of the security bug currently remains unclear.
The Shellshock flaw affected the Bash component of many Linux systems, as well as the OS X operating system used by Apple Macs, along with networking kit and embedded devices.
The vulnerability could let hackers execute arbitrary code on vulnerable systems. Anything that uses the flawed open-source shell is vulnerable to being hijacked.
Patches for the main CVE-2014-6271 vulnerability are already available for most Linux distributions. However, there are reports that the patch is NOT a complete fix
An ICO spokesperson said: “This flaw could be allowing criminals to access personal data held on computers or other devices. For businesses, that should be ringing real alarm bells, because they have legal obligations to keep personal information secure. The worst thing would be to think this issue sounds too complicated – businesses need to be aware of this flaw and need to be monitoring what they can do to address it. Ignoring the problem could leave them open to a serious data breach and ultimately, enforcement action.”
Tomi Engdahl says:
Symantec Analyst Relations
Shellshock: All you need to know about the Bash Bug vulnerability
Created: 25 Sep 2014
http://www.symantec.com/connect/blogs/shellshock-all-you-need-know-about-bash-bug-vulnerability-0
Has it been exploited yet?
There are limited reports of the vulnerability being used by attackers in the wild. Proof-of-concept scripts have already been developed by security researchers. In addition to this, a module has been created for the Metasploit Framework, which is used for penetration testing.
Once the vulnerability has been made public, it was only a matter of time before attackers attempted to find and exploit unpatched computers.
How can it be exploited?
While the vulnerability potentially affects any computer running Bash, it can only be exploited by a remote attacker in certain circumstances. For a successful attack to occur, an attacker needs to force an application to send a malicious environment variable to Bash.
The most likely route of attack is through Web servers utilizing CGI (Common Gateway Interface), the widely-used system for generating dynamic Web content. An attacker can potentially use CGI to send a malformed environment variable to a vulnerable Web server. Because the server uses Bash to interpret the variable, it will also run any malicious command tacked-on to it.
The consequences of an attacker successfully exploiting this vulnerability on a Web server are serious in nature. For example attackers may have the ability to dump password files or download malware on to infected computers. Once inside the victim’s firewall, the attackers could then compromise and infect other computers on the network.
Aside from Web servers, other vulnerable devices include Linux-based routers that have a Web interface that uses CGI. In the same manner as an attack against a Web server, it may be possible to use CGI to exploit the vulnerability and send a malicious command to the router.
Linux vendors have issued security advisories for the newly discovered vulnerability including patching information.
Computers running Mac OS X are also potentially vulnerable until Apple releases a patch for the vulnerability.
Tomi Engdahl says:
Risk Assessment / Security & Hacktivism
New “Shellshock” patch rushed out to resolve gaps in first fix [Updated]
Weakness in patch discovered Wednesday fixed in code pushed out next day.
http://arstechnica.com/security/2014/09/new-shellshock-patch-rushed-out-to-resolve-gaps-in-first-fix/
Update, 9/26 11:00 PM ET: The most recent patches issued for the “Shellshock” bug have apparently still left avenues of attack, based on the analysis of several open source developers. See the latest report for further information.
Tomi Engdahl says:
Still more vulnerabilities in bash? Shellshock becomes whack-a-mole
Latest patch fixed one test case, but more vulnerabilities remain, say experts.
http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/
Remember when we said that a new patch had fixed the problems with the last patch to fix the rated-highly-dangerous “Shellshock” bug in the GNU Bourne Again Shell (bash)? You know, that bug that could allow an attacker to remotely execute code on a Linux or Unix system running some configurations of Apache, or perhaps the Git software version control system, DHCP network configuration or any number of other pieces of software that use bash to interact with the underlying operating system? Well, the new patch may not be a complete fix—and there may be vulnerabilities all the way down in the bash code.
Here’s how the Shellshock vulnerability works, in a nutshell: an attacker sends a request to a Web server (or Git, a DHCP client, or anything else affected) that uses bash internally to interact with the operating system. This request includes data stored in an environmental variable
But in this case, the data is malformed so as to trick bash into treating it as a comman
In other words, “Shellshock” may be partially patched, but it’s still highly dangerous on systems that might use bash to pass information to the operating system or to launch other software. And it may take a significant change to fix the code.
Wheeler made two specific recommendations for fixes to bash that will essentially break backward compatibility with older bash versions. The first is an idea suggested by German computer security expert Florian Weimer to add a prefix to bash functions, preventing them from being named the same thing as system variables (one of the mechanisms used to exploit the current bug). The second recommendation, put forward originally by NetBSD developer Dr. Christos Zoulas, is to allow bash to only import environmental variables into bash when explicitly requested—eliminating the risk of any other bugs in bash’s command parsing from accidentally bringing in malicious code or irrelevant data lying around in random defined environmental variables. Both of these changes, Wheeler said, are already being made by developers—function importing has been disabled by default in FreeBSD’s bash implementation in the latest fix.
Tomi Engdahl says:
Oracle Shellshocked by Bash bug – but Exalogic folk will have to wait
Database kingpin lists 32 products that can’t be patched (yet) as GNU fixes second vuln
http://www.theregister.co.uk/2014/09/27/oracle_no_shellshock_patches_yet/
Tomi Engdahl says:
Shell shock is dangerous also to Windows systems that have cygwin installed..
Shellshock and Cygwin
http://blog.disects.com/2014/09/shellshock-and-cygwin.html
Cygwin by default comes with 4.1.x version which has shellshock (CVE-2014-6271) vulnerability, use “bash –version” to check the version of bash shell.
Tomi Engdahl says:
25-year-old Bash Shellshock bug could be more dangerous than Heartbleed
http://www.geek.com/apps/25-year-old-bash-shellshock-bug-could-be-more-dangerous-than-heartbleed-1605349/
Bash has been helping Unix command line junkies tinker with their OSes since 1989. And today it appears as though a rather nasty security flaw has gone undetected in Bash since day one.
Several software vendors have already shipped patches to address Shellshock, but security researchers have found that some of them haven’t plugged the hole completely. Then there’s the patching problem we saw with Heartbleed: not everyone who’s in charge of server maintenance seems to think that these vulnerabilities need to be addressed with any sort of urgency.
There are still tens of thousands of servers on the ‘net that are vulnerable to Heartbleed months after it made the news. There’s no reason to think that the Bash flaw will be patched up any more quickly, and that could put everyone who connects to an unpatched server at risk.
As for your home network, there’s probably no need to panic: retail routers don’t generally ship with Bash in their firmware
Tomi Engdahl says:
‘Bigger than Heartbleed’ Shellshock flaw leaves OS X, Linux, more open to attack
http://www.pcworld.com/article/2687857/bigger-than-heartbleed-shellshock-flaw-leaves-os-x-linux-more-open-to-attack.html
Well, this isn’t good. Akamai security researcher Stephane Chazelas has discovered a devastating flaw in the Unix Bash shell, leaving Linux machines, OS X machines, routers, older IoT devices, and more vulnerable to attack. “Shellshock,” as it’s been dubbed, allows attackers to run deep-level shell commands on your machine after exploiting the flaw, but the true danger here lies in just how old Shell Shock is—this vulnerability has apparently been lurking in the Bash shell for years.
Why this matters: A large swath of the web-connected devices, web servers, and web-powered services run on Linux distributions equipped with the Bash shell, and Mac OS X Mavericks is also affected.
Security researchers are already finding evidence of the Shellshock Bash bug being exploited in the wild
Heartbleed redux
The news comes as the security community is just shaking off the effects of Heartbleed, a critical vulnerability in the widely used OpenSSL security protocol. “Today’s bash bug is as big a deal as Heartbleed,” says Errata Security’s Robert Graham, a respected researcher.
For the record, cygwin is vulnerable, as well as bash-3.1 from 2005
“Unlike Heartbleed, which only affected a specific version of OpenSSL, this bash bug has been around for a long, long time. That means there are lots of old devices on the network vulnerable to this bug. The number of systems needing to be patched, but which won’t be, is much larger than Heartbleed.”
Maybe not Heartbleed redux?
But don’t panic! (Or at least not yet.) While Heartbleed had the potential to be widely exploited, Jen Ellis of security firm Rapid7 says the Shellshock bug’s outlook isn’t quite as grim, even if it is rampant.
“The vulnerability looks pretty awful at first glance, but most systems with Bash installed will NOT be remotely exploitable as a result of this issue,”
Tomi Engdahl says:
Protect Your System from the Shellshock Bash Exploit
http://www.lynda.com/articles/shellshock-bash-exploit
Tomi Engdahl says:
Shellshock DHCP Remote Code Execution – Proof of Concept (trustedsec.com)
https://news.ycombinator.com/item?id=8369443
Shellshock DHCP RCE Proof of Concept
https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
Tomi Engdahl says:
Shellshock (software bug)
http://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
Tomi Engdahl says:
Firms BASH Bash bug with new round of Shellshock patches
Red Hat: ‘Applying multiple security updates is extremely difficult’
http://www.theregister.co.uk/2014/09/28/bash_shellshock_bug_patches_released_by_red_hat/
A fresh dump of Shellshock patches were released on Friday night in the latest move to stamp out the Bash shell security vuln that has the potential to blight millions of Linux, Unix and Mac OS X machines.
Red Hat said in a blog post that the threat from Shellshock was receding now that patches had been issued for most operating systems affected by the bug.
It comes after Apple said that “the vast majority of OS X users are not at risk” from the vuln.
Meanwhile, hackers have been trying to exploit the Shellshock security flaw – which can allow wrongdoers to hijack machines – just as tech outfits around the world scrambled to squish the 22-year-old Bash bug.
Red Hat said that it had now issued new patches for the bot, after its first round of fixes proved to be incomplete.
The flaws in Bash had gone undetected for so long, Sidhpurwala added, because they “were in a quite obscure feature that was rarely used”.
Tomi Engdahl says:
Still more vulnerabilities in bash? Shellshock becomes whack-a-mole
Latest patch fixed one test case, but more vulnerabilities remain, say experts.
http://arstechnica.com/security/2014/09/still-more-vulnerabilities-in-bash-shellshock-becomes-whack-a-mole/
Here’s how the Shellshock vulnerability works, in a nutshell: an attacker sends a request to a Web server (or Git, a DHCP client, or anything else affected) that uses bash internally to interact with the operating system. This request includes data stored in an environmental variable.
Environmental variables are like a clipboard for operating systems, storing information used to help it and software running on it know where to look for certain files or what configuration to start with. But in this case, the data is malformed so as to trick bash into treating it as a command, and that command is executed as part of what would normally be a benign set of script. This ability to trick bash is the shellshock bug. As a result, the attacker can run programs with the same level of access as the part of the system launching a bash shell. And in the case of a web server, that’s practically the same level of access as an administrator, giving the attacker a way to gain full control of the targeted system.
Tomi Engdahl says:
CVE-2014-6271 (Shellshock) DHCP Test
http://www.reddit.com/r/sysadmin/comments/2hqyt3/cve20146271_shellshock_dhcp_test/
I know, in internet age, shellshock, is already old, but i wrote a scapy (python) script to test for / trigger this exploit over dhcp clients.
In general you could just set up a dhcp server and set the option flag, but this way it would be more difficult to only test specific clients, spoof server and some other stuff.
I tested (successfully) with dhclient. But i saw other clients being mentioned as vulnerable. I am using the dhcp option 114 (url) as default field to supply the shellshock string. But there seem to be a bunch of possible fields (See end of post).
another_shellshock_test / shellshock_dhcp.py
https://github.com/SleepProgger/another_shellshock_test/blob/master/shellshock_dhcp.py
Tomi Engdahl says:
Shellshock DHCP server exploitation
http://www.sectechno.com/2014/09/28/shellshock-dhcp-server-exploitation/
Over this week the infosec community are busy in testing the bash shellshock vulnerability.
Tomi Engdahl says:
Frequently Asked Questions about the Shellshock Bash flaws
https://securityblog.redhat.com/2014/09/26/frequently-asked-questions-about-the-shellshock-bash-flaws/
Tomi Engdahl says:
What does SELinux do to contain the the bash exploit?
http://danwalsh.livejournal.com/71122.html
Lots of people are asking me about SELinux and the Bash Exploit.
SELinux does not block the exploit but it would prevent escallation of confined domains.
Tomi Engdahl says:
Worse still, Rapid7′s Metasploit penetration tool, which has often been used by hackers to attack sites, now has a Shellshock module. With this and similar script-kiddie tools available, expect the number of attacks to increase dramatically because now almost no technical skill is now needed to launch an assault.
Source: http://www.zdnet.com/shellshock-better-bash-patches-now-available-7000034115/
Tomi Engdahl says:
How to Manually Update Bash to Patch Shellshock Bug on Older Fedora-Based Systems
http://stevejenkins.com/blog/2014/09/how-to-manually-update-bash-to-patch-shellshock-bug-on-older-fedora-based-systems/
With the announcement of the Shellshock Bash Bug, Linux admins around the world have been scrambling to patch their Bash shells so that they’re no longer vulnerable to the exploit. If you have a Fedora, RHEL, or CentOS system that hasn’t reached End-Of-Life, then updating to a patched version of Bash is as simple as:
sudo yum update -y bash
But what if you have a system running Fedora 12, Fedora 13, Fedora 14, Fedora 15, Fedora 16, Fedora 17, Fedora 18, or Fedora 19… or even RHEL/CentOS 3 or RHEL/CentOS 4? I have a Fedora 12 box I keep around for testing, and an updated version of Bash isn’t available in the repos. In that case, you can actually download the Bash source, manually apply all the patches, and compile and install it manually. It’s not as hard as you think! In fact, check out the comments for reports of people successfully patching all the way back to Fedora 9 using this method!
Tomi Engdahl says:
Here is a good site on shellshock
https://shellshocker.net/
Tomi Engdahl says:
Bash bug flung against NAS boxes
SSHit just got real
http://www.theregister.co.uk/2014/10/01/sheelshock_nas_attack/
Hackers are attempting to exploit the BASH remote code injection vulnerability against Network Attached Storage (NAS) systems.
Miscreants are actively exploiting the time-to-patch window in targeting embedded devices, security firm FireEye warns.
We have evidence that attackers are actively exploiting the time-to-patch window and targeting embedded devices, specifically those made by QNAP, in order to append their SSH key to the authorized_keys file and install an ELF backdoor.
The sheer number of devices which run an embedded Linux OS mean that the potential for wide scale compromise of network-connected personal and business data storage systems is very high. Many smart or connected devices utilise similar set-ups as NAS boxes and may be just as vulnerable.
Tomi Engdahl says:
Shellshock: ‘Larger scale attack’ on its way, warn securo-bods
Not just web servers under threat – though TENS of THOUSANDS have been hit
http://www.theregister.co.uk/2014/09/29/shell_shock_bash_vuln_large_scale_attack/
The Shellshock vulnerability has already become the focus for malicious scanning and at least one botnet but crooks are still testing the waters with the vulnerability and much worse could follow, security watchers warn.
Net security firm FireEye said it has seen all manner of overtly malicious traffic leveraging the Bash bug, including DDoS attacks, malware droppers, reverse shell hacks, backdoors and data exfiltration. Some of the suspicious activity seems to be originating from Russia.
Attackers have deployed scanners looking for vulnerable machines that have been bombarding networks with traffic since mid-day Wednesday. So far, the Common Gateway Interface vector (an interface between a web server and executables that produce dynamic content) has received the bulk of the attention from attackers. However the scope of the Bash Shell Shock bug extends far behind web servers.
“We suspect bad actors may be conducting an initial dry run, in preparation for a real, potentially larger-scale attack,” FireEye warns.
Tomi Engdahl says:
Third patch brings more admin Shellshock for the battered and Bashed
‘Okay we got it THIS time’
http://www.theregister.co.uk/2014/09/30/third_patch_brings_more_admin_shellshock_for_the_battered_and_bashed/
A third patch, from Red Hat engineer Florian Weimer, has been released for the vulnerable Bash Unix command-line interpreter, closing off flaws found in two previous fixes.
The first patch (CVE-2014-6271) released Wednesday when the Shellshock flaw dropped was rapidly bypassed. An ensuing fix failed to stop underlying and newly-discovered holes that may have resulted in security vulnerabilities.
Google security engineer Michal Zalewski described the patches in a blog and said the previous patches, while imperfect, reduced attack vectors.
“[The flawed patches] led to a round of high-profile press reports claiming that we’re still doomed, and people assigning the new bug CVSS scores all the way up to 11.”
The private remote code execution bug may be revealed in coming days, placing importance on the need for admins to apply the patches.
Tomi Engdahl says:
Oracle SHELLSHOCKER – data titan lists unpatchables
Database kingpin lists 32 products that can’t be patched (yet) as GNU fixes second vuln
http://www.theregister.co.uk/2014/09/27/oracle_no_shellshock_patches_yet/
Oracle has confirmed that at least 32 of its products are affected by the vulnerability recently discovered in the Bash command-line interpreter – aka the “Shellshock” bug – including some of the company’s pricey integrated hardware systems.
The database giant issued a security alert regarding the issue on Friday, warning that many Oracle customers will have to wait awhile longer to receive patches.
Tomi Engdahl says:
Apple’s Shellshock patch for Macs is incomplete, says security researcher
http://www.cnet.com/news/apples-shellshock-patch-incomplete-say-experts/
Apple just released a patch for Shellshock, a bug that could give hackers access to Macintosh computers, but a security specialist says Apple fixed only two out of three security holes.
Tomi Engdahl says:
Inside Shellshock: How hackers are using it to exploit systems
http://blog.cloudflare.com/inside-shellshock/
On Wednesday of last week, details of the Shellshock bash bug emerged. This bug started a scramble to patch computers, servers, routers, firewalls, and other computing appliances using vulnerable versions of bash.
CloudFlare immediately rolled out protection for Pro, Business, and Enterprise customers through our Web Application Firewall. On Sunday, after studying the extent of the problem, and looking at logs of attacks stopped by our WAF, we decided to roll out protection for our Free plan customers as well.
Since then we’ve been monitoring attacks we’ve stopped in order to understand what they look like, and where they come from. Based on our observations, it’s clear that hackers are exploiting Shellshock worldwide.
Tomi Engdahl says:
Building a Honeypot To Observe Shellshock Attacks In the Real World
http://it.slashdot.org/story/14/10/02/1539242/building-a-honeypot-to-observe-shellshock-attacks-in-the-real-world
A look at some of the Shellshock-related reports from the past week makes it seem as if attackers are flooding networks with cyberattacks targeting the vulnerability in Bash that was disclosed last week. While the attackers haven’t wholesale adopted the flaw, there have been quite a few attacks—but the reality is that attackers are treating the flaw as just one of many methods available in their tool kits.
Observing Shellshock Attacks in the Real World
http://news.dice.com/2014/10/02/observing-shellshock-attacks-in-the-real-world/
A look at some of the Shellshock-related reports from the past week makes it seem as if attackers are flooding networks with cyberattacks targeting the vulnerability in Bash that was disclosed last week. While the attackers haven’t wholesale adopted the flaw, there have been quite a few attacks—but the reality is that attackers are treating the flaw as just one of many methods available in their tool kits.
Security experts have warned that, because the flaw is so widespread, and the fact that a successful attempt would give the adversary shell access, a large number of attacks is looming. The good thing about the vulnerability, despite that scary-sounding “Shellshock” name, is that defenders can tell when attackers are targeting the flaw. “Everyone should watch their logs carefully—this exploit is noisily and easily logged,” said Daniel Ingevaldson, CTO of Easy Solutions.
One way to get a front-row seat of what the attacks look like is to set up a honeypot. Luckily, threat intelligence firm ThreatStream released ShockPot, a version of its honeypot software with a specific flag, “is_shellshock,” that captures attempts to trigger the Bash vulnerability. Since attackers are systematically scanning all available addresses in the IPv4 space, it’s just a matter of time before someone finds a particular ShockPot machine.
And that was definitely the case, as our honeypot captured a total of seven Shellshock attack attempts out of 123 total attacks. On one hand, that’s a lot for a machine no one knows anything about; on the other, it indicates that attackers haven’t wholesale dumped other methods in favor of going after this particular bug. PHP was the most common attack method observed on this honeypot, with various attempts to trigger vulnerabilities in popular PHP applications and to execute malicious PHP scripts.
Tomi Engdahl says:
Third patch brings more admin Shellshock for the battered and Bashed
‘Okay we got it THIS time’
By Darren Pauli, 30 Sep 2014
http://www.theregister.co.uk/2014/09/30/third_patch_brings_more_admin_shellshock_for_the_battered_and_bashed/
A third patch, from Red Hat engineer Florian Weimer, has been released for the vulnerable Bash Unix command-line interpreter, closing off flaws found in two previous fixes.
Weimer’s unofficial fix was adopted upstream by Bash project maintainer Chet Ramey and released as Bash-4.3 Official Patch 27 (bash43-027) which addressed a bunch of previously undisclosed flaws including two remote exploit bugs.
The first patch (CVE-2014-6271) released Wednesday when the Shellshock flaw dropped was rapidly bypassed.
The latest bug closed off remote code execution found after the second patch was applied which has not been made public.
“This patch changes the encoding bash uses for exported functions to avoid clashes with shell variables and to avoid depending only on an environment variable’s contents to determine whether or not to interpret it as a shell function.” Bash patch report.
Google security engineer Michal Zalewski described the patches in a blog and said the previous patches, while imperfect, reduced attack vectors.
“At this point, I very strongly recommend manually deploying Florian’s patch unless your distro is already shipping it.”
Tomi Engdahl says:
OpenVPN open to pre-auth Bash Shellshock bug – researcher
Fallout continues. But you’ve patched, right? Right?
http://www.theregister.co.uk/2014/09/30/openvpn_open_to_shellshock_researcher/
The Shellshock Bash bug, the gift that just keeps on taking, could also sting OpenVPN users, according to researcher Fredrick Stromberg.
Pre-authentication vectors affect communication through the popular and formerly secure VPN platform, he says.
“OpenVPN servers are vulnerable to Shellshock under certain configurations,” Stromberg said.
“OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session. Many of these commands are called with environmental variables set, some of which can be controlled by the client.
“One option used for username+password authentication is auth-user-pass-verify. If the called script uses a vulnerable shell, the client simply delivers the exploit and payload by setting the username. This attack vector is pre-auth.”
Those using OpenVPN can dodge Shellshock by preventing Bash from running scripts.
OpenVPN’s Gert Doering told Threat Post OpenVPN was vulnerable only on systems where /bin/sh points to /bin/bash, or when scripts running bash as an interpreter were called explicitly.
” use a shell that is better suited to script usage, like ash/dash,”
“Also, always use client certificates, as the username verification script that is the attack vector here is only called after successful verification of a client cert.”
Tomi Engdahl says:
Bash bug flung against NAS boxes
SSHit just got real
http://www.theregister.co.uk/2014/10/01/sheelshock_nas_attack/
Hackers are attempting to exploit the BASH remote code injection vulnerability against Network Attached Storage (NAS) systems.
Miscreants are actively exploiting the time-to-patch window in targeting embedded devices, security firm FireEye warns.
We have evidence that attackers are actively exploiting the time-to-patch window and targeting embedded devices, specifically those made by QNAP, in order to append their SSH key to the authorized_keys file and install an ELF backdoor.
Tomi Engdahl says:
Everything you need to know about the Shellshock Bash bug
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
Tomi Engdahl says:
OpenVPN servers can be vulnerable to Shellshock Bash vulnerability
http://www.pcworld.com/article/2690372/openvpn-servers-can-be-vulnerable-to-shellshock-bash-vulnerability.html
Virtual private network servers based on OpenVPN might be vulnerable to remote code execution attacks through Shellshock and other recent flaws that affect the Bash Unix shell.
The OpenVPN attack vector was described in a post on Hacker News Tuesday by Fredrik Strömberg, co-founder of a commercial VPN service called Mullvad.
“OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session,” Strömberg said. “Many of these commands are called with environmental variables set, some of which can be controlled by the client.”
One OpenVPN configuration option that allows for Shellshock exploitation is called auth-user-pass-verify. According to the software’s official documentation this directive provides a plug-in-style interface for extending an OpenVPN server’s authentication capabilities.
The option executes an administrator-defined script via the command-line interpreter in order to validate user names and passwords supplied by connecting clients. This opens up the possibility of clients supplying maliciously crafted user names and passwords that exploit the Shellshock vulnerability when passed to Bash as strings.
However, it does appear that the developers of OpenVPN knew about the general security risks associated with auth-user-pass-verify even before the recent Bash flaws were discovered.
“Care must be taken by any user-defined scripts to avoid creating a security vulnerability in the way that these strings are handled,” the official OpenVPN documentation warns for this configuration option. “Never use these strings in such a way that they might be escaped or evaluated by a shell interpreter.”
Shellshocking OpenVPN servers
https://news.ycombinator.com/item?id=8385332
Tomi Engdahl says:
OpenVPN ShellShock PoC
http://pastebin.com/VyMs3rRd
Tomi Engdahl says:
Hackers Compromised Yahoo Servers Using Shellshock Bug
http://tech.slashdot.org/story/14/10/06/1712211/hackers-compromised-yahoo-servers-using-shellshock-bug
Hackers were able to break into some of Yahoo’s servers by exploiting the recently disclosed Shellshock bug over the past few weeks. This may be the first confirmed case of a major company being hit with attacks exploiting the vulnerability in bash.
Hackers Compromised Yahoo Servers Using Shellshock Bug
http://www.securityweek.com/hackers-compromised-yahoo-servers-using-shellshock-bug
Attackers have figured out a way to get onto some of Yahoo’s servers via the Shellshock bug over the past few weeks. This may be the first confirmed case of a major company being hit with attacks exploiting the vulnerability in bash.
At least two servers for Yahoo Games have been breached, Jonathan Hall, a security researcher and a senior engineer with Future South Technologies, wrote on Reddit. The servers were vulnerable because they were using an older version of bash, Hall said. Yahoo confirmed the breach over email
“This breach is very serious, and jeopardizes every consumer that uses Yahoo! in any manner, from shopping to email, and even game playing,” Hall wrote in a detailed technical post on Future South Technologies website.
Hall noted that millions of people visit Yahoo Games per day, and the games themselves are Java-based. Considering that Shellshock give attackers full control of the compromised server, there are many things attackers can do, such as stealing user information, harvesting financial data, and infecting visitor computers with malware.
“Romanian hackers are currently working on further infiltrating the Yahoo! Network, and also have infiltrated Lycos and WinZip.com,” Hall wrote.
Tomi Engdahl says:
Yahoo confirms its servers were breached via a Shellshock exploit, but says no user data was accessed — Shellshock: Romanian hackers are accessing Yahoo servers, claims security expert — Hackers are exploiting Yahoo’s bash bug vulnerability, according to technology consultant Jonathan Hall
Shellshock: Romanian hackers are accessing Yahoo servers, claims security expert
http://www.independent.co.uk/life-style/gadgets-and-tech/news/shellshock-romanian-hackers-are-accessing-yahoo-servers-claims-security-expert-9777753.html
Yahoo servers have been infiltrated by Romanian hackers exploiting the Shellshock bug discovered last month, according to cyber security expert Jonathan Hall.
Hall had Google-searched a range of codes designed to identify which servers were vulnerable to Shellshock, and found that Romanian hackers had breached two Yahoo servers and were exploring the network in search of access points for Yahoo!Games, which has millions of users.
A Yahoo told The Independent: “A security flaw, called Shellshock, that could expose vulnerabilities in many web servers was identified on September 24.
Before releasing this information, Hall emailed Yahoo and tweeted at its engineering team and CEO Marissa Mayer.
It was confirmed to him that its servers had been infiltrated but Yahoo refused to pay him for alerting them as it was not part of the company’s bug bounty programme. Yahoo is notorious for its disregard of bug bounty hunters
In a blog post on his website Future South, Hall detailed the process by which he discovered Yahoo, Lycos and WinZip websites had all been infiltrated by a group of Romanian hackers.
http://www.futuresouth.us/wordpress/
Tomi Engdahl says:
Yahoo! Shellshocked Like Ninja Turtles!
http://www.futuresouth.us/wordpress/?p=5
Yahoo! Has been HACKED, and all your information with them is now in danger! All stemming from them not keeping up with technology and failing to patch a world-known vulnerability!
This document stands to serve as a technical explanation as well as detailed overview of how I identified the yahoo.com breach, and how I’ve identified that they are – in fact – compromised. At the time of writing this, Romanian hackers are currently working on further infiltrating the Yahoo! Network, and also have infiltrated Lycos and WinZip.com . I’ve notified both Yahoo! and the FBI New Orleans field office of the infiltration, but in my eyes, they really aren’t seeing the severity and danger of this situation, and really are not reacting quick enough.
When the bug was first disclosed, I immediately began doing my research on it. Because it affects something that is so wide spread, it’s safe for me to go ahead and say that it more than piqued my curiosity. And at the time, the only information on it was how to pull it off from a command-line, but being a bash junkie, I saw the potential danger of it immediately.
Successful exploitation vectors as been achieved in many methods, not limited to just web scripts. I have successfully exploited bash through not only web scripts, but FTP servers where certain conditions are met (possibly considered race-conditions) – external authentication modules for instance, OpenSSH and even through a stratum server being run by a bitcoin mining pool.
The original code I wrote simply searched google.com for various search phrases, including, but not limited to: inurl:cgi-bin filetype:sh, inurl:cgi-bin filetype:pl, inurl:cgi-bin filetype:cgi
To clarify what’s going on here, this is actually a standard HTTP GET request with what would be considered malformed headers.
What this is doing is forcing bash to run and pipe itself through a tcp session to my box on a specific port.
Before I knew it, I was getting an onslaught of boxes connecting left and right.
A majority of the sites that were successfully exploited using the spidering method didn’t really appear to have been compromised by anyone else. The ones found on google all seemed to have various forms of local root exploits and scripts scattered through /tmp and /var/tmp on the boxes, indicating that others had also used the same vector for exploitation. But what’s more interesting is that the most common remnants and identifier that they were compromised was generally perl-based IRC DDoS bots.
Tomi Engdahl says:
The Shellshock vulnerability, aka the “Bash Bug”
http://blog.trendmicro.com/the-bash-bug-vulnerability/
Tomi Engdahl says:
Shellshock just ‘a blip’ says Richard Stallman as Bash bug attacks increase
GNU Project founder: ‘Any program can have a bug. But a proprietary program is likely to have intentional bugs’
http://www.theguardian.com/technology/2014/sep/26/bash-bug-shellshock-richard-stallman
First it was Heartbleed, now it’s Shellshock. Two vulnerabilities affecting many of the planet’s web users have hit widely deployed free and open source software in a matter of months.
Heartbleed brought about distrust in OpenSSL, which was designed to make websites more secure but instead opened them up to attack.
Earlier this week, Shellshock landed, allowing hackers to easily exploit many web servers that used the free and open source Bash command line shell, managed by the GNU Project.
GNU Project founder Richard Stallman told the Guardian that Shellshock will soon be deemed by the world as only “a blip”.
There are indications Shellshock is considerably more prevalent than initially predicted too. “Right now people are pretty much falling over themselves trying to come up with the craziest attack vector possible,” said security expert Andreas Lindh, who successfully exploited his own Buffalo Linkstation Network Attached Storage (NAS) device using the Bash bug.
The vulnerability was supposed to only affect those machines that ran Bash as their default command line interface, but mounting evidence has hinted even those using related interpreters could be exploited.
Lindh’s NAS ran Bash alternative Dash by default and a tweet from security researcher Dragos Ruiu appeared to back up Lindh’s early research. If derivatives of Bash are also vulnerable to Shellshock, this would widen the number of potential targets massively.
“We should probably not make big a fuss about that just yet, but if it turns out that some old Dash shells are also vulnerable, then consumer appliances will definitely be at risk,” Lindh added.
Tomi Engdahl says:
Attention Buffalo TeraStation and LinkStation NAS users
10/05/2014 . Partner News Press Releases
http://www.buffalo-technology.com/en/media/press-releases/article/attention-buffalo-terastation-and-linkstation-nas-users-buffalo-releases-firmware-update-for-shells/?tx_news_pi1controller=News&tx_news_pi1action=detail&cHash=2a86c1281995ec369a3516c91a4e79fc
BUFFALO releases firmware update for Shellshock vulnerability
if the optional WebServer feature is enabled on your LinkStation or TeraStation device (disabled by default and must be enabled by administrator), your unit is at risk for BASH security related vulnerabilities.
Becky says:
Tom, I am trying to understand all of this. Perhaps you could answer some questions about this.
I am an at home user of Ubuntu 14.04. I have bash, dash and busybox installed on my Ubuntu desktop. Would I need to be worried about hackers hacking in to my computer? Also, if I had a router hooked up to my computer that uses busybox and I had a firewall on that same router, would a hacker be able to compromise me that way? I have been reading so much about this and am so confused by all of it that I want to know what to do to protect myself against this thing beyond what I am already doing, which is I am installing security updates every time Ubuntu tells me there is one available. Please let me know! You can email privately if you want to or respond here on your blog, whichever you want–I just need to know!
Tomi Engdahl says:
> I am an at home user of Ubuntu 14.04. I have bash, dash and busybox installed on my Ubuntu desktop.
You have bash installed in your box. It will be vulnerable bash if you have not updated it last well (do test to see).
You need to have bash 4.3.27 or newer (if such has come up).
Let’s assume you have vulnerable bash. If anyone can use that to hit your computer depends on what you use it for.
The main attack vectors are:
Web services – if you run web server and use CGI-scripts your are in danger because anyone connecting to web server can run commands
SSH – users that have credentials to system (user account and password) might be able to run command at higher than their own right
OpenVPN server – if you run OpenVPN server with password authentication anyone can potentially run commands on your system
DHCP – if someone compromises your DHCP server (usually your broadband router) they can run command on your system
If you are not running web server or OpenVPN server, no worries on them.
SSH vulnerability is an issue mainly on multi-user systems where there are many different people using the same computer with different user levels, if you are the only user of your desktop then I would not worry much…
DHCP vulnerability could be issue after if someone hacks to your DHCP server or has physical access to your LAN to put in a rogue DHCP server in…
> Also, if I had a router hooked up to my computer that uses busybox and I had a firewall on that same router, would a hacker be able to compromise me that way?
The busybox as itself would not be vulnerable. If someone can hack in your router some way, they might or might not be able (depends on router design) to use it to make the DHCP attack.. Not very probable though.
> I want to know what to do to protect myself against this thing beyond what I am already doing, which is I am installing security updates every time Ubuntu tells me there is one available. Please let me know!
Install the security updates and verify the bash version you already have. That’s the best start.
This shellshock is a serious issue if you have an Internet facing public server – you need to worry (I spend some nights on this issue on this web site to keep it safe… first quick fix with firewall rules, then bash update and taking modsecurity to use, then fixing some issues that modsecurity caused)
If you have normal desktop Linux workstation behind the firewall that you keep up-to-date it is a less of an issue.