Ounce Labs, a software risk analysis company, has uncovered two security vulnerabilities in the Spring Framework.
Considering how long Spring has been in use, and its popularity, how could such vulnerabilities remain hidden so long? After all, isn’t one of the hallmarks of open source the strong community vetting? Could it be that the shift towards single vendor-driven open source is making open source riskier?
What the Spring vulnerabilities are
Kudos to Ryan Berg, chief scientist and co-founder of Ounce Labs, and Ounce team for uncovering the issues and working with SpringSource to raise awareness.
According to Ounce Labs:
The specific vulnerabilities are “ModelView Injection” and “Data Submission to Non-Editable Fields.” These vulnerabilities allow attackers to subvert the expected application logic and behavior, gaining control of the application itself, and access to any data, credentials or keys held in the application.
If your applications use the Spring Framework, be sure to read FAQs from the SpringSource advisory and the Ounce Security Advisory.
The deeper question on open source vetting
Now, the reason this story caught my eye:
“As we put more and more trust into the frameworks that are the foundation of our applications, we need to make sure we understand the security decisions made so we can make the right implementation choices.”
Two key benefits of OSS are the ability to read and understand the code we use and that “many eyes scouring the code” makes the product more secure.
Considering the millions of downloads of the Spring Framework, should we have expected someone to discover these security holes earlier? Or do developers use what the next guy/gal is using, trusting that “someone” has done the due diligence?
How should we interpret the news versus the long-held belief of increased security as a result of “more eyes scouring the code”? Could that be a trait of merit-based OSS projects that isn’t likely to show up in OSS projects where a single vendor writes the code?
If developers outside the company can’t contribute code, what is the likelihood that a developer will look at a piece of code within the project and ask, “How can I make this better?” — and in the process uncover a potential security issue?
I’m really asking a fundamental question: Are merit-based OSS projects more secure than single-vendor-driven OSS projects?
Thoughts?
PS: I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies or opinions.”
07.16.08 at 10:51 am
[...] Comments [...]
07.17.08 at 8:07 am
I’ve often run into the assumption that open source software is more secure because it’s been reviewed by the international community.
As you point out – that’s an assumption. Not all projects have an active community.
But is there a direct relation between community involvement (or lack-thereof) and single-vendor OSS? I don’t know. Would be great to gather up some statistical data and see if that points to a conclusion or not.
07.22.08 at 9:07 am
There’s a general lack of security awareness among developers working on “application frameworks”. Most of them think security is the domain of network administrators and basic infrastructure software developers (OS, web servers, firewalls). So I expect most application frameworks (Java-based or not) have not being scrutinized for vulnerabilities like, say, the apache httpd daemon.
If you read the Ounce Labs advisory, it looks more related to incorrect usage of the Spring Framework than a Spring bug per se. This increases the risk, because if few framework developers are security-aware, even fewer application developers are.
You’d be hard-pressed to find a web application anywhere that isn’t vulnerable to some form of script injection or SQL injection. Try to ask the regular developer to validade input from “free form” text fields or hidden fields…
I could point to severe security flaws from some closed-source application frameworks I’ve worked with (well, I actually cannot by contract) and from some open source ones. The more the “easy of use”, “autowiring” or “convention over configuration”, the more vulnerabilities. because the developer does not have to face the security implications. Time to market is all that matters, and security allways slow you down. Of course, I don’t have any scientific data on this, but I guess most security-aware developers will find the same trend.
So I don’t think the real issue is about “single-vendor” open source being riskier than “real community” open source. The real issue is a general lack of security from most app frameworks, and at least the open source ones allow us to freely talk about the issues and find workarounds or even fixes.
By the way, what is “single vendor” open source? Having a corporate sponsor like Spring Source or Red Hat is that bad compared to having a single “community” sponsor like the Apache Software Foundation or the Free Software Foundation? Would the ASF be a “single vendor” just like a comercial company?
07.24.08 at 10:54 am
Hi Fernando,
Great points!
When a project is single vendor driven AND the vendor does not accept outside committers, there is virtually no reason for a 3rd party developer to look at the code and think about how to make improvements.
I don’t want to single out any vendor, because today we’re seeing more and more open source equals “single vendor open source”.
I don’t consider the ASF to be single vendor because any vendor, and any 3rd party developer can contribute code to any project. The same is true for Mozilla, Eclipse and Linux projects.
12.17.09 at 3:09 pm
[...] Comments [...]