SoylentNews is people
SoylentNews
Ars reports that a new bug has been found in GNU Bash allows remote attackers to execute arbitrary code by setting the process trailing strings after function definitions in the values of environment variables.
This bug is reported to be present in RHEL (ver 4 through 7), Fedora, CentOS (ver 5 through 7), Ubuntu (ver 10.04 LTS, 12.04 LTS, and 14.04 LTS), Debian, and even OS X Mavericks.
This bug is exploitable through Apache servers with mod_cgi and mod_cgid loaded, OpenSSH, malicious DHCP servers in a compromised wireless access point through dhclient, as well as the CUPS printing system.
The Ars also includes a simple single liner that will test your setup for the newly found discovery:
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
A vulnerable system will output the following:
vulnerable
this is a test
While a patched or unaffected system outputs:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
A patch is already out, so administrators are advised to update Bash.
Editor's Update: Security Engineer Tavis Ormandy has said "The bash patch seems incomplete to me, function parsing is still brittle".
$ env X='() { (a)=>\' sh -c "echo date"; cat echo
(Score: 3, Interesting) by NotInHere on Thursday September 25 2014, @02:10AM
Back in the time bash was written, we didn't know that security holes are this important. Or nobody had in mind their software gets used in 2014. X for example had some issues with >4G buffers being exchanged. In the "who needs more than 64k" era this might have been secure, but now it isn't. New (good) software actually tries to avoid holes. really tries. And we never get most software hole-free. Most important thing is that when a hole is used, we find out about that and fix it very fast.
(Score: 3, Insightful) by bd on Thursday September 25 2014, @11:50AM
Much of the development of X was done before the morris worm in 1988, which I think was a pivotal moment in the perception of the importance of security in networked computer systems. The first release of bash was in 1989, after the morris worm, when people knew security holes are important. The core of the GNU system was subject to intense code review attention during the 1990's, when much of its development was done.
Still, I think the GNU system has one core weakness when compared to e.g. OpenBSD, which would seem to be the willingness to add complexity. GNU utilities always tend to include a large amount of features that are not strictly necessary and a lot of code neccessary to achieve broad portability. That makes code review more complex and increases the likelyhood of something incredibly stupid slipping through. Especially as the complexity of a program that a code reviewer can actually grasp is incredibly small in comparison to typical lines of code in a software project.
This mindset is not restricted to GNU of course. The transition from Apache 1 to Apache 2 being one example, sendmail, OpenSSL etc. also come to mind here. And systemd fits perfectly into this narrative. A piece of software written in an incredibly complex way for a simple task, at a highly vulnerable position in the overall operating system stack. What could possibly go wrong?