A new BASH bug?

[Feathers McGraw]

OK I'll bite... how would we know if there are old vulnerabilities in Windows without being able to see the code? I guess you've seen it, but it's just a black box to the rest of us.

I guess you can say there has never been a vulnerability discovered and published, but it must be more difficult to find bugs when you can't read the code!

I do agree with your point about comparisons being a bit of a waste of time. I wonder if the BASH vulnerability was discovered because someone thought to have a rummage through some old code after heartbleed was discovered... hopefully all of this will result in more code audits by professionals and hobbyists alike, there are bound to be more bugs to find. Gotta catch 'em all

[SteveRiley]

Be glad this isn't Windoze...

Why, because Windows, while having its own share of vulnerabilities that have taken a few years to fix, never had one so old as this?

Or because Microsoft also has the capability of releasing emergency out-of-band patches for remote-access vulnerabilities that have exploit code in the wild?

I fail to understand why people still have the urge to make security comparisons. All software has bugs. Some bugs enable malicious behavior. What matters is that the industry as a whole continue to improve code quality, redouble its efforts at examining legacy code, and remain vigilant against adversaries.

[TWPonKubuntu]

It will end when software becomes perfect. But since software is written by humans, and humans can never be perfect, we will never have flawless software.

THE HORROR! What ever will we do? I know, let's ask the government to step in. No, wait, that didn't work last time either. I guess we'll just have to grin and bear it...

Be glad this isn't Windoze...

[whatthefunk]

Another bash upgrade today. Thats the third one so far.

[SteveRiley]

dhcp is one of the things that seems vulnerable (but if you're connecting to a malicious dhcp daemon [on an insecure network], you're likely in a world of hurt already)

Ever set up a DHCP server on the free wireless network in, say, an airport?

[Snowhog]

Specifically, the test specifies:

There is an easy test to determine if a Linux or Unix system is vulnerable. To check your system, from a command line, type:

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

If the system is vulnerable, the output will be:

vulnerable
 this is a test

An unaffected (or patched) system will output:

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

There was another bash update today. Running the test above now shows:

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

Won't be getting bashed by bash exploit here.

[MoonRise]

It will end when software becomes perfect. But since software is written by humans, and humans can never be perfect, we will never have flawless software.

---

Thank You, Thank You, Thank You!!!! You know how many times I try to tell people that and they still think software is or should be perfect?!!!!

[GreyGeek]

I noticed another bash update this morning. Interestingly, the BlueTooth firmware was also updated.

As I said before, there will probably be several updates before this bash bug is finally bashed.

I was somewhat miffed at the reporting of this bug because I interpreted the CVE entry to say that the bug was discovered on 9/9/14 but not reported until 9/24/14. It is long been a mantra in Linux that bugs are reported ASAP, along with proof of concept code, to allow users to adjust their system and/or behavior so as to avoid being affected by the bug. It is well known that proprietary systems frequently keep bugs secret until, for what ever reason, they announce the bug and the patch on the same day, then claim "zero day" fixes. Meanwhile, they sit on other bugs for months or years, or even tell customers that if they want a bug fixed then buy the next version of the OS. Nice. Using their own insecurities as a profit center. I was miffed because I thought RedHat was doing the same thing. Rechecking the CVE I noticed some fine print:

20140909	Disclaimer: The entry creation date may reflect when the CVE-ID was allocated or reserved, and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed, or updated in CVE.

So, the bash bug may not have been or was NOT discovered on the 9th and announced on the 24th like I had originally concluded. it was an ASAP announcement.

[kubicle]

As discussed in the thread, yes... /bin/sh points to /bin/dash. But the login shell is /bin/bash.

but system calls don't go through login shells, which makes systems that don't use bash as /bin/sh less vulnerable. (not immune, but harder to exploit remotely)

As Jerry mentions in a later post, Bash is everywhere, and thus this bug is a major problem. Many scrips and utilities call Bash -- the tell-tale sign is that the first line is #!/bin/bash. For example, dhclient uses Bash as you mention in a later post here. Nothing like asking for an IP address and getting your system p0wned instead.

dhcp is one of the things that seems vulnerable (but if you're connecting to a malicious dhcp daemon [on an insecure network], you're likely in a world of hurt already)

Wanna see how widespread Bash is Ubuntu scripts? Take a look!

