Slashdot Log In
Study Says Open Source Software a Security Risk
Posted by
CmdrTaco
on Mon Jul 21, 2008 05:18 PM
from the sky-is-falling dept.
from the sky-is-falling dept.
chareverie writes "Fortify Software released a study where they concluded that open source software poses a large security risk to corporations who have implemented it. They reason this by stating that the fault lies within the open source communities and their failure to adhere to minimum security practices. Fortify Software studied 11 open source software packages, where the application server Tomcat was determined to be the best. The other 10 were found to have poor results, with those being Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts. Jacob West, manager of Fortify's research group, reminds that purpose of the study was 'not to condemn open source software, but rather to point out that the security practices need to improve because open source adoption by enterprises and governments is growing.'"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
ZOMG!!! (Score:5, Interesting)
Why, this is just too much, how will we ever recover? And they even based it on 11 whole OSS projects... Game over!
Re:ZOMG!!! (Score:5, Insightful)
That being said, these are valid complaints, and if external support is going to be an issue with your company, then you need to think very carefully about whether open source software is right for you.
Parent
Re: (Score:2)
JBoss is owned by RedHat, so it qualifies as having a major company backing it (at least as much as RHEL does).
Re:ZOMG!!! (Score:5, Interesting)
Parent
Re: (Score:3, Insightful)
Yeah, I looked over most of the projects that they commented about... it's like, um... where are the big names? OpenBSD, Linux, X.org, Apache?
Like... oh right, if they reviewed high-profile FOSS projects rather than low-band FOSS projects, they'd come out with different results...
TRASHBIN!
What we use (Score:2, Insightful)
Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts
While we use tomcat, thankfully we don't use any of the others (in fact, I haven't even heard of several of them). As an example, we use Alfresco as our cms. If it ever caused security concerns, we could switch to a different open source cms. This would probably be quite a bit tougher if you were stuck with a single closed source package (and good luck finding out which "minimum security practices" a closed source vendor u
Re: (Score:2)
So maybe the whole question if it's valid or not is completely off the mark.
I've only heard of two of those... (Score:3, Interesting)
Tomcat and OpenCMS, to be specific. And I don't use any of them.
This might be interesting news to me if they found problems with: Apache 2, PHP 5, Wordpress, Gallery 2, or Python 2.5, which is basically what my site runs on.
And yes, I know there's security problems with PHP and Wordpress. I'm just pointing out that they aren't targeting more popular software; wonder why?
Re:I've only heard of two of those... (Score:4, Insightful)
JBoss is not widely used. Struts is, Hibernate mostly is... However, the underlying problem is that these are ALL middleware packages. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
This study manages to tell me one thing: This group has no idea how to perform studies. Even most FUD merchants would do a bit better job of covering the deficiencies in their methods.
Parent
Re: (Score:2)
. Is the study claiming that the middleware is faulty? Or that the apps other people write on top of that middleware has issues? If it's the apps, then the middleware is likely blameless. Even if it is the middleware, why isn't the app filtering out erronious inputs? And why is the middleware being run in a container with excessive permissions?
They appear to be claiming the middleware is faulty. Note that the authors of the report sell a Java-based static analysis tool for detecting the kinds of security f
Re: (Score:3, Insightful)
Or a real programmer as any good programmer doesn't particularly care what SHOULD be necessary and only concerns himself with what IS necessary here in the real world.
Re: (Score:2)
Wow. You do realise that there is a whole realm of coding outside of web apps, and that at the very least you should check any and all input that is going to interact with a database or filesystem? I wouldn't call myself an expert on security, but some things are just obvious. Either that was just a very poor joke, or.. the mind boggles.
Conflict of interest (Score:5, Funny)
Re: (Score:2, Informative)
WTF? My team uses Fortify to analyze our Java webapps (compiled on the Sun JDK [slashdot.org] and running on their JRE), which is then deployed to Linux servers running RHEL 5 [redhat.com]. HTTP connectivity for the apps is provided by Jetty [mortbay.org]; the apps themselves connect to Oracle [oracle.com] databases (using C3P0 [mchange.com] for connection pooling).
With Fortify 4.0, I griped that it provided no value that we didn't already get with FindBugs [sourceforge.net] (for free). The 5.0 release (along with the workbench, which provides better information than the HTML report), how
Re: (Score:3, Funny)
Not necessarily (Score:2)
Since Fortify is a security firm, it's obviously in their best interest to have everybody using their own products.
There. Fixed that for ya.
OSS is a risk compared too... (Score:5, Insightful)
in other news... (Score:4, Insightful)
to explain the parent post with quotes : (Score:3, Funny)
Eric S. Raymond discusses the recent Microsoft security debacle in which an engineer inserted a back door in a library that allowed access with the phrase 'Netscape engineers are weenies!' The article notes that 'Apache will *never* have a back door like this one.
http://linuxtoday.com/stories/20234.html [linuxtoday.com]
Re: (Score:2)
O RLY? [cmu.edu]
Never is too strong of word methinks.
In other security news.. (Score:3, Insightful)
Judge for yourself (Score:5, Interesting)
I'm not an expert on open source and security but I get the feeling that the authors judged open source software based on closed source standards. They author complain that disclosing security issues with general bugs was a problem. Did the author not understand that full disclosure is one of the tenets of open source? The last gripe is that the service wasn't the same with lack of contacts and responses. Judging by the summary it appears that the author just monitored the community forums. Did the authors even pay for support? When you pay for software and support, you should get it. When you don't pay for software or support, why should you deserve service?
Re:Judge for yourself (Score:5, Interesting)
Many of the projects they evaluated are Apache projects. The Apache Foundation has a private list for security bugs (security AT apache.org) so their complaints on that basis are unjustified for those projects at least. And I would be very surprised if they found security bugs in all of those projects in order to test the responsiveness of the developers, so I guess they sent some random mail that was probably justifiably discarded as spam.
Parent
Proprietary Software Poses a Risk to corporations (Score:3, Interesting)
Closed source/propetiary software doesn't adhere 100% to industry "best" practices, such as providing a prominent link to security information on their Web site either.
It's just not as easy to see where closed source is lacking, because, well: you don't have the source to conduct research into the security flaws.
If the source was not public, you in many cases, would have never known that X practice wasn't being followed by certain elements of the software.
Closed software can ignore practices whenever convenience, and since the source is closed, they are all but immune to this type of analysis.
A true comparison requires actually obtaining the source to proprietary software and using that to its full advantage to find security flaws.
Blah blah blah (Score:3, Insightful)
Studies also conclude that lunixes is a big intellectual IP property ripoff doomed to failure, laptops will completely replace desktops in ten years, and piracy is a really big problem that's sending business after business into bankruptcy.
It's wonderful how you can release any anecdotal evidence from a limited perspective as a marketable 'study'.
I'm releasing a study on how interest groups posing as reputable and productive companies pass bullshit around like the flu.
Re: (Score:2)
Re: (Score:2)
It's not as exciting to be fair, and if all studies were fair and perfectly concluded there'd be a lot less news on the slashfront I think.
Apples, oranges, or bananas? (Score:5, Informative)
They also forgot to have a proprietary package -- so the comparison is between open source packages. They might as well say, "Proprietary software poses a security risk. We've evaluated
Re:Apples, oranges, or bananas? (Score:4, Insightful)
No, if anything, these packages aren't unrelated enough to get a good cross section of FOSS. They're mostly web app-related thingys that are tied into Java. I haven't heard of most of them, probably because I stay strictly away from Java.
Parent
Re: (Score:2)
You may, but much of the enterprise web development world doesn't. Sorry to break it to you, but PHP really isn't that popular in massive corporation websites. Regardless of the quality of this review, Fortify is a fairly well entrenched security code analysis tool that many corporations use. I would say a number of Fortune 500 companies who use Java that had security analyses done at my former employer, but that is confidential.
Re: (Score:2)
I don't use PHP either. And I do work under a Fortune 500.
WTF (Score:3, Funny)
Re: (Score:3, Funny)
Yes, Mr.Strawman, I'm sure they do.
Hmmm... that got me thinking.
Straw man + flamebait = ??? (think of an ultra flamable scarecrow)
Where to start... (Score:5, Informative)
FTFA:
The projects in question:
Tomcat, Derby, Geronimo, Hibernate, Hipergate, JBoss, Jonas, OFBiz, OpenCMS, Resin and Struts.
For those who don't play in Java often:
Derby is an embedded database.
Tomcat, Geronimo, JBoss, Resin and JOnAS are Java (EE) app servers.
Hipergate and OpenCMS are (you guessed it) content management systems.
Hibernate is a persistent framework.
Struts is a web framework.
So of any of these, it seems that the only projects that would be open to XSS or SQL injection would be the CMS products. Unless they're referring to the web administration for the app servers?
The only way to have SQL injection attacks in javaland is if you're not using prepared statements or if your database driver isn't preparing/escaping properly.
So they're saying two CMS projects have tens of thousands of XSS and SQL injection vulnerabilities?
Re:Where to start... (Score:4, Insightful)
I wonder how they're counting. They quote says across "multiple versions". Are they giving multiple counts for a single vulnerability that exists in multiple versions?
Parent
Re:Where to start... (Score:5, Interesting)
You're just on the edge, I suspect, of the reason they didn't get good responses from the maintainers of the code for the "vulnerabilities" they reported. That's because, in most cases, they probably weren't vulnerabilities. The authors of the report are the producers of a static analysis tool that -- you guessed it -- detects potential XSS and SQL injection vulnerabilities. Of course, it (like all such tools) has a very high false positive rate.
In the case of code that automatically generates SQL code algorithmically (not using hard-coded prepared statements, for example) like Hibernate, or generates HTML code algorithmically (like, say, pretty much any JSP implementation or templating language), the number of false positives is going to be huge.
Any bets they didn't bother stripping out those false positives before reporting the "vulnerabilities"?
Parent
Java/Apache heavy? (Score:4, Insightful)
Is it just me, or is this survey extremely Java heavy?
Not only that, but there are a good number of Apache projects in particular... Apache Tomcat [apache.org], Apache Geronimo [apache.org], Apache Derby [apache.org], Apache Struts [apache.org]...
Re: (Score:2)
Java-focused (Score:2)
Yes, it's Java-heavy. The study author sells a proprietary static analysis tool for Java. So the Java bias is understandable, but their title should have made it clear that they were only analyzing a few Java programs, and not a representative sample of major OSS projects. They also ignored the enterprise support options for these programs, which is completely unjustifiable.
I think its Java bias matters. Until very recently, most Java programs required Sun's proprietary Java implementation. The FSF an
Re: (Score:2)
I've only used Tomcat. The others I've only run across while looking up information at work.
Re: (Score:2)
I don't know how much traction Geronimo or Derby have got now, but Struts, Hibernate, Tomcat, and JBoss are very popular, Resin and Jonas less so. The others I haven't heard of, but judging by their names OpenCMS and OFBiz are probably a bit outside my field so may be popular within their own field, and hipergate sounds like it might be a fork of hibernate, but a quick google shows it is actually a CRM ser
Re: (Score:2)
Not paying much attention to the Web Services arena, are these some of the most popular Java projects?
Yes. Judging by the recruitment adverts I see, Tomcat+Hibernate+Struts is probably the most common combination of server & frameworks for new Java-based web projects right now. The others are pretty close, though. I'm surprised they missed out Spring, but that's a more generic and not web-biased framework. Also, it's probably not particularly susceptible to static analysis, as it does most of its wo
Did MS get their receipt for this study? (Score:3, Insightful)
This is a weak article about a specific set of open source projects designed to keep CIO's and CTO's from jumping off the Windows turnip truck.
FUD... it's what's for dinner.
Biggest security risk of Open Source Software (Score:4, Interesting)
Re: (Score:3, Insightful)
I got that impression too. Have you ever tried calling Microsoft support? By the time you actually get a qualified person to answer your question, you could have received 2 - 3 responses on a OSS project's forum or mailing list.
Another interesting thing that I saw the study fail to mention, there are many OSS projects that clearly state on their web site "This is not yet production quality, use at your own risk" .. yet anyone selling something new would not dare to issue such a warning.
I really feel like th
Enterprises and governments before the people (Score:2)
"security practices need to improve because open source adoption by enterprises and governments is growing"
So these fortify people think security has to improve not because of the adverse effects it can have on users at large, but specifically because of the adverse effects on enterprise and government.
Oh yea, thats the reason i donated my time the open source community, to help enterprise and government. After all, they are all about helping the people. I never did it to try help the little bloke. /sarcasm
HAHAHA! (Score:2)
Have you voted yet? Apparently, about 80% of the readers of that article "doesn't get it", and votes the opposite of what the article is trying to push across....
Re: (Score:2)
I wonder if it's because the last times studies were done on those it was found that they were far more secure than closed source software, in a US GOVERNMENT FUNDED STUDY
The problem with that is you think that the government is going to be unbiased. Granted, the government isn't on the payrolls of Red Hat or Microsoft, but wouldn't it be in the government's best interest to use open source software that is a lot easier to audit and a ton cheaper? I'm not saying that they are wrong, but the government does have a lot of reason to mess with the statistics to their own favor.
Re: (Score:2)
We don't really know which way they're going to be biased, though. They could swing for closed source (if Microsoft's lobbists are going on a spending spree this week) or for open source (if it's Red Hat lobbists turn to do the same). The US government is also easily big enough to produce conflicting information due to different departments working on the same problem.
However, I maintain that the funding of the study is ultimately irrelevant. If the method is correct, and the data is correct, and the logic
Re: (Score:2)
Is obviously to do a study on software no-one's EVER heard of.
To be fair to the report's authors, if you're a Java web app developer (which is their target audience, as they're trying to sell a Java web app security analyzer) you probably recognize most of these projects. Derby was the only one I didn't know.