Blogxter: How to 0wn an OSS project, part 2.
How to 0wn an OSS project, part 2.
Mar 15, 2007 1:31:00 PM, steve

Previously, I looked at how to subvert an OSS project by attacking the compiler, the source, the artifacts or the mirrors.

However, there is another way, one that is recent, and which I don't think enough attention is being paid to. It's the documentation. More precisely, it is wiki-hosted documentation.

When a project's documents were static pages, they underwent the same editing and review process as for source: only a committer could update them. The result is that the barrier to entry for putting something malicious in the docs is on a par with subverting the source, so it is not worth the effort.

But now, everyone wants a community Wiki site to contain all the live docs, so that any user of a product is free to help maintain the docs. Unfortunately, that model is built on the assumption that the users are well meaning. To make it easy for well-meaning users to add wiki entries, to become an editor you need an email address. There may be some security and post-editing notification emails, but the overhead is designed to prevent automated spambots adding links, not someone with malicious intent trying to be subtle.

What is to stop me editing an httpd wiki to provide information about a security setting that makes it easy to run files? More subtly, what if I edit the Axis one and provide a code snippet that doesn't properly escape its incoming SOAP payload, so makes it easier to database injection. Anyone who uses that sample is making their system more vulnerable. Yet at first glance, it may not be an obvious problem, and the team would probably be grateful for the contribution, as it would appear to improve the documentation

I have no evidence that any OSS project has had its documentation subverted in this manner. Yet. I'm semi-tempted to attempt it on a project or two to see if they notice -a Tomcat servlet example that creates an XSS risk, an Axis sample that is vulnerable to SQL injection attacks. Create a disposable username/account, write some helpful pages, then, in between some good content, a malicious back door to cut and paste into your own server-side application. Not as direct as patching the code, but still potentially workable, especially if you can use a search engine to find live sites. Which, based on the happyaxis.jsp experience, is not that hard.

How do you stop Wikis becoming a new security risk, without restricting the editor base to trusted people?

(C) 2003-2006 1060 Research Limited
1060 Registered Trademark and NetKernel Trademark of 1060 Research Limited
Powered by Netkernel