Six open source security myths debunked - and eight real challenges to consider

Six open source security myths debunked - and eight real challenges to consider

Summary: Just like proprietary software, there's plenty of plus and minus points to using open source software. Here, one expert slaps down the myths while highlighting some of the genuine issues.


Detractors of open source software often point to its broad developer base and open source code as a potential security risk. But that's not a fair assessment, according to Dr Ian Levy, technical director with the CESG, a department of the UK's GCHQ intelligence agency that advises UK government on IT security.

Open source is no worse or better than proprietary software when it comes to security, according to Levy, who busted myths about open source security — and detailed its genuine security challenges — at the Open Source, Open Standards conference in London last week.


Open source software is more/less secure than proprietary
"I've done a lot of work on this, there's no objective evidence either way. On average, good open source is about as good as good proprietary, and [bad] about as bad as bad proprietary," said Levy.

Asking whether any piece of software is secure is too broad a question, according to Levy. A more valuable approach, he added, is to ask what security guarantees your organisation wants from a piece of software and then ask whether the software delivers that.

Many eyes makes for secure code
The idea that, because open source code is open for anyone to look at, its security will have been subjected to greater and more worthwhile scrutiny is questionable, said Levy.

Of everyone who had downloaded the Linux kernel code he asked: "'Who thinks they are competent to judge the security of the Linux kernel?' Downloading 21 million lines of Linux code and saying 'I've got the code and I've looked through it', so I can convince myself it's secure, is often nonsense.

"Many eyes give you many eyelashes, and not a lot else."

Bad people can look at the source code, so it's less secure
"Again that's nonsense. If I look at how people break software, they don't use the source code. If you look at all the bugs in closed source products, the people that find the bugs don't have the source, they have IDA Pro, it's out there and it's going to work on open and closed source binaries — get over it."

Anyone can contribute to the code so it's all bad
While some elements of this assertion might be true of some open source projects, "in a lot of open source projects it's not", he said. To offset this risk, learn about the open source project and its history and make a judgement call, he said.

Open source software means it's open for your organisation to use
Just because it's open source doesn't mean that it's free from restrictions. It could be in the licence — the GPL places restrictions on you, the BSD fewer restrictions. They may not be relevant to you at all, but there are restrictions."

Even if licensing isn't an issue, organisations can fall foul of separate IP rights conflicts, he said.

Levy gave the example of the distributed compute and storage software Hadoop, which is referred to as an open source project.

"It's a patented algorithm. Forget the implementation. The implementation may be IP-free but the algorithm is patented — do you think you can use it?"

All software must be evaluated for security
"That would be insane, and yet we still hear this. Around government every piece of software has to be evaluated before we buy — it's utter nonsense. Only security-enforcing functions need security evaluation."


Software distribution
The online distribution methods used by many open source projects are vulnerable to genuine software binaries being replaced with fakes containing malicious code, he said.

"How do we get assurance for online distribution, because a SHA-1 hash and a PGP key sat on the same server as the distribution doesn't do it for me. There've been publicly noted attacks against distribution servers. Nobody's touched the source code, but they've touched the binary, the MD5, the SHA-1 and PGP code around it.

"You've downloaded it and checked the hash but you got the hash from the same place you got the binary. Where's my route of trust?"

The same question over provenance of the code can be raised when it comes to receiving patches for open source software, he said.

"If I go to Windows Update I know it's signed, and I have a process that works inside Microsoft. What do I know about Red Hat? A lot, and it's broadly equivalent.

"What do I know about 'Ian's Honest HTTP Server' software? You're going to have to do the work to assure yourself those patches sensibly controlled."

Exploit visibility
"Open source patches have to put out the source. They inherently disclose the underlying issue. So if I've got a security vulnerability in a product and I put a binary patch out, it's a chunk of work to reverse engineer it and work out what the underlying thing is. If it's open source, then I'm putting out a source patch and so I'm telling my attacker exactly what the problem is.

"That's not necessarily a bad thing, providing you've got a sensible patching regime. You've really got to have a sensible patching regime because time to exploit is probably going to lower."

Open source projects also have individuals and groups who actively track bugs in the code, which also makes these potentially unpatched bugs more visible.

"If they're open to everybody that's another issue, because now you get zero day exploits because there's no patch," he said.

Auditing the code supply chain
"How do I know who's written my code, how do I know what they've imported, how do I know what other stuff is in there?" said Levy.

When it comes to imported software modules, for example, an organisation can expect that a commercial company has a team of lawyers that check this imported code for licence compliance and engineers to handle reported bugs.

"How do I get the same kind of assurance with free software? What can I say about the legality of it? How do I know that somebody has looked at the licences of these imported modules and done the due diligence on it?

