A new BASH bug?

[verndog]

Linux-based routers are also be affected by this bug, as explained in this article:
http://www.symantec.com/connect/blog...-vulnerability

[kubicle]

That's the kind of info that I haven't kept up on since I stopped following Linux below the KDE level. I was't aware that "dash" replaced "bash". I did a "man bash" and got the usual manual. I did "man sh" (because I've seen a lot of 'sh' commands) and got the dash manual, which is also what I got when I did "man dash".

That change was easy to miss, as the default login shells for users are still bash (I prefer zsh myself), dash just replaced bash as the default sh shell (mostly used for non-interactive shells...and system calls).

Bash is more rich in features (mostly useful only in interactive shells) but slower (doesn't really matter in interactive shells where the bottom neck for speed sits in front of the keyboard)...dash is leaner (faster) but still POSIX compatible (so it'll work fine as the default sh).

[Feathers McGraw]

I don't know how I did it, but i totally missed the posts on this page before commenting last night... sorry for repeating information!

[GreyGeek]

This sort of depends on the one's definition of "good majority". For some years now, on debian and derivatives (including *buntus), /bin/sh has linked to dash, not bash

That's the kind of info that I haven't kept up on since I stopped following Linux below the KDE level. I was't aware that "dash" replaced "bash". I did a "man bash" and got the usual manual. I did "man sh" (because I've seen a lot of 'sh' commands) and got the dash manual, which is also what I got when I did "man dash".

Learn something every day.

EDIT:
Checked to see which were executables and which were links to executables.

$ whereis bash
bash: /bin/bash /etc/bash.bashrc /usr/share/man/man1/bash.1.gz
$ whereis dash
dash: /bin/dash /usr/share/man/man1/dash.1.gz
$ whereis sh
sh: /bin/sh.distrib /bin/sh /usr/share/man/man1/sh.1.gz
$ vdir /bin/bash
-rwxr-xr-x 1 root root 1017016 Sep 25 20:45 /bin/bash
$ vdir /bin/dash
-rwxr-xr-x 1 root root 121272 Feb 19  2014 /bin/dash
$ vdir /bin/sh
lrwxrwxrwx 1 root root 4 Feb 19  2014 [B]/bin/sh -> dash[/B]

[Feathers McGraw]

There are some good comments on this /. article:

http://apple.slashdot.org/story/14/0...be-in-the-wild

What I didn't realise at first was that your CGI script doesn't even have to be BASH to be vulnerable, according to the comments (paraphrasing) it could be anything that makes a system call, because that system call uses BASH to run in (if /bin/sh is BASH EDIT: I think the Debian/Ubuntu default shell at /bin/sh is DASH not BASH, which is lucky... I've logged out now though so I can't check. Regardless, there's a whole lot of Linux out there using BASH...).

Something in there about DHCP being vulnerable, too, because it calls shell scripts and passes them untrusted environment variables, so a malicious DHCP server could attack clients this way.

I'm trying to work out if awstats, which is a perl CGI script, can be exploited like this...

I bet Steve is going to be busy for the next couple of days!

[GreyGeek]

.... It seems unlikely that they did, but it probably wouldn't be that difficult to do now that the bug is public, it's easier to understand than heartbleed at least! All those neglected servers will make a great botnet for someone.

That is the big fear, and it is a serious one that went deeper than I originally thought when I read the USN notification. Going deeper into the CVE and all the picture is much more complicated, and because of Bash's extensive use though out Linux, more serious than I originally thought. There have been six major vulnerabilities since Linux was started in 1992 and this one may become the seventh and most serious. I'd wager that the script kiddies are out in force testing for holes right now, but the real threat will be the professional hackers attacking Linux servers running Apache and such. It might cause a rise in the use of Python scripts to replace Bash scripts, which wouldn't bother me ... Python is a great language & tool.

[Feathers McGraw]

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

Me too... meanwhile, Apple users were still waiting for a patch...

Nothing like a sensational headline ...

I agree... to make a good headline, many journalists have overstated the problem. Obviously this needs to be patched fully (and no doubt will be), but since most people have their own machines and I can't think of anyone who allows untrusted users to have shell access of any kind on a normal desktop, I don't think it's a big deal for desktop users.

However, it could be a major headache for Linux webservers that allow unauthenticated access to CGI BASH scripts.

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

It seems unlikely that they did, but it probably wouldn't be that difficult to do now that the bug is public, it's easier to understand than heartbleed at least! All those neglected servers will make a great botnet for someone.

[kubicle]

But there's a catch: on a good majority of modern Linux systems, /bin/sh is actually a symlink to /bin/bash!

This sort of depends on the one's definition of "good majority". For some years now, on debian and derivatives (including *buntus), /bin/sh has linked to dash, not bash

[TWPonKubuntu]

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

[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]

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.

[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 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.

[Qqmike]

Thanks Vinny -- got it!

[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