Jon Udell says that “I’m sure Paul Kulchenko will soon fix the SOAP::Lite vulnerability that was just noticed.”

This is quite a strange tale. It discussed on the Perl-5-Porters list back in December. At that time the discussion centred less around SOAP, but about why Perl’s taint mode didn’t help.

For those that don’t know, this feature tells the language not to trust any data received from the outside world unless the author has taken steps to verify that that information is safe (usually through a regular expression, although there are a variety of tools that can help with the monotony of this).

Several orthogonal issues arose out of this. Firstly, in a language as dynamic as Perl, what exactly should you check – in this case the problem is down to resolving method calls at run-time based on possibly unsafe data, whereas previously taint had been used more for areas like I/O and executing other arbitary programs.

Secondly, and more imporatntly IMO, a change arose (not directly out of this but around the same time), to help with the gradual migration to taint-safe code. One of the areas in which taint mode is most useful, and most important, is in web-programming. When your forms are taking input from the big bad web(tm) you need to be very sure of what you’re doing with that information. But, if you’re running under mod_perl, taintedness is very much an ‘all or nothing’ across your entire application.

This causes problems if you come in late to a project that isn’t running in taint mode. It’s very difficult to bootstrap your way back into safe territory. You can attempt to migrate your code to a taintsafe approach (and abstracting all input processing to using a tool like that described earlier can help greatly with this). But you can’t actually turn taint on until you’ve found every last unsafe construct without risking your entire application blowing up at run-time (trying to do something unsafe with an unchecked tainted variable throws a fatal exception).

This issue has come up many times on the perl internals list, and it generally generates a lot of heat. Proponents of the current system point out that if you haven’t closed every possible problem case then your entire application can blow up in even more dangerous ways at run time anyway – you’re just relying on no-one else finding the holes before you. People in precisely this situtation, on the other hand, would point out that they’d like to move to a truly safe environment, but without being able to turn taint on an area at a time, it’s a very difficult path to take.

This time around however, we got a result. Larry Wall blessed the idea of taint warnings. From version 5.8 you will now have the ability to turn on a taint pragma which warns rather than dies when you attempt to do something potentially unsafe. In most cases this should alert you to the hole before someone passes something actually unsafe through it. So now (or at least soon, if you don’t run bleadperl), you can turn that on everywhere, watch for warnings, and when you’re comfortable that you should be clean, turn full taint mode on.

However. No-one then went back to the original problem. The SOAP::Lite problem remained. Possibly no-one ever told Paul about it. And then it raised its head again this week, 4 months later.

Jarrko, the current pumpking, had a wonderful response:

While it’s true that Perl strives to give you enough rope I sometimes wonder was it morally right to buy a whole sisal plantation.

This time, the loophole has been closed.

The story provides an interesting take on the open source approach to security. When everything comes together properly, as has often been pointed out, security works well. Holes can be closed quicker than the equivalent closed source world. But things don’t always come together properly, and attention can very easily be diverted elsewhere. Of course that “elsewhere” can often be very useful too :)