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.
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.
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.