"I'm not saying you can't do it, I'm saying how do you do it? It's a different set of challenges."

Team breakdown
"Change of personality can have a much bigger effect in an open source product than it can in a commercial product. A commercial product has a brand value, an open source product is driven by a bunch of people. You'd hope they are all broadly aligned but there have been there's been spats in open source projects where they've massively changed direction."

Developer relations
Being able to evaluate the security of software relies heavily on having knowing the developers and having some insight into their future plans for the software, according to Levy.

"The security evaluation is about the developer relationship, it's not about source code," he said.

"Anybody who thinks an evaluation crawls through every line of source code looking for vulnerabilities is sorely mistaken — it's about big picture stuff. The evaluation at the level we're talking about is about does the developer have clue what they're doing? Do they have a long term plan for keeping this thing secure? Do they have an incident management plan?

"Extracting product design architecture from code is incredibly difficult. If you haven't got a relationship with the developer to ask 'Why did you design it like this?' then evaluation is really difficult and often you need a third party to act in this role. It's a business risk to be managed."

Developer identities are generally weak
Whereas a commercial company may have several layers of assurance for developer identity — an on-boarding process, an identity process, a technical identity process for checking-in source code — establishing developer identity can be far trickier for some open source projects.

"For some of these projects it's a Gmail address. Who wants to bet the farm on the security of someone's Gmail account? There ways around all of these but these are things you have to think about."

Lack of development standard and common security infrastructure
"I can audit a company and say 'You have these standards and apply them and yes you have incidents but you manage them well'. How do I do that for a diverse set of developers on their own hardware?"

Topics: Security, Open Source


