New Shell Bug Shell Shock Bash Bug Remote

And local root command execution vulnerability CVE-2014-6271 and CVE-2014-7169

Are you vulnerable and properly already been hacked by the new Bash security vulnerability that goes under many names such Shellbug, Shellshock,bashbug.

Most Linux distributions, embedded devices based on linux, Mac OS X was vulnerable overnight leaving users at risk.

In many cases it only caused a risk locally and not remote.

More information at:

Slackware http://slackbuilds.org/mirror/slackware/slackware-14.1/patches/packages/?C=M;O=D


Red Hat has updated its advisory and patch information for this vulnerability.

Only a temporary patch which is incomplete.
 

This vulnerability allows a 5th grader to easily exploit it

Click to get more information on the Penetrator Vulnerability Scanner Scanner software or Appliance.


Find out if your computer or server is vulnerable?

If you run on Windows 7, Windows 8.1 or Windows servers a big chance you do not need worry at all.

However if you are running on Mac OS X even the latest at this time writing 10.9.4 or Linux most distributions you might be at very high risk.

SecPoint recommends to patch your system asap

Or replace bash with another shell and on Mac OS X disable remote login.

Open up a  terminal cmd window and put the following key command at the $ cmd prompt:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

The output on a vulnerable system will be:

attackvulnerable
this is a testing

A patched or unaffected system will output different.

It is surprised that code written today sets environment variables unchecked from network input than there is an exploit with #bashbug

Shellshock: The 'Bash Bug' That Could Be Worse Than Heartbleed


Mac users should disable remote login until Apple releases a patch for

It is exploitable via the following command:
SSH_ORIGINAL_COMMAND:


SSH_ORIGINAL_COMMAND &&" does not help - we'd have to unset the variable

before beginning bash, not from bash.

TERM is another assault vector, however IIRC sshd does not set TERM when

no-pty is utilized. In this way, talking about SSH constrained charges, it seems, by all accounts, to be

just SSH_ORIGINAL_COMMAND that we have awful workaround for.

In reality, there are numerous different setups where the issue is exploitable,

not simply SSH constrained summons.

It is not just popular operation systems and software packages that are vulnerable but also many embedded devices and wireless routers.

SecPoint recommends to patch your system asap or replace bash with another shell and on Mac OS X disable remote login.