In Heartbleed's wake, let's not forget many open-source apps remain vulnerable to attacks

In Heartbleed's wake, let's not forget many open-source apps remain vulnerable to attacks

Summary: Over 46 million Java-based open-source components containing known security flaws and vulnerabilities were downloaded in 2013, according to the latest research.

(Image via CNET)

The wounds caused by Heartbleed remain at the front of many minds, just a few weeks after a bug in the OpenSSL cryptographic library threatened to throw the world's Internet population under the bus.

The flaw could have allowed hackers to reveal contents of secured communications — such as passwords and credit card transactions. But to make matters worse, the fears around the flaw were only compounded when another separate vulnerability was found, this time in OAuth and OpenID, a few weeks later.

According to one researcher, that's far from being the end of the matter.

Many millions of Java-based and other open-source applications are vulnerable to flaws that have been around for, in some cases, years, he warned. And even up to today, they are being downloaded

Sonatype's Brian Fox penned a note on Wednesday with his "jaw hanging open," explaining that although many projects typically respond and patch vulnerabilities quickly, the issue is that "users don't respond as quickly to consume the fixes." 

"Given that attackers are notified via the same mechanism that a vulnerability has been found and fixed, they effectively have first mover advantage because it's generally easier to exploit than it is to update your application framework," he wrote.

In a few given examples, hundreds of thousands of affected versions of commonly used and highly popular Java-based apps were downloaded by tens of thousands of organizations.

He said affected versions of Struts, a widely used application framework, were downloaded more than 80,500 times from more than 10,000 organizations in the nine months a major remote code execution flaw was disclosed.

Meanwhile, although Bouncy Castle remains the most popular white-room implementation of cryptographic algorithms in Java, a version that contained a vulnerability that allowed an attacker to compromise encrypted data was downloaded more than 20,000 times in the five years after the flaw was disclosed. More than 4,000 organizations are said to be running an affected version.

"This essentially makes the thing you intended to encrypt completely open," he said.

Heartbleed may give IT organization leads the shivers and cold sweats, but Fox warned that many other open-source apps are not being updated as quickly as they should be. 

That, he hinted, could lead to the next Heartbleed-style attack of scope and potential damage.

(Image: Sonatype)