Yeah, there are things that explicitly call bash (most things do actually call /bin/sh), but most of those aren't remotely exploitable as you'd have to inject malicious code "before" bash gets called. (and you can't do that remotely with most of these)

--- I'm not saying the bug isn't serious, it certainly is...and everyone should upgrade their bash installation...just that not all linuxes are equally vulnerable.

<soapbox>
I'm rather miffed by the Free Software Foundation's response. The license type (GPL 3) had nothing do with how fast patches could be produced. Their response continues, echoing the feel-goodiness that only open source allows everyone to see the code and fix vulnerabilities. OK, then why did this one go undetected for 25 years? "Open source" and "more secure" are not synonyms. Neither are they antonyms, even. I'd say they're orthogonal.
</soapbox>

Agreed, that was ridiculous.

[SteveRiley]

Wanna see how widespread Bash is Ubuntu scripts? Take a look!

steve@t520:~$ [B]grep -R '#!/bin/bash' /bin/*[/B]
/bin/gunzip:#!/bin/bash
/bin/gzexe:#!/bin/bash
/bin/gzexe:# WARNING: the first line of this file must be either : or #!/bin/bash
/bin/gzexe:# On Ultrix, /bin/bash is too buggy, change the first line to: #!/bin/bash5
/bin/gzexe:#!/bin/bash
/bin/uncompress:#!/bin/bash
/bin/zcat:#!/bin/bash
/bin/zcmp:#!/bin/bash
/bin/zdiff:#!/bin/bash
/bin/zegrep:#!/bin/bash
/bin/zfgrep:#!/bin/bash
/bin/zforce:#!/bin/bash
/bin/zgrep:#!/bin/bash
/bin/zless:#!/bin/bash
/bin/zmore:#!/bin/bash
/bin/znew:#!/bin/bash

steve@t520:~$ [B]grep -R '#!/bin/bash' /sbin/*[/B]
/sbin/dhclient-script:#!/bin/bash
/sbin/ip6tables-apply:#!/bin/bash
/sbin/iptables-apply:#!/bin/bash

steve@t520:~$ [B]grep -R '#!/bin/bash' /usr/bin/*[/B]
/usr/bin/aptitude-create-state-bundle:#!/bin/bash
/usr/bin/aptitude-run-state-bundle:#!/bin/bash
/usr/bin/byobu-ugraph:#!/bin/bash
/usr/bin/byobu-ulevel:#!/bin/bash
/usr/bin/cautious-launcher:#!/bin/bash
/usr/bin/cpupower:#!/bin/bash
/usr/bin/editdiff:#!/bin/bash
/usr/bin/equivs-control:#!/bin/bash
/usr/bin/fakeroot:#!/bin/bash
/usr/bin/fakeroot-sysv:#!/bin/bash
/usr/bin/fakeroot-tcp:#!/bin/bash
Binary file /usr/bin/fig2dev matches
/usr/bin/init-checkconf:#!/bin/bash
/usr/bin/itweb-settings:#!/bin/bash
/usr/bin/javaws:#!/bin/bash
/usr/bin/lcf:#!/bin/bash
/usr/bin/lzcmp:#!/bin/bash
/usr/bin/lzdiff:#!/bin/bash
/usr/bin/lzegrep:#!/bin/bash
/usr/bin/lzfgrep:#!/bin/bash
/usr/bin/lzgrep:#!/bin/bash
/usr/bin/lzless:#!/bin/bash
/usr/bin/lzmore:#!/bin/bash
/usr/bin/perf:#!/bin/bash
/usr/bin/pnmindex:#!/bin/bash
/usr/bin/policyeditor:#!/bin/bash
/usr/bin/ppmquantall:#!/bin/bash
/usr/bin/turbostat:#!/bin/bash
/usr/bin/tzselect:#!/bin/bash
/usr/bin/ucf:#!/bin/bash
/usr/bin/usb-devices:#!/bin/bash
/usr/bin/X11/cautious-launcher:#!/bin/bash
/usr/bin/X11/lcf:#!/bin/bash
/usr/bin/X11/ucf:#!/bin/bash
/usr/bin/X11/usb-devices:#!/bin/bash
/usr/bin/X11/aptitude-create-state-bundle:#!/bin/bash
/usr/bin/X11/aptitude-run-state-bundle:#!/bin/bash
/usr/bin/X11/xzmore:#!/bin/bash
/usr/bin/X11/xzless:#!/bin/bash
/usr/bin/X11/xzgrep:#!/bin/bash
/usr/bin/X11/xzdiff:#!/bin/bash
/usr/bin/X11/xzfgrep:#!/bin/bash
/usr/bin/X11/xzegrep:#!/bin/bash
/usr/bin/X11/xzcmp:#!/bin/bash
/usr/bin/X11/lzmore:#!/bin/bash
/usr/bin/X11/lzless:#!/bin/bash
/usr/bin/X11/lzdiff:#!/bin/bash
/usr/bin/X11/lzcmp:#!/bin/bash
/usr/bin/X11/lzgrep:#!/bin/bash
/usr/bin/X11/lzegrep:#!/bin/bash
/usr/bin/X11/lzfgrep:#!/bin/bash
/usr/bin/X11/fakeroot-sysv:#!/bin/bash
/usr/bin/X11/fakeroot-tcp:#!/bin/bash
/usr/bin/X11/fakeroot:#!/bin/bash
/usr/bin/X11/equivs-control:#!/bin/bash
grep: warning: /usr/bin/X11/X11: recursive directory loop
/usr/bin/X11/editdiff:#!/bin/bash
/usr/bin/X11/ppmquantall:#!/bin/bash
/usr/bin/X11/pnmindex:#!/bin/bash
/usr/bin/X11/policyeditor:#!/bin/bash
/usr/bin/X11/javaws:#!/bin/bash
/usr/bin/X11/itweb-settings:#!/bin/bash
/usr/bin/X11/init-checkconf:#!/bin/bash
/usr/bin/X11/byobu-ulevel:#!/bin/bash
/usr/bin/X11/byobu-ugraph:#!/bin/bash
Binary file /usr/bin/X11/fig2dev matches
/usr/bin/X11/xmlto:#!/bin/bash
/usr/bin/X11/tzselect:#!/bin/bash
/usr/bin/X11/turbostat:#!/bin/bash
/usr/bin/X11/cpupower:#!/bin/bash
/usr/bin/X11/x86_energy_perf_policy:#!/bin/bash
/usr/bin/X11/perf:#!/bin/bash
/usr/bin/x86_energy_perf_policy:#!/bin/bash
/usr/bin/xmlto:#!/bin/bash
/usr/bin/xzcmp:#!/bin/bash
/usr/bin/xzdiff:#!/bin/bash
/usr/bin/xzegrep:#!/bin/bash
/usr/bin/xzfgrep:#!/bin/bash
/usr/bin/xzgrep:#!/bin/bash
/usr/bin/xzless:#!/bin/bash
/usr/bin/xzmore:#!/bin/bash

steve@t520:~$ [B]grep -R '#!/bin/bash' /usr/sbin/*[/B]
/usr/sbin/dkms:#!/bin/bash
/usr/sbin/dkms:#!/bin/bash
/usr/sbin/ip6tables-apply:#!/bin/bash
/usr/sbin/iptables-apply:#!/bin/bash
/usr/sbin/locale-gen:#!/bin/bash
/usr/sbin/make-ssl-cert:#!/bin/bash -e
/usr/sbin/mkrlconf.sh:#!/bin/bash
/usr/sbin/mvrefind.sh:#!/bin/bash
/usr/sbin/update-info-dir:#!/bin/bash

[SteveRiley]

It never ends, does it?

It will end when software becomes perfect. But since software is written by humans, and humans can never be perfect, we will never have flawless software.

---

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

As discussed in the thread, yes... /bin/sh points to /bin/dash. But the login shell is /bin/bash.

How to check your shell:

steve@t520:~$ [B]ps -p $$[/B]
  PID TTY          TIME CMD
18811 pts/1    00:00:00 bash

---

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.

As Jerry mentions in a later post, Bash is everywhere, and thus this bug is a major problem. Many scrips and utilities call Bash -- the tell-tale sign is that the first line is #!/bin/bash. For example, dhclient uses Bash as you mention in a later post here. Nothing like asking for an IP address and getting your system p0wned instead.

Basically, if you can convince a user to set an environment variable, you can hand them anything you want in that variable and Bash will happily execute it. It's a common technique for exchaning parameters. This is quite a sloppy coding bug.

---

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.

Exploit code is already in the wild.

---

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

Ahyup. Been corralling various of our engineers for details so that I can keep Riverbed KB article S24997 up-to-date. We also added a rule to our web application firewall and created a bit of code for our application delivery controller that blocks attempts to exploit servers in load-balanced pools. Neat stuff.

---

Also: Debian has issued two fixes, Ubuntu three fixes, and Redhat two. Distributions may yet find more. This Phoronix post offers some interesting ideas about how to exploit the vulnerability.

<soapbox>
I'm rather miffed by the Free Software Foundation's response. The license type (GPL 3) had nothing do with how fast patches could be produced. Their response continues, echoing the feel-goodiness that only open source allows everyone to see the code and fix vulnerabilities. OK, then why did this one go undetected for 25 years? "Open source" and "more secure" are not synonyms. Neither are they antonyms, even. I'd say they're orthogonal.
</soapbox>

[GreyGeek]

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

True. But, for those routers which have DD-WRT firmware installed, which uses BusyBox, not Bash, there are no problems.

[verndog]

EdgeRouter uses bash . Their discussing it here:
http://community.ubnt.com/t5/EdgeMAX...1024523/page/3

[MoonRise]

Device with embedded linux that uses bash as the system shell would be an extremely rare find (I haven't seen a single one).......

I can +1 that.

[kubicle]

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

Device with embedded linux that uses bash as the system shell would be an extremely rare find (I haven't seen a single one). These commonly use ash (or busybox).