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.
Ok... clearly sarcasm, and you clearly realizes Macs aren't impervious to this and making fun of people who beleive macs are immune... but I can't decide whether or not the you realize this particular vulnerability actually does affect OS X.
... 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.
Ok... clearly sarcasm, and you clearly realizes Macs aren't impervious to this and making fun of people who beleive macs are immune... but I can't decide whether or not the you realize this particular vulnerability actually does affect OS X.
Oh, he knows it affects Macs; he just said you don't read about things like this on a Mac -- the reality distortion field and all that, living on in the actual products :)
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.)
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.
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
Non-sequitur much?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
When there is real malware out in the wild causing millions of systems to be breached, then Linux will be "as secure as Windows". Until then, it's just ranting of trolls repeating well refuted ideas and conflating everyone else's mere bugs with actually malware.
A Pirate and a Puritan look the same on a balance sheet.
Just to balance the slanted sensationalism a bit.
And maybe I should have said: "Vulnerabilities Found (without Seeking) In MS Windows".
.
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.