But there's a catch: on a good majority of modern Linux systems, /bin/sh is actually a symlink to /bin/bash!
-
This sort of depends on the one's definition of "good majority". For some years now, on debian and derivatives (including *buntus), /bin/sh has linked to dash, not bash -
Me too... meanwhile, Apple users were still waiting for a patch...Originally posted by GreyGeek View Post
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.Nothing like a sensational headline ...
However, it could be a major headache for Linux webservers that allow unauthenticated access to CGI BASH scripts.
It seems unlikely that they did, but it probably wouldn't be that difficult to do now that the bug is public, it's easier to understand than heartbleed at least! All those neglected servers will make a great botnet for someone.Despite the fact that Bash has been around for decades, I doubt that a script kiddie could have exploited it. Professional hacker?Comment
-
That is the big fear, and it is a serious one that went deeper than I originally thought when I read the USN notification. Going deeper into the CVE and all the picture is much more complicated, and because of Bash's extensive use though out Linux, more serious than I originally thought. There have been six major vulnerabilities since Linux was started in 1992 and this one may become the seventh and most serious. I'd wager that the script kiddies are out in force testing for holes right now, but the real threat will be the professional hackers attacking Linux servers running Apache and such. It might cause a rise in the use of Python scripts to replace Bash scripts, which wouldn't bother me ... Python is a great language & tool.Originally posted by Feathers McGraw View Post"A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.Comment
-
There are some good comments on this /. article:
http://apple.slashdot.org/story/14/0...be-in-the-wild
What I didn't realise at first was that your CGI script doesn't even have to be BASH to be vulnerable, according to the comments (paraphrasing) it could be anything that makes a system call, because that system call uses BASH to run in (if /bin/sh is BASH EDIT: I think the Debian/Ubuntu default shell at /bin/sh is DASH not BASH, which is lucky... I've logged out now though so I can't check. Regardless, there's a whole lot of Linux out there using BASH...).
Something in there about DHCP being vulnerable, too, because it calls shell scripts and passes them untrusted environment variables, so a malicious DHCP server could attack clients this way.
I'm trying to work out if awstats, which is a perl CGI script, can be exploited like this...
I bet Steve is going to be busy for the next couple of days!Last edited by Feathers McGraw; Sep 25, 2014, 03:39 PM.Comment
-
That's the kind of info that I haven't kept up on since I stopped following Linux below the KDE level. I was't aware that "dash" replaced "bash". I did a "man bash" and got the usual manual. I did "man sh" (because I've seen a lot of 'sh' commands) and got the dash manual, which is also what I got when I did "man dash".Originally posted by kubicle View Post
Learn something every day.
EDIT:
Checked to see which were executables and which were links to executables.
Code:$ whereis bash bash: /bin/bash /etc/bash.bashrc /usr/share/man/man1/bash.1.gz $ whereis dash dash: /bin/dash /usr/share/man/man1/dash.1.gz $ whereis sh sh: /bin/sh.distrib /bin/sh /usr/share/man/man1/sh.1.gz $ vdir /bin/bash -rwxr-xr-x 1 root root 1017016 Sep 25 20:45 /bin/bash $ vdir /bin/dash -rwxr-xr-x 1 root root 121272 Feb 19 2014 /bin/dash $ vdir /bin/sh lrwxrwxrwx 1 root root 4 Feb 19 2014 [B]/bin/sh -> dash[/B]
Last edited by GreyGeek; Sep 26, 2014, 07:11 AM."A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.Comment
-
I don't know how I did it, but i totally missed the posts on this page before commenting last night... sorry for repeating information!Comment
-
That change was easy to miss, as the default login shells for users are still bash (I prefer zsh myself), dash just replaced bash as the default sh shell (mostly used for non-interactive shells...and system calls).Originally posted by GreyGeek View Post
Bash is more rich in features (mostly useful only in interactive shells) but slower (doesn't really matter in interactive shells where the bottom neck for speed sits in front of the keyboard)...dash is leaner (faster) but still POSIX compatible (so it'll work fine as the default sh).Comment
-
Linux-based routers are also be affected by this bug, as explained in this article:
http://www.symantec.com/connect/blog...-vulnerabilityComment
-
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).Originally posted by verndog View PostComment
-
-
EdgeRouter uses bash . Their discussing it here:
http://community.ubnt.com/t5/EdgeMAX...1024523/page/3Comment
-
True. But, for those routers which have DD-WRT firmware installed, which uses BusyBox, not Bash, there are no problems.Originally posted by verndog View PostLast edited by GreyGeek; Sep 26, 2014, 06:35 PM."A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
– John F. Kennedy, February 26, 1962.Comment
-
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.Originally posted by TWPonKubuntu View Post
As discussed in the thread, yes... /bin/sh points to /bin/dash. But the login shell is /bin/bash.Originally posted by kubicle View Post
How to check your shell:
Code:steve@t520:~$ [B]ps -p $$[/B] PID TTY TIME CMD 18811 pts/1 00:00:00 bash
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.Originally posted by Feathers McGraw View Post
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.
Exploit code is already in the wild.Originally posted by GreyGeek View Post
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.Originally posted by Feathers McGraw View Post
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>Last edited by SteveRiley; Sep 26, 2014, 11:57 PM.Comment
-
Wanna see how widespread Bash is Ubuntu scripts? Take a look!
Code: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
Code:steve@t520:~$ [B]grep -R '#!/bin/bash' /sbin/*[/B] /sbin/dhclient-script:#!/bin/bash /sbin/ip6tables-apply:#!/bin/bash /sbin/iptables-apply:#!/bin/bash
Code: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
Code: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
Comment
-
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)Originally posted by SteveRiley View Post
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)Originally posted by SteveRiley View Post
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)Originally posted by SteveRiley View Post
--- 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.
Agreed, that was ridiculous.Originally posted by SteveRiley View PostLast edited by kubicle; Sep 27, 2014, 01:10 AM.Comment
Comment