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?
