Why open source fails application security tests

Why open source fails application security tests

Summary: Thornton has knocked down the door and gotten our attention. Now he needs to work cooperatively with the community -- including other security vendors -- to get it back on its hinges.

SHARE:
43

Fortify CTO Roger ThorntonOur friends at Zero Day gave Fortify CTO Roger Thornton the floor today, to answer critics of his recent study on open source application security.

It's a good piece.

One point which really struck home concerned how we test open source code. We test it to see if it works. Security testing works to see if it can be broken.

The distinction is important. Security doesn't test for bugs, but features that can be exploited.

This makes security hard to build into an open source business model. It's one of those costs, like insurance, which go into the category of overhead. And open source is all about getting rid of overhead.

The answer is security must first become a business imperative, an early difference between a "community" edition of a package and a "paid" version for which businesses must pay support fees.

This, in turn, tells me where the pressure for change in open source security need to come from, big customers.

Scary headlines like "open source insecure" create heat, but "we the undersigned demand security testing or we rip it out" are needed to turn on the lights.

My hope is customers go about this responsibly, and Fortify can help, perhaps offering deals with large users, working through user groups, to get the job done. And by cooperating in this with other security vendors in the way open source works other problems.

In other words Thornton has knocked down the door and gotten our attention. Now he needs to work cooperatively with the community -- including other security vendors -- to get it back on its hinges.

Topics: Open Source, Security

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

Talkback

