SoylentNews is people
SoylentNews
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: 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.