Topics: Security, Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Why is this a surprise at all?

    Yes, it's bad. No, it is not a surprise at all.

    Once open source and FOSS made it into the corporate world, it inherited every bad habit and tradition there as well. It's a bit ironic, but I would suspect that consumers and techies are much more up to date. And why...

    The larger the organization and the more centrally managed, the slower the update rate, and that does not matter if it is open source, proprietary, free, whatever. Central management means central control and - of course - central accountability. So no one wants to push out ANY update until it is FULLY (as in, two updates behind) vetted. And add to that it is often put on someone's task list and, if no one pushes the issue, it drops as other more immediate tasks come up.

    This is a carryover form the mainframe world, where there were "applications" and "systems" groups. Even then, they often clashed because the developers would learn of a new function or whatever only to find out that the systems guys down the hall haven't turned it on yet because they haven't gotten around to testing and implementing it yet. Just magnify that with network and workstation (PC) areas and you know where this is headed.

    It was okay in the days before most updates are for security or have a security component to them. Now this doesn't work. But it is still the common practice in more corporate environments. Hazard to think (since it take a lot of companies forever to even upgrade Web browsers in the first place) that many large companies haven't even started thinking about the MS fix from last week that had so many techies' knickers in a knot. So open source, way, WAY down on the list.

    Just ask Target...
  • Know the facts before you publish!

    This is going nowhere. As long as those that write base what they write on what they are told by others to write, chaos is created.

    1. The address space limits the vulnerability on open platforms to the secure application and the client - e.g. the one that typed a password can get back (for debugging purpose) to see. So the security flaw is that he or she can then yell "yes, I got my password back!" for everyone to see.
    2. For Windows users, the heartbleed can dump the entire address space and that will contain passwords and otherwise encrypted data that belongs to this and all other applications. But to them, there is a very simple solution: use e.g. Ubuntu and run "Wine"-Windows emulator, and the emulator memory is what will be compromised.
    3. Well, the network traffic can be intercepted in any router on the way, where agencies such as NSA has inserted a "tee". This cannot be avoided - they can intercept the password that is returned.
    4. You can use unprotected wireless internet, or WPA encrypted, and people can listen to this, and intercept the packets - this is US CDMA technology that is very easy to tap into. Software is available on the net to write "injection" packets - and this will SSL still protect you from - except the returned packets. But they can turn "Heartbleed" on and off once they have "injected" into the stream.

    Now, go back and rewrite the article - do not read what others say, go to those that has coded this and ask them, someone that at least has written C-code that has "include ".
  • Open source isn't about choice

    It is pretty clear that while open source advocates frequently start shouting about the code quality, choice, and security that open source brings, it is clear that net effect is entirely the opposite.

    Quality: If code is so complicated that only a tiny group of people can audit it, being open source is meaningless to the small development firm that simply wants to use a library for a couple API calls. They have neither the time nor the expertise to fix or identify bugs. it might as well be closed-source.

    Choice: What choice? Once a library is available and "free", human laziness takes over and simply using what's already available becomes the norm. We see that with OpenSSL; it's everywhere to the point where it becomes difficult to choose something else.

    Security: Monoculture is not security. We know from biology that differences are what create a disease-resistant ecosystem. By flooding the market with only once type of library and belittling those of pick an alternative, we make everyone vulnerable.
    • that's FUD!

      FOSS community has already fixed it. only M$ products using outdated versions are still vulnerable.
      LlNUX Geek
      • Ummm...

        There are no Microsoft products other than a built-in client for Juniper Pulse that are affected by this issue:
      • ... another troll in mom's basement (nt)

      • FOSS may have fixed it

        but all those other crappy software implmentations of FOSS haven't applied the fix, speaking of FUD.
        • What implementations of FOSS are you speaking of?

          “but all those other crappy software implmentations of FOSS haven't applied the fix, speaking of FUD.”
  • Interesting the focus on Open Source

    Yes, Open source has flaws, and as you pointed out, they usually get fixed quickly.

    Why focus the article on Open Source when what you are really discussing is the slow reaction time of corporations? Those of us that know how to read will see that you are not making any inference saying that it is inherently more or less vulnerable, but the way it's written may likely make other people conclude that FLOSS is inherently more vulnerable.

    An article can be factually correct and still biased.

    Was that the intention or just an unintended consequence?
    • Slow reaction times of the users

      The focus of the blog upon which this article is referenced is on the slow uptake of repaired components. All software has bugs, OSS is no worse than anything else. What is worse is that on average, consumers grab a component off the OSS shelf, start using it and never pay much attention to the fixes down the road. This is the thing that needs to be addressed and which I intended to draw attention to in my blog.
      • Slow to update

        In all fairness, most systems have automatic update capability; Windows Update, Gnome PackageKit, etc. If the user chooses not to use those features, though they are recommended and usually enabled by default, then you are right. It is the user being slow to react.

        In the case of corporate IT dealing with the heartbleed bug, keep in mind that patches were made available rapidly, but it was not as simple as applying a patch. Every service using TLS/SSL had to be examined and have new keys created and x509 certificates reissued. It was very far reaching and far beyond the run of the mill security fix, so took more than the usual amount of time.
  • You state the obvious

    We all know that most Trojans are coded in Java-script, since this is easier to code than Flash. Well, again the Window-viruses and trojans can all be avoided by using Mac or Linux (Android/Ubuntu) - and that stops most of them.
    The comment about "Heartbleed" is that this existed for years, and was identified by two about the same time, and fix provided in 48 hours, but in the meantime, some journalist had seen the "scope" and published that a security company was working on their own fix.

    It is essential for all open source users that all changes to the code done by you, is then your responsibility and you have no right to make claims to the original. So the "fix" provided without consulting OpenSSL, would not be a "SSL" - but something else. This is a legal issue, and once discovered those distributing modified code risk huge financial claims from the open source community, and also their clients, who believed they used the correct code. We all know that you can code malware in Java, and we all know that programmers can make mistakes. So what is the novelty? Are you surprised that there are bugs coded when they use Java?
    • Total nonsense

      There is no excuse for large companies to be using a free library as-is instead of writing their own implementation. Guys like Apple, Cisco, Juniper should AT THE VERY LEAST audit the SLL library from scratch and fork it to make their own audited version.

      Forks happen all the time. Your argument that because it's SSL code it cannot be changed is ridiculous. If anything, more audited forks of the library would prevent a monoculture from forming.

      Writing SSL from scratch didn't stop Microsoft from creating a compatible library. As long as there is agreement on the SSL behaviors, who cares how many implementations there are?
      • I agree ...

        This is all about saving money and the results are predictable just as the practice is endemic and legendary. It seems like disasters happen periodically as a result, memory is very short term and before long history repeats itself. The syndrome is not partial to either open or closed source software. It happens when people are cheapskates and someone (usually not the cheapskate unfortunately) ends up paying the price for it. If the people at the top focused on quality instead of a fast buck these things would not happen, or at least not as regularly.
        George Mitchell
      • Forking is not something to do take lightly.

        I'll excuse your lack of open-source knowledge and extend it a little.
        Companies don't fork projects unless there is very good reason, and here's why:

        Once a package is forked, over time it will become more and more different than the package it was forked from. When a flaw, or new feature, shows up in the original package, it will difficult, if not impossible, to tell if the same change can, or needs to, be applied to the forked version.

        This quickly becomes very, very difficult to manage for the poor soul who forked the project. For companies, this adds up to more and more expense, hence, the reason not to fork.

        The other big reason not to fork is what does the forker do when a major rewrite of the original packages is released?
      • So: Code Reuse as "A Bad Thing"...?

        "There is no excuse for large companies to be using a free library as-is instead of writing their own implementation."

        Apart from "time and money", perhaps?

        Is everyone supposed to write their own libc too?
  • The Zero Day Arsenal

    I've had a feeling (just a feeling) since the 90's that Microsoft built backdoors into their OS for the purpose of spying. I've had this same feeling about Linux. Because Windows is proprietary the feeling makes sense as only a select few can examine the code. But why I should feel this way about Open Source I'm not sure. I guess it might be because, while source code is open to the public, only a select few understand what's going on. So now we read in the news about zero-day arsenals this makes me wonder how many flaws are in both closed and open source and only known by a select few.

    With the sewing up of Heartbleed the spy community lost one of their weapons. But the spy community surely has others in their arsenal and they are not going to share those flaws with the general public willingly.

    I'm pretty sure the bad guys have their arsenals too, but they don't have an Edward Snowden going to the media to let us know about their stock pile. I'm willing to bet that there is overlap in the two arsenals, but with no one willing to identify the flaws they will remain only known by a few.
    • For sure ...

      There are Linux powered routers that are known to have back doors.
      George Mitchell
      • You are probably right,

        But the router makers added those back doors, not Linux or open-source developers.
  • Third party software is a HUGE problem ...

    This article exposes a very real problem which is end users downloading software from third party vendors. This problem is totally platform neutral. It can happen with Windows. It can happen with Mac. It can happen with Linux AND Android. This is a major reason why Microsoft has been trying to route all third party software through their app store. When you download an app ala carte over the Internet, you have no way to know when a patch is issued for that app UNLESS the app includes a feature that checks for updates, and many, if not most, do not. The ONLY (usually) safe way to install apps is via an app store or central repository managed by the OS vendor. There are far too many end users who simply don't know where they are getting their apps from. And they have no idea when one of their apps has received a security patch, so they go on using the same old app version until their OS no longer supports it. Simply downloading software from where ever on the Internet because it seems interesting is asking for trouble. Beware.
    George Mitchell