Nick Heath is chief reporter for TechRepublic UK. He writes about the technology that IT-decision makers need to know about, and the latest happenings in the European tech scene.

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
  • FOSS fanboi to come out crying foul in 3 - 2 - 1 ...

    Go! LOL.

    For years we've been saying openness has nothing to do with better security or quality. The whole thing is an over-hyped bandwagon that only fools stay on it.
    • That's why any Windows has to use anti-virus.

      And Windows needs UEFI to help prevent botnet infections when LInux does not need UEFI or AV and doesn't get infected or have issues with botnet takeovers like Windows does.

      Run open source and Windows gets infected because of Windows problems. Run the same program on Linux and there are no issues.

      12 years of everyday proof.
      • So what's this?

        Hate to bust you like this but let's check the quote:
        "Ubuntu Security Notice USN-1786-1

        4th April, 2013

        firefox vulnerabilities

        A security issue affects these releases of Ubuntu and its derivatives:
        Ubuntu 12.10
        Ubuntu 12.04 LTS
        Ubuntu 11.10
        Ubuntu 10.04 LTS"
        • Try finding better comparisons

          Comparing Ubuntu that ships with things like LibreOffice with Windows without any external software isn't very bright. Then you should either install the corresponging Windows software or uninstall that extra Linux software first.
          • Windows won't infected...

            ...if you don't use any apps. You usually get infected if you use vulnerable software. Really there are only a few things you need to look out for to remain virus free.

            Generally speaking, Windows has sacrificed security for ease of use. The majority of security related issues happen due to people running under an Administrator account, which is the norm. It's usually the practices of Windows users, and not Windows itself, that creates the majority of security problems.
            Ehsan Irani
          • Linux sacrificed ease of use for ???

            "Generally speaking, Windows has sacrificed security for ease of use."

            But Windows IS secure, and easy to use. What has Linux sacrificed ease of use for ?
      • Correct me if I'm wrong

        But didn't, and several other high profile Linux sites catch a rootkit which then went unnoticed for almost a month?

        Oh yes they did. The servers running Linux, managed by the people most knowledable about Linux IN THE WORLD were thoroughly root'ed by an unsophisticated attack (i.e script kiddie) involving and old Linux rootkit.

        So try to explain again why Linux doesn't need protection against rootkits. Maybe you should explain it to Linus Torvalds whose went offline for a month to clean up the mess.
        • You're wrong and probably never worked for a software company.

          I've been through this a couple times before, but I'll describe it again.

          Software versions are charactized by version numbers, in my case, when I worked for Bentley Systems, a version was designated by numbers like

          Software, like Firefox makes versions for Windows and Linux among others. Basically the core parts of the program operate in the same manner and the API is different to work on Linux and adjustments are made for libraries, directories, etc.

          The dirty little secret here at ZDNet and among the shills is that they blame an application for allowing an intrinsic problem or vulnerability with the OS to be accessed. Shills, Ed, and ZDNet are great at blaming the application, such as Chrome or Firefox for the problem and not addressing the core Windows vulnerability. Then, they read documentation and without knowing anything about how things are done, blame the Linux counterparts, because they are listed.

          The problem is that items present in the application allow the core Windows vulnerability to be used to infect Windows. The application issue may also be present in the Linux version, but because Linux is so much more secure than Windows, there is no problem or infection with Linux. The only way Linux could be infected is if the malware could read the mind of the user and get his password.

          Developers review the Windows version issue and make adjustments so it does not allow the Windows vulnerability to be addressed and also make the change across the board to all sister versions to maintain consistency. Because you are naive and see Ubuntu listed as affected, it does not mean Ubuntu ever had a security issue at all, the Ubuntu version is just having the code changed for consistency. In other words, no application for Windows is ever going to fully prevent all the Windows critical flaws from being accessed. Those application characteristics causing the Windows issues may be present the Linux version, but can't be used to attack Linux, but are being changed anyway. In most cases, the change may be an operating improvement and be more efficient.

          It's so silly to ZDNet pull the same BS over and over again, year after year. If you want to believe it, you are only following the ZDNet propaganda trail, Do yourself a favor, pour yourself a strong one, and install Ubuntu or Mint on a second machine, run it as a Live DVD, or install it as a dual boot and your primary computer. Then, install, Chrome, Opera or any other open source program you like and try to get infected. Then come back here and post the Website and how you got infected. That's something that no one, in all these years of accusations has ever been able to do. Once you see that you don't get infected you;ll begin to see how ZDNet twists information and is just a stooge for Microsoft.

          As far as you referencing Linux Torvalds and the issue it was related to stolen passwords. Anyone who gets poorly secured passwords an attacks a system can't be stopped. Most times the admins are storing their login information on a Windows box, that gets easily hacked by a zero-day or a crafted emai that allows access. Remember the big ZDNet push for articles about Google, which runs 100% Linux getting hacked? Well, two Chinese employees were storing data on a Windows notebook and it easily got hacked. Since then, Google forbids employees from using Windows or work. you don't hear about that anymore here, do you? Forbidding employees to do company work on Windows is the single most important any manager can make.

          If you dig deeply into these articles against open source and Linux, you will find, as I have, that the core problem is Windows and you will see a critical update down the road, at a later time to silently correct the Windows problem. But that is never brought up here.
          • Prove that Linux gets hacked. It's something never done here.

            If you feel that strongly about it, post how and where you got hacked. I'm waiting.
          • eh?

            I take it you never frequent the Ubuntu forums then, most of the recent threads are about looking for other options #fact
            Kevin Morley
        • It didn't take a month to clean up the mess

          It took a month to redesign the architecture of the sites and servers. They could have brought it back up in hours, but decided to not do so until they knew it was safe.
          • "It didn't take a month to clean up the mess... "

            "They could have brought it back up in hours, but decided to not do so until they knew it was safe."

            Think about what you just said...

            I know you didn't catch it. The fact that you think Linux can't be hacked suggests a lack of basic reasoning skills.

            Security was the mess. It took a month to clean it up.
          • Linux is not a Windows clone or copy.

            Someone nurtured in Microsoft wants to see Microsoft in Linux. The closest they are going to get is Linux Mint Cinnamon or KDE. Linux does work differently, but previous Microsoft users don't need any retraining to use Linux Mint Cinnamon. Mint is a more friendly interface with a closer parallel to Windows so it's easier for a Windows only user to transition to.

            I converted schools over to Mint and have never received any call backs for problems. It's still working great after 3+ years with no maintenance (or virus problems).
    • Why Cry Foul?

      The article points out the fallacious talking points of the Anti-FOSS folks as well.

      Now, I do have an initial quibble about the suggestion that open source patches are problematic for pointing to vulnerabilities. I'll have to think about it more, but it seems to me that with Windows and IE patches, we were used to seeing immediate attacks on unpatched systems, suggesting that the closed source nature of that code provided minimal delay. What I do not know is if this has changed in frequency of occurrence. Regarding java exploits, there may be a point, but, as with Flash, the crackers seem to not need many hints. Java is open source (and one could have received a source license from Sun, as I did years ago to compile from source for a FreeBSD system) and Flash is not.

      Meanwhile, anonymous, you have not gotten the news that closed source companies use and provide a surprising amount of open code and open companies have their secret sauce code as well. Plus, many customers request the source along with the binary.
      • Figuring out the vulnerability closed by a patch is easier from the source

        ... especially when the check-in comments lead you on the way. But a determined attacker will be able to reverse engineer from the binaries as well.

        There's a special problem for Linux where there is a delay ranging from 2 - 6 weeks from patches hit until they filter through the distributions and become actual packaged patches you can install with apt, rpm or whatever.

        The period from disclosure enabling an attacker to figure out the vulnerability until patch availability is generally termed high-risk period, whereas the period leading up to the vuln disclosure is termed low-risk if it has been responsibly disclosed. Linux distros *always* has a high-risk period because of the distro delay. Closed sourced software such as Windows or OS X often have no high-risk period.

        That is not accounting for zero-day attacks where attacks begin before the vendor has had a chance to respond. Zero day can happen under any development methodology as it is not a trait of the methodology but rather one of the attacker (chosing to attack rather than to responsibly disclose).

        Some projects (e.g. Apple OS X and iOS) have another challenge: They rely on shared *components* where disclosure is beyond their control. Countless bugs have been found in popular libraries such as libxml, libpng, libjpeg etc. These components are being so widely used that it is *not* feasible to coordinate patches with vendors of all of the products that make use of them, be it in source or binary form. Consequently, vulnerabilities are often disclosed for such libraries when the *first* product patches them. The period that follows are high-risk for the other products, until they are patched.
        • I don't see infections at all in Linux.

          The zero-day concept is a real problem with Windows, but I'm not seeing anything in Linux that has ever created issues. So, in practical terms, no data theft, no identity theft, no access for remote code execution, no viruses, no botnets, etc. with Linux.

          If you want an example of Windows infections, my Acer one netbook came with 64 bit Windows 7. I made a dual boot setup with Mint the first day and used Mint for everything. I thought I would periodically open Windows to run critical updates, but one time, I found that it was infected with the Auleron.DX rootkit botnet in just running the updates. AV was installed and fully updated from the start.

          Microsoft had advertised their advanced 64-bit driver signing as some sort of salvation, but the Auleron.DX bypassed it, turned on my proxy server settings and inserted a Russion IP address. Auleron steals financial logon information. People here post how Windows 7 is so great, but, not really, it's still Windows at heart.

          I'll easily run Linux with UEFI turned off, but when people want a dual boot, I'm reluctant to turn it off for Windows.
  • Test the theory yourself

    Get a box and harden Windows, use ANY anti-malware you like.
    Get a box and install any Linux distro, any of them, pick the weakest one you can think of.

    Go look at any web site you like with Firefox, Opera or Chrome on both ... NO IE (not supported on Linux).

    (hint: adult content and gaming sites that are 2nd or 3rd tier are reportedly famous for infections), try google searching "most dangerous web sites".

    The rules of the game are:

    * only following links or using the back button icon of the browser are allowed
    * if windows pop up you are not allowed to touch them anywhere (including the X to close).
    * if the back button is not usable or the browser is non-responsive, close the browser with task manager.

    The object is to visit infected sites and return without touching anything.

    See which system is left running after 1 hour.

    Please report your results HONESTLY.

    * ( ... no clicking (X)
    * If the browser locks up ... use the "task manager" to kill it.
    • You got it. It's something that is well hidden here.

      ZDnet isn't worth the effort, they are a failure, just like MS.

      ZDnet articles you will never see.

      Intel makes cheap processors for Win8 AND CHROMEBOOK (the truth)

      Why you don't need AV on Linux but need it on Windows?

      30 ways to get Linux infected from the Web.

      Galaxy S4 with 8 core processor and eye tracking software expected to overtake Apple in Q4.

      AV companies don't make any software for Linux, it's not needed and won't sell.

      etc, etc, etc.
  • Six open source security myths debunked - and eight real challenges to cons

    We knew that the many eyes theory was a myth. There was a security vulnerability in the linux kernel for 2 years.

    The linux distro repositories are always getting hacked so that's another security challenge for them.

    Linux leaves the telnet port open by default, again mark this under the security challenge.

    These are all linux security issues. Look at OpenBSD, a rigorious code review is done and they have very little if any security vulnerabilities.
    • You are still full of it.

      "There was a security vulnerability in the linux kernel for 2 years."

      Sure. And the many eyes spotted it. It takes a while. There are still problems in proprietary systems that goes back 4 (or more) years.

      "The linux distro repositories are always getting hacked so that's another security challenge for them."

      4? always? At least you hear about it. Unlike the MS penetration that lasted 6 months or more before being noticed.

      "Linux leaves the telnet port open by default, again mark this under the security challenge."

      Hasn't been there for at least 15 years. And before that, you had to explicitly enable telnetd to run. Not to mention the fact that you have to SPECIFICALLY install it in the first place.

      Unlike like Windows - requiring the insecure RPC port open on all systems....

      And BSD is equivalent to Linux - minus the fact that Linux supports mandatory access controls. Which Windows also lacks.

      So you just spewing your usual BS.