43 comments
Log in or register to join the discussion
  • Makes Sense

    Most FOSS is built by people with a passion to make something important to them. Implementing comprehensive security is not a fun task to do when developing software.
    mikefarinha
    • Exactly

      But at some point -- when a piece of software goes into wide distribution -- it needs to be addressed.
      DanaBlankenhorn
      • Why,

        Security isn't needed in every application, but it should be built in from the ground up where it's needed, like accounting applications; but not relevant to games, etc.
        Deadly Ernest
        • Not relevant to games?

          So someone can install things suid root to get the right permissions for hardware?

          No security issues there, nosiree, it's "just a game"
          rpmyers1
          • So you advocate the games having the ability to

            inset or install a root kit? If the game has no ability to raise privileges and no ability to operate outside its defined areas, then it has no ability to attack the operating system. Also, if the operating system is properly designed with security in mind, then the ability to make such an attack is greatly reduced. I say greatly reduced as a few new attacks in recent years have come through new ways of writing code and we don't know how that will change in the future.

            The majority of malicious code is able to work because of faults in the code of the operating system or hooks and back doors designed into the systems, some have occurred through proprietary code not allowing virus scanners the full ability to look inside them for nasties. The biggest problems today are due to propensity to use client side scripting via proprietary systems such as Quicktime, Flash, etc that can't be scanned properly and can have large sections of nasty code embedded in them without being picked up.

            But, back to the main point, a well written game should NOT be a security risk as it shouldn't have any capability of being used as a spring board to launch an attack and there is no data of great security concern kept in a game.

            Having said that, some things that present now as a game are no longer a game application but an interactive web site - such as Never Winter Nights, City of Heroes, and the other Internet only interactive applications. So they should be dealt with as an interactive Internet application and not a game due to the large amount of code constantly being handed back and forth to the system. A game is an application that's loaded and then just run within it's existing code, not something that is loaded new every few minutes.
            Deadly Ernest
        • Anything that connects to the Internet

          Anything that:

          -Connects to the Internet
          and
          -Requires elevated privileges at some point - that includes the installer

          [b]Can[/b] be an attack vector and [b]must[/b] pay attention to security.
          CobraA1
          • True, but why must it have elevated privileges?

            If the application is written properly, the application should only be sending a few fairly simple commands to the operating system and be working at its required privilege level for the whole operation of the application. It shouldn't need to raise its privilege level during the operation as it should be properly set to begin with, and if it needs a high privilege, then proper security aspects should have been built in from the beginning.
            Deadly Ernest
          • The level must be as low as possible for as long as possible.

            The level must be as low as possible for as long as possible. There are many applications that generally do not need elevated privileges except during exceptional circumstances, for example while the application is updating itself.

            You certainly don't need to keep the application at the highest privilege level all of the time on the off chance that it might need an occasional update!
            CobraA1
          • An update is NOT a normal function of an application

            and should be done as a special activity through another application, so the application being updated should NOT be open and running and thus not vulnerable. The majority of the versions of Linux in use today use applications like Synaptic or Adept to update the applications on the system. I'm sure they are probably some that are still updated outside of this, but they should be done via an external applications not the original, thus the original application doesn't need to upgrade privileges, the updater operates at the elevated privilege for the short period it's active.

            This separation of function and privilege greatly reduce the security risk as the update application has very restricted capabilities and is NOT getting general data inputs from other areas either.
            Deadly Ernest
          • Not the only example

            That was an example: Another example is shell integration. If your user just wants to access his or her own documents, then it works great. If, however, the user is working in some other space (such as cleaning up after a failed install or uninstall), then the user, and perhaps the application providing the shell enhancement as well, may need elevated privileges.

            In addition, there are many applications that perform unique tasks that may need occasional elevated privileges. Xfire, for example, is an application that provides instant messaging in a game. This requires intercepting keystrokes and the video at a rather low level, and some games themselves are rather stupidly designed to require elevation, so it has to deal with that situation as well.

            Registry cleaners and editors often keep you in user mode unless you try to access protected keys. Same with file browsers.

            There are also electronic software management software such as Steam and Impulse that provide the ability to buy and launch applications from a common interface. You don't need to elevate privileges if you're just launching the application, but installing it needs elevation.

            What I provided was only one example. I can think of a few more, if need be.
            CobraA1
          • Most of the elevation cited are not appropriate

            situations and can be managed without elevating privileges. The majority of situations cited are due to poor writing of the application in the first place. And some others are due to an attempt to get around poor practices. The fact that they do occur at present, doesn't mean that they should occur.

            The most likely is the clean up in another's space, they shouldn't be in another's space unless they have the normal user privileges for that space or an authorized higher level user, in which case the normal privileges for that space and application should apply and thus not need an elevation.

            When you're installing an application, you do sometimes need a higher privilege for that action, however, you don't need it to run and use the application, so my original statement about the application itself still stands.
            Deadly Ernest
          • UAC means even an admin doesn't always have all of the privileges

            "or an authorized higher level user, in which case the normal privileges for that space and application should apply and thus not need an elevation."

            Authorized high level users should not remain in the higher privileged state indefinitely! This is what makes previous versions of Windows so insecure compared to *nixes. You don't remain root longer than you need to be in a Unix based system, and you shouldn't remain Admin longer than necessary in Windows.

            With Vista, even an admin can be in user mode, so yes you can still have an admin that can't access privileged operations. Don't forget that's what UAC is all about.
            CobraA1
          • The best way to manage the security

            is for everyone to be a low level user, and when a situation requires the higher admin levels, they log in as a different user with the admin levels, do the task, and then back out. This how it's done in the nix set ups in the security gateways and secure systems. As an admin in a high security gateway I used to have three log in and three passwords, one was for my daily duties as a normal user, another was as a power user type position for doing much of the standard work like virus updates and the like, and the third was my admin log in for when I had to do high level admin stuff. So I never actually elevated the privileges on any account, I logged in again as a different user with higher privileges. This set up meant you could NEVER elevate an actual user's privileges and those with admin privileges were logged in only for the minimal amount of time needed for such authoritative access.

            The poorly set up MS Windows UAC system doesn't even come close to matching the nix security system.
            Deadly Ernest
          • Never heard of SU/SUDO?

            "The poorly set up MS Windows UAC system doesn't even come close to matching the nix security system."

            Oh, please. Never heard of SU/SUDO? It's the same concept. Windows just wraps it in a GUI popup.
            CobraA1
          • yes I've heard of SU and SUDO and it's usually done

            with a gui now, and has been for ages, but Windows wraps it up and a badly done gui and a poorly set out process, as is evidenced by the many troubles with it.

            Kubuntu, Ubuntu, and Mepis Linux all operate a gui based su/sudo privilege increase for admin functions and do it very seamlessly with none of the troubles that Vista has, and they've been doing it for three or four years or more. A simple box pops up when required, the password is entered and away you go with the lowering of privilege as soon as you leave the admin mode. Only seconds to get in and out; unlike the way Vista goes about it.
            Deadly Ernest
          • You just described UAC. What's the big difference??

            "A simple box pops up when required, the password is entered and away you go with the lowering of privilege as soon as you leave the admin mode."

            You just described UAC. Same thing.
            CobraA1
          • A lot depends on how you set it up to start with

            My understanding of the current set up for the Vista UAC is it allows you in to the full admin mode on the computer- I haven't used the final release version of Vista as I didn't wish to waste my money on it.

            With most of the current Linux distributions (and many have been this way for three or four years), the basic set up is - when you wish to enter an area for work as the admin, it lifts the privileges but only for the sub area that you've designated you wish to work in. When you click on the icon or menu to enter the work area, a little gui window pops up, you enter the password or the id & password and you're into the area you need to work in, when you close the work area you're logged out. There is an area where you can set up for full admin access to everywhere, but very few set it up that way, most set it up to give access for only the task you've indicated; default is limited task area only.

            The difference is that you end up with admin privileges only for the task and task work area indicated. So upgrading privilege to change network details does NOT give you admin privileges to work on the file system or the graphics etc. This further limits the area of exposure and you have to select the work area BEFORE you have the opportunity to enter the password etc.

            From how people working with Vista have explained the UAC, and the way it was in the Beta version I tested, you can actual select to upgrade the privileges and enter into full admin mode without designating a work area. Thus, it's possible to take over full control through the UAC, whereas you can't through the Linux style.

            Another aspect of the modern Linux format is that the default log on process is as a user only and most will NOT allow you to log in with full admin privileges at initial log in now, while that can be done with the Vista system. This means it's harder to raise the privilege levels in Linux and the area you can attack is limited even if you can.

            Mind you, a lot of how the security of Linux works does vary between distributions, just as the Windows security varies between versions.
            Deadly Ernest
          • Some similarities, some differences.

            "My understanding of the current set up for the Vista UAC is it allows you in to the full admin mode on the computer"

            If you turn UAC [b]off[/b] and stay in the administrative account is the only time that happens. By default, UAC is on and you're almost never in admin mode.

            "I haven't used the final release version of Vista as I didn't wish to waste my money on it."

            In that case, it sounds like you have no basis for your accusations, since you have never tried it. It sounds like much has changed since the last time you tried it, and since you haven't tried the final version, you can't speak for it.

            "when you wish to enter an area for work as the admin, it lifts the privileges but only for the sub area that you've designated you wish to work in."

            UAC does something very similar - [b]only[/b] the software you elevate the privileges for will receive the elevated privileges. Everything else on your system remains in user mode. When you shut down the program, it no longer has privileges and you have to go through the elevation procedure again the next time you launch it.

            "The difference is that you end up with admin privileges only for the task and task work area indicated. So upgrading privilege to change network details does NOT give you admin privileges to work on the file system or the graphics etc."

            I've never had that ability with SU or SUDO, but then again, I haven't used a Linux system in a long time. I don't know if UAC is doing something similar or not.

            I don't think your average user would know which "work areas" to use anyways - if a program asks for elevation, how does the user know if they want to have it access the network or the file system?

            Or both, for that matter? I've seen installers that will download updates for the software, so both network and file system access are desirable.

            This whole "work space" concept may be something that maybe the OS should be concerned with, but I don't know if the end user should be given the burden of having to deal with the higher complexity.

            "Another aspect of the modern Linux format is that the default log on process is as a user only and most will NOT allow you to log in with full admin privileges at initial log in now, while that can be done with the Vista system."

            False. UAC changed that. Even if you log in as "admin," you are really logging in as a regular user. The only difference between you and a standard user is that you don't need a password to get past the UAC prompt (and even that can be changed to require a password always), while a standard user does.
            CobraA1
          • MS say they didn't make big changes to the UAC

            so it's reasonable for me to believe it to be the same as when I tried it as a Beta. UAC is the MS attempt to copy what Linux has done for years - but not as well done.

            "If you turn UAC off and stay in the administrative account is the only time that happens. By default, UAC is on and you're almost never in admin mode."

            Can't do this in most modern Linux distros. However, what I was referring to was the way that the UAC I used placed me in admin mode when I entered the password, so if I upgraded to use the control panel to make changes to network settings I could switch over and also adjust other settings at the same time without entering the password again.

            "UAC does something very similar - only the software you elevate the privileges for will receive the elevated privileges."

            Do you really mean it will upgrade privileges to run a full program or do you mean a routine? Most modern Linuxes will only upgrade the privileges to allow you to run the routines to adjust system settings etc, as that's the only time you need to be in the admin mode. It doesn't upgrade privileges to run a full program or application of some sort -only for system maintenance and settings.

            "I don't think your average user would know which "work areas" to use anyways - if a program asks for elevation, how does the user know if they want to have it access the network or the file system?"

            The user doesn't need to know, if they select the icon for a system setting, the security system kicks in and they enter the password and away they go - just the same as when they do in the Windows Control Panel, except they only have upgraded privileges for that one area and need to enter the password again if they switch to another setting icon; not my experience with the UAC.

            I note you comment about my not using the latest version could mean it's changed, just as the changes to the Linux Su / Sudo since the last time you used Linux as well. So your comments on my experience flow back the other way too. But I did try a fairly recent version of Vista UAC and MS claim it operates the same as then.

            "False. UAC changed that. Even if you log in as "admin," you are really logging in as a regular user. The only difference between you and a standard user is that you don't need a password to get past the UAC prompt (and even that can be changed to require a password always), while a standard user does."

            If you don't need to enter the password again, then you're in full admin mode, regardless of what you want to call it. If re-entry of password isn't required, the system is easily compromised once you reach the user account.
            Deadly Ernest
          • Well, I'm in front of a Vista system, and here's my experience

            "what I was referring to was the way that the UAC I used placed me in admin mode when I entered the password, so if I upgraded to use the control panel to make changes to network settings I could switch over and also adjust other settings at the same time without entering the password again."

            Well, I can't. Tried it just now. Two different things that require UAC require UAC to be activated both times. Using UAC on one part of the system does [b]not[/b] enable everything to access the system.

            Sorry, but I'm sitting at a Vista system right now. You can hoot and holler all you want, but that won't change my experience.

            "If you don't need to enter the password again, then you're in full admin mode, regardless of what you want to call it."

            And I still need to get past the UAC prompt to get the privileges elevated, no matter what you say. You can force it to use a password all of the time if that makes you more comfortable.

            "If re-entry of password isn't required, the system is easily compromised once you reach the user account."

            If you can explain to me exactly how the program can bypass the entire security system and engage in a protected operation without setting off UAC and notifying the user, I (and a lot of hackers and security experts, I'm sure) would be happy to entertain the idea. Many people have tried, but all reports are that UAC works, and trying to bypass it without setting it off have failed.
            CobraA1