VMware issued a progress report on fixes for four different types of products as they relate to the Bash vulnerability.
Tag Archives: Bash
OpenVPN Vulnerable to Shellshock Bash Vulnerability
OpenVPN was found to be vulnerable to the Shellshock vulnerability in Bash as well. Fredrik Stromberg of Mullvad said the vulnerability is dangerous because it’s pre-authentication in OpenVPN.
How to fix Shellshock Bash on Mac OS X: Mavericks edition
Apple Mac OS X users concerned about the Bash vulnerability dubbed Shellshock got some relief late yesterday as Apple published fixes for various versions of OS X. But if you use Mavericks you will need to install 10.9.5 before the Bash fix will work.
The post How to fix Shellshock Bash on Mac OS X: Mavericks edition appeared first on We Live Security.
Shellshock vulnerability: should we be concerned?
We are continually hearing about bugs and vulnerabilities that could potentially be serious. The latest one named ShellShock can potentially be used to remotely take control of almost any system that is using a software component called Bash. This sounds devastating and it course of could be, but don’t start running for the hills or deciding to unplug from the Internet quite yet though.
Bash is a software component that exists on many Linux systems including Apple’s Mac OSX. As Linux is the operating system used on a large number of the web servers, a bug like this could mean cybercriminals have the potential to exploit the vulnerability and cause harm to users of the web server or indeed to the company whose web server it is. They do this by inserting malware on the server that could potentially collect data, cracks passwords or do something particularly malicious.
At the time of writing this blog there is already a large number of patches available that address this vulnerability for servers and reputable companies have teams in place that watch for these alerts and update their servers to protect them and the users of the services they offer. A good example is our own security team here at AVG who immediately ran an audit to see if we had any servers that may have this vulnerability, and they have already confirmed that our servers are safe.
If you are a Mac user should you be concerned and what do you need to do?
Apple has, as expected, reacted quickly and is releasing an automatic update to OSX that users will be prompted to install. They have also made it clear that the issue does not affect the majority and is an issue for power users that take advantage of the advanced UNIX services within OSX. If the previous sentence has baffled you then you are in the group that Apple say are not at risk.
Even as a power user at home you are likely to be sitting behind a firewall that would detect someone trying to execute commands on your machine and they would be blocked. However bad guys may well try and trick users to into installing files that could leave them more vulnerable to attack, a good rule is to not click something that you don’t recognize and remember the update will only come directly from Apple. When you see the update appear through on your Mac, install it immediately so that you stay safe.
There are also other devices in our homes that run Linux. Many of the routers and broadband modems we use to connect to the Internet also utilize Linux as an operating system and because of this we recommend you watch for updates from those vendors and take the action to install them. If your router is provided by your ISP then they should push the update to the router automatically.
It is good practice to allow the automatic updates on your devices so that they are maintained by the manufacturer of the device to protect you from issues like this. Having up to date anti-virus software installed and active is also of paramount importance in today’s environment where more of our data than ever before is held by us on our devices. The protection provided will detect and block an exploit such as this where cybercriminals attempt to install malware on your machine. AVG’s Free Antivirus is available for Mac and PC users and can be downloaded from www.avg.com
What to do about Shellshock bash bug on Mac OS X, web servers, routers, and more
The “Bash Bug” or “Shellshock” vulnerability means a wide range of devices, servers and computers, including Mac OS X, will need to be patched to prevent abuse by malicious persons. Here’s advice about what to do and links to more in-depth resources.
The post What to do about Shellshock bash bug on Mac OS X, web servers, routers, and more appeared first on We Live Security.
Honeypot Snares Two Bots Exploiting Bash Vulnerability
Two malware samples trying to exploit the Bash vulnerability, both DDoS bots, were snared in a honeypot belonging to AlienVault Labs.
Patching Bash Vulnerability a Challenge for ICS, SCADA
Experts are concerned that many Linux-based industrial control systems and embedded systems could be too steep a patching challenge and remain in the crosshairs of the Bash vulnerability.
Bash Exploit Reported, First Round of Patches Incomplete
Reports of the first in-the-wild exploits targeting the Bash vulnerability have surfaced, as have complaints the first patches for the bug are incomplete.
Major Bash Vulnerability Affects Linux, UNIX, Mac OS X
A critical remote code execution vulnerability in Bash, present in almost all Linux, UNIX and Mac OS X deployments, has been discovered. Experts advise immediate patching.
Bash specially-crafted environment variables code injection attack
Update 2014-09-30 19:30 UTC
Questions have arisen around whether Red Hat products are vulnerable to CVE-2014-6277 and CVE-2014-6278. We have determined that RHSA-2014:1306, RHSA-2014:1311, and RHSA-2014:1312 successfully mitigate the vulnerability and no additional actions need to be taken.
Update 2014-09-26 12:00 UTC
We have written a FAQ to address some of the more common questions seen regarding the recent bash issues.
Frequently Asked Questions about the Shellshock Bash flaws
Update 2014-09-25 16:00 UTC
Bash or the Bourne again shell, is a UNIX like shell, which is perhaps one of the most installed utilities on any Linux system. From its creation in 1980, Bash has evolved from a simple terminal based command interpreter to many other fancy uses.
In Linux, environment variables provide a way to influence the behavior of software on the system. They typically consists of a name which has a value assigned to it. The same is true of the Bash shell. It is common for a lot of programs to run Bash shell in the background. It is often used to provide a shell to a remote user (via ssh, telnet, for example), provide a parser for CGI scripts (Apache, etc) or even provide limited command execution support (git, etc)
Coming back to the topic, 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. The name of these crafted variables does not matter, only their contents. As a result, this vulnerability is exposed in many contexts, for example:
- ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
- Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in Bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
- PHP scripts executed with mod_php are not affected even if they spawn subshells.
- DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
- Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
- Any other application which is hooked onto a shell or runs a shell script as using Bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.
Like “real” programming languages, Bash has functions, though in a somewhat limited implementation, and it is possible to put these Bash functions into environment variables. This flaw is triggered when extra code is added to the end of these function definitions (inside the enivronment variable). Something like:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
The patch used to fix this flaw, ensures that no code is allowed after the end of a Bash function. So if you run the above example with the patched version of Bash, you should get an output similar to:
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
We believe this should not affect any backward compatibility. This would, of course, affect any scripts which try to use environment variables created in the way as described above, but doing so should be considered a bad programming practice.
Red Hat has issued security advisories that fixes this issue for Red Hat Enterprise Linux. Fedora has also shipped packages that fixes this issue.
We have additional information regarding specific Red Hat products affected by this issue that can be found at https://access.redhat.com/site/solutions/1207723
Information on CentOS can be found at http://lists.centos.org/pipermail/centos/2014-September/146099.html.