Slashdot Mirror
Vulnerabilities Found (and Sought) In More Command-Line Tools
itwbennett writes The critical Shellshock vulnerabilities found last month in the Bash Unix shell have motivated security researchers to search for similar flaws in old, but widely used, command-line utilities. Two remote command execution vulnerabilities were patched this week in the popular wget download agent and tnftp client for Unix-like systems [also mentioned here]. This comes after a remote code execution vulnerability was found last week in a library used by strings, objdump, readelf and other command-line tools.
hopefully any remaining bugs will be found and we end up with better products
From one of the referenced articles:
Tnftp is a cross-platform port of the original BSD FTP client. It is the default FTP client in NetBSD, FreeBSD, DragonFly BSD and Mac OS X, but it is also available in many Linux distributions.
The tnftp package shipped with OpenBSD is not vulnerable due to some changes made to the code some time ago
It's almost like the OpenBSD team knows what they're doing when it comes to security.
I don't know if I'm being paranoid, but I'm pretty sure there are backdoors in every major open source project : gcc, the linux kernel, ssh, gpg and bash to name a few. :-/
They've been either actively introduced by NSA/FSB/... or found and jealously kept secrets.
It's not like recent history has proven this theory wrong.
... to the masses of sarcastic "I though Open Source was more secure!" crowd: in an Open Source forum, when vulnerabilities are found, they are patched. Since it's a public forum, the vulnerabilities are disclosed, and patches / updates made available. The poor, sorry state of the first cut gets rapidly and openly improved.
With closed source, the vulnerabilities merely stay hidden and undisclosed, and you have no ability to know about it, or fix it yourself. the poor, sorry state of the first cut never improves. Yes, there are some cultures that take security seriously. You have no way of knowing.
This, right here, is what "more secure" looks like: public notification of the vulnerabilities and patches to distribute.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
But they can write to ~/.bash_profile and equiv to add ~/.../evilbin/ to their path on next login (and ping a C&C, add an ssh key to authorized hosts, etc.)
In Open Source vernacular, we call that becoming more and more secure :-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
What the hell is wrong with the title exactly? Shellshock made people realize that open source should be reviewed, especially in things that haven't changed much lately.
With that approach, they found a few problems, patched them, and continue to look for more. It's not well written, but that's expected.
Defend.
While surely there are serious bugs that are found, shellshock is not one on my list of "serious bugs". If you would have picked a different target, I may have taken less issue with your statement. Every exploit of "shellshock" requires either A) access to the system. or B) poor system administration/development (which in essence loops back to A).
Let's see how this is actually exploited from the same Wiki page.
CGI-based web server
If the request handler is a Bash script, or if it executes one for example using the system(3) call, Bash will receive the environment variables passed by the server and will process them as described above.
OpenSSH server
OpenSSH has a "ForceCommand" feature, where a fixed command is executed when the user logs in, instead of just running
DHCP servers
A malicious DHCP server could provide, in one of these options, a string crafted to execute code on a vulnerable workstation or laptop.
QMail server
Depending on the specific system configuration, a qmail mail server can pass external input through to Bash in a way that could exploit a vulnerable version
I added emphasis and snipped the quotes to the relevant portions, but you can read the whole Wiki if you have doubts.
As I stated in my opening, surely exploits exist but Shellshock was more noise than anything else. Yup it was a bug, but having it exposed to the Internet was not a Bash problem in and of itself. Shellshock was easy to avoid simply by using "Best Practices". If you are running your sites on a bunch of Bash CGI scripts, we knew that shell based CGI was a bad idea in the 90s. If you have a DHCP client attaching to unknown servers, shame on you. If you have arbitrary users with shell access to your hosts.. well, I guess it's possible that someone has this in their business model somewhere but it's surely not very common.
We manage many tens of thousands of websites, and even with "vulnerable bash" we could not exploit the bug unless we were logged in to a host. We tried really really hard to exploit it (at least 5 days of testing since they kept releasing patches), but we follow best practices.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
All the eyes ... they do nothing! Arrrrrg.
Linus's Law worked better back in the day when the projects were smaller, but these days most people do not have the time or inclination to go through hundreds of thousands of lines of source code. You really want to be paid for that kind of work, in other words professional code audits.