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
Linux is getting too popular and too targeted!
I got to the chocolate box before you, that's why the hard ones have teeth marks.
All the eyes ... they do nothing! Arrrrrg.
I have busiest weeks patching my systems. Today I have already spent 16 hours ,moving virtual machines , patching , rebooting....
Still support tasks keep piling up.. Ignorance is bliss, keep your vulnerabilities for yourself.
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.
So how many of these come down to simple laziness when the code was originally written and how many are simple a post-creation artefact caused by the host system being updated with newer technologies?
captcha:apiaries
You just don't read about things like this on a Mac, that's why everyone you see who uses a Mac is a Dr or someone else super intelligent. They just work!
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.
Wget did not have two remote command execution vulnerabilities. It had one vulnerability, which allowed a malicious FTP server (but not an HTTP server) to overwrite any file the calling user could write. This is not necessarily a remote command execution vulnerability, since many users can't write to any directories in their $PATH.
... 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.
I used to spend a ton of time doing nothing but scrutinizing source code. I used to not install things based on what I saw in the code, pretty commonly. I simply lack the time today, but wish I could make time for this. I have turned into a minimalist because I don't trust everything, which 15 years ago I thought was crazy.
That aside, at least with OpenSource I could try and make time. The source is there for scrutiny, we just need more eyes watching for problems. Compare this to closed source (as you stated) and you can't. What you may perceive as the OS looking to download a patch could easily be that OS uploading your passwords and credit card data. In fact go ahead and run one of those closed source OSes and dump all the traffic for a perfectly idle box.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
... 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.
The key words here being "when they are found."
Shellshock makes a perfect farce of the Open Source mantra "With many eyes all bugs are shallow."
Analysis of the source code history of Bash shows the [Shellshock] vulnerabilities had existed since version 1.03 of Bash released in September 1989.
25 years ago. Shellshock (software bug)
The name itself is an acronym, a pun, and a description. As an acronym, it stands for Bourne-again shell, referring to its objective as a free replacement for the Bourne shell. As a pun, it expressed that objective in a phrase that sounds similar to born again, a term for spiritual rebirth. The name is also descriptive of what it did, bashing together the features of sh, csh, and ksh.
Stallman and the Free Software Foundation (FSF) considered a free shell that could run existing sh scripts so strategic to a completely free system built from BSD and GNU code that this was one of the few projects they funded themselves.
it has been distributed widely as the shell for the GNU operating system and as a default shell on Linux and Mac OS X. It has been ported to Microsoft Windows and distributed with Cygwin and MinGW, to DOS by the DJGPP project, to Novell NetWare and to Android via various terminal emulation applications.
Bash (Unix shell)
Just to balance the slanted sensationalism a bit.
And maybe I should have said: "Vulnerabilities Found (without Seeking) In MS Windows".
.
This is a local code execution vulnerability. Remove vulnerabilities do not need help to get onto the machine, that is the very point of the name.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Fix can be downloaded here.
Shellshock makes a perfect farce of the Open Source mantra "With many eyes all bugs are shallow." by westlake (615356) on Thursday October 30, 2014 @07:36PM (#48274451)
Of course you'll be downmoderated for telling the truth of things around here on slashdot for it. Yes, you can expect that since their outright bs and lies are now and have continually been exposed in the very crap it is by your words. You're no first either. I don't think the moronic Open SORES crew around here "gets it" that when you tell outrageous outright lies you'll get caught in the act (as they have been repeatedly not just in your case, but many others over time ala "Linux = Secure, Windows != Secure" type crap they spouted here for years to a decade and then some when ANDROID, of all things, shows just how "secure" Linux is once it finally got a foothold as top most used OS on another hardware platform (and they only reason it got that was it costs nothing keeping phone handset costs lower, and that only) since Android shows security issues and malware galore every day almost for nearly a decade now).
A person should not be able to gain access to a terminal remotely to exploit local command line applications. How do they gain access to remotely execute them? I guess that is the guy with a smoking gun as they say in the western united states.