from the he-who-does-not-learn-from-history dept.
David Wheeler has a nice write-up of the many aspects of the shellshock vulnerability in Bash, including a timeline of events and commentary on how to prevent vulnerabilities like shellshock in the future.
He even provides a quick test to see if your shell is still susceptible to shellshock:
To determine if a system is vulnerable to shellshock, run the following refined test on a Unix-like system command line (this should work on any Bourne or C shell):
env foo='() { echo not patched; }' bash -c foo
This will reply “bash: foo: command not found” on a repaired system, while a vulnerable system will typically reply “not patched” instead. The initial “env” can be omitted when typing the command into a POSIX/Bourne shell (including bash, dash, and ash).
The write-up shows that several mis-identifications of the problem were communicated, as well as how multiple solutions were constructed—thanks to the code being open-source.
He also presents a similar type of defect under Microsoft Windows where, in a CMD.EXE window, issuing these commands:
set foo=bar^&ping -n 1 localhost echo %foo%
will not only display the value of the "foo" environment variable, it will also cause a ping command to be executed.
[Update: fixed formatting of code sample.]
(Score: 0) by Anonymous Coward on Saturday October 11 2014, @01:23PM
All software has bugs. But here we have bugs in bash, one of the most widely used pieces of open source software, that went undetected for decades! These are the kind of bugs that, according to the Cathedral and the Bazaar model, should have been detected by the many, many eyes supposedly looking at the code.
But if that didn't happen in the case of widely used and mature software like bash, it clearly must not be happening when it comes to immature, new software like systemd.
So I need to ask, why are so many Linux distros rushing to include the unproven systemd code into their distros? Are they properly vetting this code? Is it being suitably reviewed?
Systemd isn't just any software. It may even be considered more important than bash was! Systemd is the init system, it's the logging system, it manages logins, it manages the network, it will allegedly provide the console soon, among many other things.
There's only one option that I can see: avoid using systemd until it's proven technology.
(Score: 0) by Anonymous Coward on Saturday October 11 2014, @02:17PM
You learned to be a loudmouth during the great Fuck Slashdot Beta war, but your autism persists and deepens.
There's only one cure. It's self-inflicted.
(Score: 0) by Anonymous Coward on Saturday October 11 2014, @02:49PM
How do you figure that? Autism causes systemd. Systemd doesn't cause autism. Systemd causes anger, rage, and sadness.
(Score: 0) by Anonymous Coward on Saturday October 11 2014, @03:01PM
is this the "Bunch of tough guys that post as A.C" thread? Finally a place i can sound cool. Fuck systemd and beta.
(Score: 1, Insightful) by Anonymous Coward on Saturday October 11 2014, @03:07PM
Silly boy, this isn't about being tough. This is about saving one of the greatest open source projects to have ever existed: Debian. We were quiet when these kind of people killed Firefox. We were quiet when they killed GNOME. But we damn well won't sit here quietly while they try to kill Debian! If our voices aren't heard, then we will move to FreeBSD.
(Score: 2) by kaszz on Saturday October 11 2014, @03:45PM
Don't worry. They will infest FreeBSD too within time.. And make compatibility with software designed for a systemd environment a pain.
(Score: 2) by kaszz on Saturday October 11 2014, @03:21PM
Just like heartbleed, GnuTLS bug [gnutls.org] etc are bugs that won't be caught because there's no problem solving itch to be had by looking for them. It's a bit like astronomy and science. You look openly to explore and find things you didn't think of. While the software people are more tinkers and solvers. The second factor is that there's a lot of people that understand programming. Less so that understand the complex algorithms at play in encryption, signal processing, debugging math software like Octave etc.
As for systemd. One can get the feeling that Redhat has backroom dealings with listening organizations to provide opportunities for zero day exploits or just plainly are in bed with Microsoft in a scenario like the SCO Group in 2004. Or just plainly to make systems complex enough such that RedHat can offer support and systemd certification. Or just plainly letting brawling people take too much space. New software is only better if it is better, not because it's new. Another scenario is where it's more important to make things easy than to make them without vurnabilities takes over.
Intelligent people with wisdom identifies pitfalls and avoids them. The rest often runs until there is a crisis to teach them the right path.
(Score: 2) by tynin on Saturday October 11 2014, @01:47PM
C:\Users\tynin>set foo=bar^&ping -n 1 localhost echo %foo%
'amp' is not recognized as an internal or external command,
operable program or batch file.
Windows 7 64bit
(Score: 1, Informative) by Anonymous Coward on Saturday October 11 2014, @01:54PM
Did you try getting rid of the "amp;" part? That HTML entity crap probably should not be there!
(Score: 3, Informative) by maxwell demon on Saturday October 11 2014, @01:58PM
The comment processing already did it for him, so he probably just needs top copy/paste from his own comment ;-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by tynin on Saturday October 11 2014, @02:11PM
Thanks, getting closer :)
C:\Users\tynin>set foo=google.com^&;ping -n 1 localhost echo %foo%
Bad parameter echo.
(Score: 3, Informative) by tynin on Saturday October 11 2014, @02:20PM
Ah, I see what it is doing now. foo contains everything needed with the ^ escaping the pipeline. Once it is set, then echoing the var will execute it. I need more coffee... :)
C:\Users\tynin>set foo=bar^&ping -n 1 google.com
C:\Users\tynin>echo %foo%
bar
Pinging google.com [74.125.229.168] with 32 bytes of data:
Request timed out.
Ping statistics for 74.125.229.168:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
Ping statistics for ::1:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
(Score: 1) by martyb on Saturday October 11 2014, @03:30PM
Mea culpa. Please accept my apologies for the corrupted code sample. We have been dealing with some issues with how the site escapes various characters into character entities, and I used the wrong HTML elements to bracket the code sample. The story has been updated.
You might be interested in this article: Command-injection vulnerability for COMMAND-Shell Scripts [thesecurityfactory.be]. I highly recommend reading the *entire* article. It provides samples of different ways to make the display or use of environment variables cause one or more commands to be executed.
Wit is intellect, dancing.
(Score: 2) by tynin on Saturday October 11 2014, @02:05PM
Thanks for the amp reminder, I glossed over that. However nothing gets returned when I run them. I don't know how to do the bash equivalent of a echo $? to see the exit status. Individually I can ping any of them. Fetching wireshark now to see if these icmp echo requests are doing the needful and just not outputting to the terminal due to how this is constructed.
C:\Users\tynin>set foo=bar;ping -n 1 localhost echo %foo%
C:\Users\tynin>set foo=google.com;ping -n 1 localhost echo %foo%
C:\Users\tynin>set foo=10.1.1.254;ping -n 1 localhost echo %foo%
C:\Users\tynin>set foo=10.1.1.254;ping -n 1 127.0.0.1 echo %foo%
(Score: 1) by Coniptor on Saturday October 11 2014, @05:27PM
echo $? is how to echo/print the bash exit status.
To get the cmd.exe/command.com output it would be echo %errorlevel%.
(Score: 2) by tynin on Saturday October 11 2014, @06:30PM
Thanks!
(Score: 0) by Anonymous Coward on Saturday October 11 2014, @08:44PM
echo %foo%
goes on its own line
(Score: 0) by Anonymous Coward on Saturday October 11 2014, @01:55PM
Use the commands in the article, the summary corrupted them. And they did work on my Windows 7 64 bit system. Also all the various bash implementations on my Windows system distributed with things like Cygwin, MinGW and Git are all vulnerable to Shellshock as well. Yay for cross platform compatibility.
(Score: -1, Troll) by Anonymous Coward on Saturday October 11 2014, @03:01PM
This kind of bug can't happen when using C or C++ or Java or C# or any real programming language.
This kind of a bug only happens when using dynamic languages like bash, Ruby, Perl or JavaScript, where code in strings can be executed on the fly.
(Score: 0) by Anonymous Coward on Saturday October 11 2014, @06:38PM
So NO! to $anything because $anything can be used to murder innocents.
Blaming tools for human error is counter productive at best.
(Score: 2, Informative) by Anonymous Coward on Saturday October 11 2014, @07:18PM
if you were serious...type man 3 system. oooo "code in strings can be executed on the fly." that's this very bug, waiting for you to call it from stdlib.
in other words, you have no idea what you're talking about.
(Score: -1, Troll) by Anonymous Coward on Saturday October 11 2014, @11:09PM
Why the fuck is the parent's dumbass comment modded up? It's fucking idiotic.
You have to go to great lengths to execute arbitrary C or C++ code using system(). Fuck, you have to even manually call system() in the first place, and modern compilers warn about its use.
Fuck, all it took with bash was setting and using an environment variable's value! Only somebody as fucking retarded as the parent wouldn't see the difference here.
Mod the parent down. It's full of shit, and it's dumb as rocks.
(Score: 2) by PizzaRollPlinkett on Saturday October 11 2014, @04:08PM
Do we know yet how pervasively this bash bug was exploited? How many remote access exploits have there been? One server in ten? One in a million? One in a trillion? I can't get a mental picture of how pervasively this bug has been exploited.
I can't wrap my mind around the idea that much critical Internet infrastructure depends on bash. Are there really a lot of CGI programs (which don't sanitize their input) being used on the Internet today? Were there ever? I used to see trivial CGI examples in bash, in books and tutorials, but I just assumed that anyone who actually wrote a CGI program would use Perl. For better performance if nothing else. And even old legacy web stuff is usually not CGI, but something like ColdFusion or original ASP. How many web servers are even set up to run CGI?
How much should we care about shell security? Has anyone ever expected shells to be secure? Compared to, say, the daily parade of credit card data breaches, is bash security an important issue? Or are people magnifying this issue because it's a slow news period?
(E-mail me if you want a pizza roll!)
(Score: 3, Informative) by Foobar Bazbot on Saturday October 11 2014, @05:15PM
I don't have numbers either, but AIUI it goes much farther than a putative real-world CGI service implemented directly in bash. (Which I'm with you on. Perl, sure. Maybe ruby or python, if that's your thing. Personally, I could see doing it with awk, because dammit, I like awk. But bash? WTF would ever make you do that?)
The point is, once an attacker puts the exploit in your CGI script's environment as HTTP_FOO, it not only applies to the CGI script itself, but is commonly inherited along with the rest of the environment by child processes. If the CGI script or any child process eventually executes /bin/bash (or /bin/sh on many systems), whether explicitly or implicitly, you get bit. In C terms, I mean by "explicitly" something like:
and by "implicitly" something like:
or
I'm not familiar with perl's facilities for executing external commands, but I assume that, like many languages, it has both system()-like and exec()-like facilities. Even if not, or if your code only uses the exec()-like version, it may implicitly spawn a shell by execing a shell script, and of course any program it does call may also start a shell implicitly or explicitly.
(Score: 3, Informative) by maxwell demon on Saturday October 11 2014, @07:41PM
However, system invokes /bin/sh which need not be bash (and at least on Debian-derived systems is not bash). And a shell script, unless it explicitly requests bash in the shebang line, will also be executed using /bin/sh.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by fnj on Sunday October 12 2014, @06:38AM
(Score: 2) by choose another one on Saturday October 11 2014, @10:01PM
It goes further than CGI as well. The unix way means implementing services as pipelines of lots of different programs, and environment variables pass all the way through. Any program in the pipeline may be a shell script or may use system() etc. Often shell scripts are part of the pipeline specifically to allow user customizability.
Think ".qmail" for instance (man qmail-command). In fact several (most) mail servers are vulnerable. Just as one example, other services are vulnerable too.
(Score: 2) by fnj on Sunday October 12 2014, @06:41AM
(Score: 2) by chromas on Sunday October 12 2014, @09:32AM
SedBot weeps in the corner.
And think of all those init scripts! So you see? Systemd was trying to save us all along!
(Score: 2) by francois.barbier on Monday October 13 2014, @01:32PM
Here is the code of the shell script it tries to run: http://pastebin.com/6z9gfdSx [pastebin.com]