Open Source Security - A PHP Tale

For a long time a lot of us believed that open source systems had superior security to vendor products. Part of this is that we could look at the source code and configs, and historically open source projects took security more seriously than closed source vendors. However, as security has become an increasing concern to businesses and as attackers skill increases it has proven not as easy for open source to keep up. Some closed source vendors have begun taking security more seriously. Believe it or not, some people don't think that finding and fixing security bugs is as fun as developing new features. PHP is the latest example, Stefan Esser leaves PHP Security team:

The reasons for this are many, but the most important one is that I have realised that any attempt to improve the security of PHP from the inside is futile. The PHP Group will jump into your boat as soon you try to blame PHP's security problems on the user but the moment you criticize the security of PHP itself you become persona non grata. I stopped counting the times I was called immoral traitor for disclosing security holes in PHP or for developing Suhosin.

For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.

Unfortunately this is not the first time we have seen this. I have also seen this trend on several other very widely used open source packages, where friends and colleagues tried to spearhead security efforts, but could not generate sufficient interest in fixing security bugs as opposed to slamming new features. Certainly this is not the case in all projects, but it is more widespread than most people think. Andrew van der Stock:

PHP must now mature and take on a proper security architecture, an over arching security model which prevents or limits attack surface area until the application explicitly asks for it. There can be no other way. If you look at Bugtraq, every day, 10-50 PHP applications are broken mercilessly. This cannot continue. Hosters cannot pay the price for the PHP development team’s lack of security expertise.

Stefan Esser:

I’m now basically convinced that there is just no point trying to make PHP safe. The people involved are too poisonous and arrogant to change, therefore PHP will not change and become safe. My architecture would be attacked viciously but nothing would be done to put something like it in place. And without a decent architecture (mine or someone else’s), PHP is no safer than it is today, which is to say - not safe at all unless you know what you’re doing and can control php.ini, something most shared host users do not have the luxury.

Technology evolves at a rapid pace. This means that our assumptions have the shelf life of a gallon of milk and must be updated regularly. It is even more so in the security space, because it is not human against machine, it is human against human. Assumptions are context for decision making, but they are not necessarily reality. I mean a few years ago, would you have bet that SQL Server's security would out perform Oracle's?

I don't think Microsoft upgraded their SDLC and took security more seriously because it was fun, rather I think they listened to their customers and dealt with the issues. I suspect Oracle is going to do the same thing. What role does the market and customer relationship in general play in open source? What will it take beyond technical coolness for open source to again take a leadership position in security?

Comments

[James]

Liferay Enterprise Portal has already jumped on the security bandwagon and is miles ahead of its closed source competitors. Maybe if security folks started amplifying the products that are built on sound security practices then things would get better.

[Gunnar]

Right, there are a number of cases where open source is ahead, but it is not automatically ahead of closed source in all cases. For example, while MS is hiring every security person they can find, security people are bailing out of PHP for lack of support. Look at how many people work on Apache project? How may work on mod_security and mod_proxy?

[LonerVamp]

Good post. I think open source has peer review which can "out" issues with the code more quickly. But closed source has more economic incentive to incorporate security.

Stefan's story is felt beyond pro bono open source projects and is part of any security team's experience in the corporate space. Trying to bake security into a process is largely met with lots of dislike and even hate...until management buys in or an incident pressures the stakeholders or money coffers.

I feel that as long as technology is moving at this rapid clip, trying to get security to catch up is a nearly futile effort. Everyone wants features and functionality, not "limiting" security. Security is best adopted with established technology and operations and processes. In the end, almost everyone would rather get something done, than jeopardize getting it done but with security added in. :(

I posted more thoughts a few days ago on Open Source in my link.

[PHP Developer]

"The people involved are too poisonous and arrogant to change, therefore PHP will not change and become safe."

This statement is by Andrew van der Stock of OWASP, not Stefan Esser. The poisonous, arrogant attitude he is referring to is Stefan Esser's.

Stefan's departure from PHP is a good thing, and his public reasons for unsubscribing from [email protected] are dishonest.

You did get one thing right. This isn't the first time we have seen this, but now that Stefan is gone, hopefully it's the last.

[Sam]

I have to agree with the anonymous PHP developer, Gunnar: Stefan Esser has a history of being profoundly negative, hostile, and self-aggrandizing, so I am not surprised to see him pack up and take his marbles home. He has made spot-on observations and technical criticism of PHP security flaws, but I find that I have to run everything he writes through a "remove Stefan's vitriol" filter.

That said, I do agree that PHP needs a security architecture (I'm not sure what happened to Andrew's proposal; I'll have to ask him). Ease of entry for unskilled programmers is not completely to blame for PHP's security woes. (Likewise, a security architecture such as you find in Java or .NET is not nearly enough for developers to write secure software.) It's also clear that, as you have written before, the open source world is not keeping pace with changes in the security world in nearly the same way that Microsoft does. Near the heart of the matter is your question about the role of market and customer relationship in open source. I have no answers right now but would like to explore that further.

[Gunnar]

Sam: exactly. Customer demands drive a lot of what closed source vendors do. In many cases this involves said vendors developing lots of chrome. Fleeing this chrome is what drives a lot of us to open source.

But customers discover that they rely on their systems and don't like data to disappear or their SSNs broadcast on the web, and so they evolve. They start asking/demanding vendors do a better job with security. Some of the smart vendors like MS listen.

Now open source is not driven as much by this customer-supplier ethos. There ae lots of good things about not being totally customer focused, for one thing it gives way to systems like OpenBSD that can push the envelope on security, but what about general purpose open source like LAMP? They are not dealing with security on the same level as the leading edge closed source vendors and they are not innovating (or even learning from the innovations) like leading edge open source projects. So what drives these projects to improve their security? Microsoft has been hiring every security person they can for years. In open source it is fine to dismiss someone who leaves a project as a jerk, but where is the Plan B for security?