A new BASH bug?

[whatthefunk]

Im guessing most of you guys have seen this already, but:
http://www.bbc.com/news/technology-29361794

The flaw has been found in a software component known as Bash, which is a part of many Linux systems as well as Apple's Mac operating system.

The bug, dubbed Shellshock, can be used to remotely take control of almost any system using Bash, researchers said.

Bash was part of today's update, so Im guessing Ubuntu is already on top ot it. Does Android use Bash?

[Qqmike]

A new BASH bug?

Sept 24th:

New 'Bash' software bug may pose bigger threat than 'Heartbleed'

http://www.reuters.com/article/2014/...0HJ2FQ20140924


What's this? A friend pointed this out this morning. Fyi.

[vinnywright]

yes Ubuntu is on it ,,,,,,,, http://www.ubuntu.com/usn/usn-2362-1/ installing the updated bash now .......in a regular update "dist-upgrade"

VINNY

[vinnywright]

apt search bash ..................................
bash/trusty-updates,trusty-security,now [COLOR=#ff0000]4.3-7ubuntu1.1[/COLOR] amd64 [installed]
  GNU Bourne Again SHell

patched ver.

VINNY

[vinnywright]

see hear........................ https://www.kubuntuforums.net/showth...rability-found

the patched bash is out .......do your

sudo apt-get update && sudo apt-get dist-upgrade

today

VINNY

[GreyGeek]

I only found out about this Bash bug AFTER this morning's automatic update of FireFox and Bash.

http://www.abc.net.au/news/2014-09-2...tbleed/5769076

Nothing like a sensational headline ...

Tod Beardsley, an engineering manager at cybersecurity firm Rapid7, warned the bug was rated a "10" for severity, meaning it has maximum impact, and rated "low" for complexity of exploitation, meaning it is relatively easy for hackers to launch attacks.


"Using this vulnerability, attackers can potentially take over the operating system, access confidential information, make changes, et cetera," he said.

http://www.ubuntu.com/usn/usn-2362-1/

Details

Stephane Chazelas discovered that Bash incorrectly handled trailing code in
function definitions. An attacker could use this issue to bypass
environment restrictions, such as SSH forced command environments.

Despite the fact that Bash has been around for decades, I doubt that a script kiddie could have exploited it. Professional hacker?

No known exploits have been reported for this security hole, and no major Linux bot farms have been created since a group of crooks, several years ago, took 6 months to create a Linux bot farm from 700 servers that they MANUALLY broke into because they were poorly secured using default or no passwords. As usual, when you use passwords like that no holes are needed.

[Qqmike]

I assume this morning's update of Firefox and BASH includes the latest, correct BASH update, fixing the bug?

[Qqmike]

For 12.04, my latest installed ver is 4.2-2ubuntu2.2; NOT what Vinny posted.

[vinnywright]

For 12.04, my latest installed ver is 4.2-2ubuntu2.2; NOT what Vinny posted.

look hear ....... http://www.ubuntu.com/usn/usn-2362-1/

for 12.04 you have the patched bash
mine was for 14.04

VINNY

[Qqmike]

Thanks Vinny -- got it!

[TWPonKubuntu]

I saw this report yesterday, after the daily update.

http://arstechnica.com/security/2014...ith-nix-in-it/

This article includes a simple piece of test code to determine your fix status.

[vinnywright]

vinny@vinnys-HP-G62:~$ 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

well if that test is good then so am I .........

VINNY

[TWPonKubuntu]

I have exactly the same response on my system. But I make no guarantee that the test is valid...
I'll watch for more info on this.

[GreyGeek]

I have exactly the same response on my system. But I make no guarantee that the test is valid...
I'll watch for more info on this.

There are suggestions that the fix isn't complete. Here is more info for you, which was posted early today.
First, an explanation of the bug, posted yesterday:
http://www.openwall.com/lists/oss-se.../2014/09/24/11
with this comment:

With that out of the way, it is important to note that the today's patch provided by the maintainer of bash does not stop the shell from trying to parse the code within headers that begin with "() {" - it merely tries to get rid of that particular RCE side effect, originally triggered by appending commands past the end of the actual function def. But even with all the current patches applied, you can still do this:
Cookie: () { echo "Hello world"; }
...and witness a callable function dubbed HTTP_COOKIE() materialize in the context of subshells spawned by Apache; of course, the name will be always prefixed with HTTP_*, so it's unlikely to clash with anything or be called by incident - but intuitively, it's a pretty scary outcome.
...
Bash supports exporting not just shell variables, but also shell functions to other bash instances, via the process environment to (indirect) child processes. Current bash versions use an environment variable named by the function name, and a function definition starting with “() {” in the variable value to propagate function definitions through the environment. The vulnerability occurs because bash does not stop after processing the function definition; it continues to parse and execute shell commands following the function
definition. For example, an environment variable setting of

VAR=() { ignored; }; /bin/id

will execute /bin/id when the environment is imported into the bash process. (The process is in a slightly undefined state at this point. The PATH variable may not have been set up yet, and bash could crash after executing /bin/id, but the damage has already happened at this point.)

The fact that an environment variable with an arbitrary name can be used as a carrier for a malicious function definition containing trailing commands makes this vulnerability particularly severe; it enables network-based exploitation.
....

And Icmtuf adds:
http://lcamtuf.blogspot.com/2014/09/...ts-impact.html

What else? Oh, of course: the impact of this bug is an interesting story all in itself. At first sight, the potential for remote exploitation should be limited to CGI scripts that start with #!/bin/bash and to several other programs that explicitly request this particular shell.

But there's a catch: on a good majority of modern Linux systems, /bin/sh is actually a symlink to /bin/bash! This means that web apps written in languages such as PHP, Python, C++, or Java, are likely to be vulnerable if they ever use libcalls such as popen() or system(), all of which are backed by calls to /bin/sh -c '...'.

There is also some added web-level exposure through #!/bin/sh CGI scripts, <!--#exec cmd="..."> calls in SSI, and possibly more exotic vectors such as mod_ext_filter. For the same reason, userland DHCP clients that invoke configuration scripts and use variables to pass down config details are at risk when exposed to rogue servers (e.g., on open wifi). Finally, there is some exposure for environments that use restricted SSH shells (possibly including Git) or restricted sudo commands, but the security of such approaches is typically fairly modest to begin with.

So, I don't believe that we are done with this bug and I expect further patches down the road.

[TWPonKubuntu]

@GreyGeek
Thanks for the update. It never ends, does it?