Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security Open Source

Vulnerabilities Found (and Sought) In More Command-Line Tools 87

Posted by timothy from the one-thing-at-a-time dept.
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.
This discussion has been archived. No new comments can be posted.

Vulnerabilities Found (and Sought) In More Command-Line Tools More

Vulnerabilities Found (and Sought) In More Command-Line Tools

Comments Filter:

  • great news (Score:5, Interesting)

    by Anonymous Coward on Thursday October 30, 2014 @04:58PM (#48273773)

    hopefully any remaining bugs will be found and we end up with better products

    • Agreed. Quality assurance is what open source sorely needs, and I'm glad that more focus is assigned to that area.
  • Linux is getting too popular and too targeted!

    • Re:what happened to obscurity (Score:5, Informative)

      by Zero__Kelvin ( 151819 ) on Thursday October 30, 2014 @06:07PM (#48274289) Homepage
      In Open Source vernacular, we call that becoming more and more secure :-)

    • Re: (Score:1)

      by Anonymous Coward

      These tools have nothing to do with Linux. If you run cygwin, you'll have the same issues.

      • Don't bother, I posted the same fact on the Shellshock threads and got smacked down for it. Let them remain blissfully ignorant.

  • tnftp (Score:5, Informative)

    by Anonymous Coward on Thursday October 30, 2014 @05:13PM (#48273869)

    From one of the referenced article [itworld.com]s:

    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.

    • Re:tnftp (Score:5, Insightful)

      by MrBingoBoingo ( 3481277 ) on Thursday October 30, 2014 @05:50PM (#48274161) Homepage
      Well the difference is... reading, and reading is nothing if not for rereading. A billion, thousand, or even three eyes mean nothing if they're aimed at cat videos. Instead of reineventing every API to keep it fresh a la the GNOME model, to get actual tools you have to instead make sure what you're already working with... works.

  • Laziness (Score:1)

    by Anonymous Coward

    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

  • Am I paranoid? (Score:5, Interesting)

    by BlackPignouf ( 1017012 ) on Thursday October 30, 2014 @05:18PM (#48273911)

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

    • Re:Am I paranoid? (Score:4, Insightful)

      by Anonymous Coward on Thursday October 30, 2014 @05:48PM (#48274151)

      It's not like your "theory" is falsifiable, either.

      • Re: (Score:2)

        by anagama ( 611277 )

        That's annoying. If we can't prove a piece of software is backdoor free, how can we justify trusting it with important information (medical records, financial records, legal records, secret recipes, etc. etc.)?

    • Well the way this probably works is they submit patches to be helpful. They encourage work on certain things to distract from things they already know are vulnerable. Bash had that bad behavior at a time when some people may have lobbied for it as a feature. On the other hand you have outright turds like OpenSSL which are developed by people who jsut slap shit in and avoid starvation by consulting for the Feds. The only solution is more people reading old code.

    • Re: (Score:2)

      by chgros ( 690878 )

      In case you're not feeling paranoid enough yet:
      Reflections on Trusting Trust [bell-labs.com]

    • I doubt that they're inserted intentionally. If you insert an intentional backdoor, then there's a chance that it can be traced back to you. Pretty much any nontrivial program contains bugs, and if the program is written in C then a good fraction of those are exploitable. If you've got the resources to insert intentional vulnerabilities into open source code, then you've got the resources for the lower-risk strategy of auditing and fuzzing the code to finding some existing ones to exploit.

    • Re: (Score:3)

      by tlhIngan ( 30335 )

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

      Except that shellshock dates to 1989. That's when the "feature" to export functions was added to bash per commit logs. And that predates Linux 0.1 by a couple of years, so your FBI/NSA/etc wo

  • Summary Incorrect (Score:1)

    by Anonymous Coward

    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.

    • Re: (Score:3, Informative)

      by Anonymous Coward
      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.)

  • For all the idiots (Score:5, Insightful)

    by mcrbids ( 148650 ) on Thursday October 30, 2014 @05:25PM (#48273973) Journal

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

    • Yup (Score:3)

      by s.petry ( 762400 )

      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

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

      The disclosure and fixing is definitely a good thing, but the number of vulnerabilities and the ease with which people are finding them is worrying.

      I don't think that this really disproves Linus's Law, "given enough eyeballs, all bugs are shallow". More likely I suspect that the eyeballs aren't as numerous or well distributed as we think. There's a lot of tools that have been around a really long time and may not have undergone rigorous review when they were written. Even if maintainance if fairly active (t

      • "But with Linux most contributors, be they individuals or companies, are primarily concerned with their own projects."

        Your definition of contributor is skewed. A FOSS contributor may do so in many ways. Clearly a project lead for a major project isn't going to contribute further by analyzing the ecosystem; their plate is full. There are others, also known as contributors, who do this. Other contributors administer project websites or write documentation. There is a whole wide array of types of contri

        • Re:For all the idiots (Score:4, Insightful)

          by quantaman ( 517394 ) on Thursday October 30, 2014 @06:26PM (#48274403)

          "But with Linux most contributors, be they individuals or companies, are primarily concerned with their own projects."

          Your definition of contributor is skewed. A FOSS contributor may do so in many ways. Clearly a project lead for a major project isn't going to contribute further by analyzing the ecosystem; their plate is full. There are others, also known as contributors, who do this. Other contributors administer project websites or write documentation. There is a whole wide array of types of contributors.

          That being said, clearly there are more developers than people doing security audits, and it would be nice to see more contribtors in all the other categories, actually.

          My definition of contributor didn't exclude non-coders. The point was that most contributors, except for a few individuals, are contributing with a specific goal or direction in mind. Implement feature X, support customer Y, make nicer docs, make a nicer build, etc. All of those tasks have a nice tangible outcome that is good for motivating people.

          Auditing old code for potential security vulnerabilities is hard work, it isn't fun, and it's unlikely to scratch a particular itch. Those kind of problems aren't a strength of the open source model.

          • There is no old code; only old auditors :-)

            I can assure you, when I analyze any hardware/software system I don't in any manner way shape or form categorize anything, or base any decision on the age of, and subsystem.

            I doubt I'm the only competent analyst.

            • There is no old code; only old auditors :-)

              I can assure you, when I analyze any hardware/software system I don't in any manner way shape or form categorize anything, or base any decision on the age of, and subsystem.

              I doubt I'm the only competent analyst.

              I'm not saying competent analysts can find these bugs. What I'm suggesting is that they don't have a lot of motive to look and I think this story is evidence of that. If a lot of analysts were already examining Linux and all the basic tools then why the sudden flood of bugs now?

    • Re: (Score:1)

      by Threni ( 635302 )

      Having said that, are we going to discover in a year or two's time, that for the last 20 years the NSA (and other bodies) have contributed code to every single open source project out there, and that no-one's actually bothered to check? (You need time, motivation, skills (if you're going to find anything that's not totally obviously written) etc)

      • Somebody should invent commit logs!

        • Re: (Score:1)

          by Threni ( 635302 )

          You think they'd hide something nasty then explain what they'd done in black and white?

          • No. I think I understnd how to interpret a commit log. If the commit was from a trusted source, ignore it. You have just narrowed down your search by at least 2 orders of magnitude. If you have a suspected commiter, scrutinize them. Commit logs go a very long way to taking your OMFG How will anyone analyze every change! to a pleasant rejoicing song of: Hey, it turns out we only have to review a very small subset!

    • ... 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) [wikipedia.org]

      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) [wikipedia.org]

      • Silly (Score:4, Informative)

        by s.petry ( 762400 ) on Thursday October 30, 2014 @09:37PM (#48275323)

        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.

        • If you have a DHCP client attaching to unknown servers, shame on you

          Huh? First of all, DHCP has no authentication. If I pop up on your trusted network and answer DHCP broadcast queries faster than the router, then your DHCP client will trust me. Second, you realise that that's how most operating systems are configured to work out of the box? Plug in network cable (or join WiFi network), send DHCP broadcast packet, trust the response.

          • Re: (Score:1)

            by Anonymous Coward

            If you're able to pop a rogue DHCP server on a network, then I think the IT/Security folks have bigger problems than shellshock.

          • Re: (Score:3)

            by s.petry ( 762400 )

            Huh? First of all, DHCP has no authentication.

            It may not have authentication, but it can surely be secured. Not to say your point is completely invalid, but it's not something that any business should really have to worry about because the DHCP Client does not hack the DHCP server.

            Where your point has some validity is lets say a Laptop and a traveler. Going through the airport you could, if you wanted, connect to networks other than what the airport provides. So a bad guy can set up a rogue server and hotspot that you could connect to if you selecte

            • No, because your laptop doesn't authenticate base systems either. It will try to connect to any AP that has an SSID that it recognises and (if it expects DHCP on that network, which is usually the default) send a DHCP query. And, if that AP is malicious, then you'll get the exploit code delivered to your DHCP client.

              • Re: (Score:2)

                by s.petry ( 762400 )

                You still have not demonstrated that a Client can hack a Server (and won't be able to), which as I stated means that Best Practices fixes issues for companies. If you are running DHCP, secure it! Both on the client and the server side.

                People connecting to "any" Wifi they can find should have an expectation that they are going to be hacked. In fact if I own a DHCP server as a bad guy, you have more serious problems than me getting a shell on your laptop. I can MITM every connection you make so would not

                • You're missing the point. The vulnerability is in the client, not the server. If you connect to WiFi, then you implicitly trust the WiFi access point to route your traffic. Anything unencrypted can be compromised, but your machine should be safe. With the dhcp client vulnerability, a malicious DHCP response - which can be sent by any machine on the network, not just the WiFi access point - can get a root shell on your laptop.

            • Re: (Score:2)

              by elgaard ( 81259 )

              In for example an airport you have no way of knowing if it really is the airport that provided the network, you are using.

              Even if it is a real airport network, most airport wireless networks are open and unencrypted, so anyone could run their own DHCP server on the network.

              In many airport lounges you could just go to the accesspoint and move a few cables to use your own hardware router.

              And why should you have to trust airport networks, or networks in cafes, trains, bars, etc?

              I think it is reasonable to expe

              • Re: (Score:2)

                by s.petry ( 762400 )

                So what you are telling me is that your wifi client automatically connects to any available network automatically? Okay, but if you get hacked that is not a Bash problem. My WIFI does not connect to any random network, I have to take action to connect. Get a new WIFI client or secure what you have, problem solved.

                • Re: (Score:2)

                  by elgaard ( 81259 )

                  Actually my client does not connect automatically.
                  Not that i should be a problem, except that it would keep connectiong to networks that I cannot use.

                  I am telling you that if I stay in a hotel, and I see a network named eg Free_Hotelname_network, then I connect to it and if it works I use it, even though for all I know that network could be running from the laptop of the guy in a room down the hall.

                  But I should not have care about that. It should not be necessary to trust every DHCP-server I use.

                  In the same

                  • Re: (Score:2)

                    by s.petry ( 762400 )
                    I think for the most part we agree, but I still disagree that you can't know if "Free_Hotel" WIFI is legit, since every Hotel I have been in has information in numerous places about their WIFI. Airports too, and shopping malls, etc... I could probably trap a whole mess of people in a Hotspot "Free_Airport_Porn", but anyone checking with the airport should know that this is not an Airport provided WIFI network. In fact they busted some guy just last week with a Hotspot because it had a name that included A

                    • Re: (Score:2)

                      by elgaard ( 81259 )

                      The hotels usually do print the name of their network on flyers, signs etc.
                      But an attacker does not have to make up fake names, he can just use the legit name.

                      At an airport you might see:

                      - Airport Net
                      - Airport Net
                      - HP_Printer.

                      Where "Airport Net" is the legit offices name, that the airport uses.
                      An attacker then names his AP also "Airport Net".

                      Then you see:

                      - Airport Net
                      - Airport Net
                      - Airport Net
                      - HP_Printer.

                      There is no way to know that one of the "Airport Net" AP's are not run by the airport.

                      And even worse.
                      If

                    • Re: (Score:2)

                      by s.petry ( 762400 )
                      AFAIK what you are describing is surely possible, but I'm wondering if it's illegal. "Alquada_terrorist_network" may be offensive, but not assuming the ID of anyone. Yes, possible so I stand corrected.

                    • Re: (Score:2)

                      by elgaard ( 81259 )

                      Well, if you are the third AP owner in your neighborhood that has a network name Linksys or Home Network, you should not get into trouble.

                      If you named you network Logan Airport because you wanted to gain access to passengers computers, you would be breakting the law in most countries.

                      If you named you network Logan Airport because you were curious to find out how many would connect to it, well I am not a lawyer, but I would say you were on thin ice.

                      The problem with faked DHCP-servers is not so much that it c

    • If no one but bad guys looks for these vulnerabilities, it might as well be closed source. And given the vulnerabilities and how long they have been out there, they effectively are closed source.

      And when closed source projects have vulnerabilities reported, they too get fixed, or they get disabled and people will move to a competitor. Sure there are counter examples in both arenas, but closed projects will tend to patch any exploits in the wild.

      If your experience with closed source vulnerabilities is from

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

      Except when they are not fixed.

      There are various serious bugs lingering on bug trackers, which have been known for a long time, but no one takes the responsibility to fix them.

      For example, in addition to Heartbleed, OpenSSL had another bug which had been unfixed for 4 years [eweek.com] and even had a CVE record in place.

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

    • Such as, for example, upstream developers who might sometimes use libbfd in the process of opening a crash binary submitted in a bug report - so no need to worry about remote code execution, local code execution will do just fine.

Slashdot Top Deals

Some people only open up to tell you that they're closed.

Close