open source software discussion in Gov, to include: - Free, libre, open source software - Creation of OSS by the gov - open standards
Open Source Vulnerabilities
March 29, 2012 at 7:05 pm #157506
Not sure that I would put an overwhelming amount of faith in this study without a careful analysis of the study... Aspect Security is in the business of providing security consulting services...
From Network World:
Open source code libraries have a significant number of security vulnerabilities, according to an Aspect Security study that analyzed 113 million software downloads from Sonatype's Central Repository of more than 30 Java frameworks and security libraries over the previous 12 months.
The researchers found that 26 percent of the library downloads had known security flaws, including flaws that existed in Spring, an application development framework for Java. The vulnerabilities, which existed in Spring's use of Expression Language, could be exploited by attackers using HTTP parameter submissions to obtain sensitive system data as well as application and user cookies. Other vulnerabilities varied from flaws that could be used to completely take over the host using the library to flaws that could result in the loss or corruption of data if attacked. In addition, the researchers found that the most popular vulnerable open source libraries were Google Web Toolkit, Apache Xerces, Spring MVC, and Struts 1.x.
March 29, 2012 at 7:49 pm #157518
My team has performed static source code security analyses (SSCA) on a number of Open Source frameworks and libraries over the past four years and the IRS has an ongoing Open Source Software (OSS) organizational initiative in conjunction with the IRS Java Community Of Practice (JCOP), all supporting our CTO's desire to move us to a standard programming language. We also work with Aspect, as well as other such firms and are using IBM's AppScan Source as a SSCA tool for all IRS code writers and my team in Cybersecurity. We have used/are using such additional tools for SSCA as Fortify, FindBugs, FxCop, etc.
Our experience has been in line with the Aspect report. The larger problem is how to deal with the fact of OSS vulnerabilities and library changes that may impact business functionality. In order to avoid the "out-of-phase" problem, we have adopted a schema whereby we use the OSS unchanged, but with an accompanying Software Risk Profile that describes the secure code constructions that must be used by the "including" code to mitigate the insecurities found within the "included" code. We also work to reconcile our corporate needs with the copyright and license restrictions used in the various frameworks and libraries, since OSS is usually both copyrighted and proprietary.
Jim Lindley, Team Chief, IRS Penetration Testing and Code Analysis
March 29, 2012 at 8:50 pm #157516
So, as we use the terms here in Defense, OSS is usually copyrighted, but never proprietary.
Open source means that you have the right to modify the software and/or the right to hire anyone to do so on your behalf. Proprietary means that you do not have that right and only the vendor can modify the code. How can anything be both open source and proprietary?
Q: Does IRS work to notifiy the OSS projects of the defects found and get them fixed? This is something we have tried to promote at DoD, and certainly DHS's HOST program has been very proactive in this regard. (c.f. http://www.cyber.st.dhs.gov/host/) It seems wasteful to work to identify weaknesses in your supply chain and not attempt to address them.
I have to agree with Henry: it's hard to put much credence into a study by a security consulting firm that recommends spending more money hiring security consultants.
March 29, 2012 at 9:51 pm #157514
To us, Open Source means you have the source code. The code will usually have a copyright notice in one of the several copyright schemas available, but even without a copyright notice, a creative work is copyrighted by its creation. Where the proprietary hook occurs is that the code may also have a license statement included, which states the terms under which the copyright holder (proprietor) permits the source code to be used. The licenses I have seen vary greatly, all the way from "best of luck if it doesn't work" to "no changes may be made to this code" to "any changes you make must be shared with a community". The copyright and the license are different things and the license controls. So source code copyrighted under what may be considered a loose "standard" may be more tightly restricted by the license offered by the proprietor.
As for code security quality, open source code varies greatly. When you have code creation and support ranging from the very professional organizations like Apache to a grad student from Ghent who writes one of the most commonly used PDF generators on a "good luck" basis, it could hardly be otherwise. Once again, the devil is in the details of which code you're analyzing.
As for notifying the source code creators of insecure constructions, one of the reasons we track the license specificity is to meet the license requirements for creator notification. But since our approach is to work with the open source code regardless of its insecurities and to acept the burden of ensuring that our own "wrapper" code mitigates any included weaknesses, we don't have any general program of creator notification.
And our policy here is that no vendor security assertion is accepted without supporting evidence and a due diligence confirmation by us.
March 30, 2012 at 2:24 am #157512
Open Source only works as a community. If nobody is helping to update the code, then the code won't improve and will continue to have flaws.
With GitHub, there's an ability to raise issues with code in order to let the author know there's something the matter. There's also an ability to clone the code, correct it, then push it back to the master list. Tools like this only work if there's a community dedicated to improving the code.
March 30, 2012 at 2:38 pm #157510
When I wrote DoD's guidance on Open Source Software, my early drafts explicitly referenced the Open Source Definition(OSD), as promulgated by the Open Source Initiative(OSI), and moreover referenced the list of OSI-approved licenses. Alas, General Counsel felt this was an improper endorsement of a non-federal entity, and they made me take it out. (I still think they were wrong, but I got tired of arguing the point.)
But the OSI and OSD are pervasive in industry; I think most folks today would not consider software to be Open Source just because you have the source code. Microsoft will give you the code to Windows if you ask nicely enough, but that doesn't make it Open Source. I believe an essential element to OSS is the ability to fix it, and if necessary, fork it.
Instead of referencing the Open Source Definition (which is too long, anyway) we wrote a condensed version which was this:
Open Source Software is software for which the human-readable source code is
available for use, study, reuse, modification, enhancement, and redistribution by the users of that software.
There is clearly a wide range of quality for both OSS and proprietary s/w. I would never say that "OSS is more secure" because there is plenty of crappy open-source software out there. (I've written some of it.) But it's important to note that there is a wide range of quality to proprietary s/w also. (Even from generally well-respected vendors.) So the only useful thing I could say about Open Source Software was this:
The continuous and broad peer-review enabled by publicly available source code supports software reliability and security efforts through the identification and elimination of defects that might otherwise go unrecognized by a more limited core development team.
Which is to say, that with many eyes, all bugs are shallow. But Christopher's point below is well taken; this works for Linux and MySQL and Firefox which have millions of users. Not so much for DBD-QBase-0.03, which hasn't been updated since Nov 1995...
March 30, 2012 at 3:32 pm #157508
I'll be the first to admit that I take a very, umm...narrow...view of open source when I say it's code for which you have the human readable source code. But that's because I'm in the business of source code analysis, so - if I have the source - I can do the analysis. But your other points about the wide variablity in Open Source Software definitions and quality are well taken.
Because the IRS has taken the position that we will not use federal tax dollars to support non-federal software development efforts and because our internal changes to OSS frameworks and libraries would make them "out of phase" with the generally available public releases (thus necessitating a rework every time the framework or library was publically updated), we have decided to simply catalog the insecure constructions (and lack of some business functionality) and then add wrapper code that mitigates the included insecurities and, perhaps, expands the business functionality. That way, we don't spend federal resources on code development not directly related to federal purposes. I realize that other federal agencies have taken other paths and I'm not arguing that ours is the one I would choose if I controlled the resources. I have belonged to a number of open source initiatives in the past, going all the way back to Remote Bulletin Board Service (RBBS), when all the world was MODEM and CompuServe was it when it came to remote access. But I don't control, I'm simply in the business of exposing vulnerabilities in software.
You must be logged in to reply to this topic.