Securing SOAP::Lite - Addendum
In my far from expert opinion, securing the open() call in HTTP::Daemon::ClientConn::sendfile would make for a more secure SOAP::Lite module.
Paul Kulchenko, SOAP::Lite's author dropped me a line last night asking what I meant by the 'unprotected open() in HTTP::Daemon being less of a problem', and what he should do to fix it.
Well, first let me state the obvious: if Paul fixes the module name traversal exploit in SOAP::Lite, a malicious user will no longer be able to call any loaded (by require) module from his remote code. It's thus far less likely that he will gain access to HTTP::Daemon::ClientConn::sendfile.
So why worry ? Because security works in layers. Fixing 2 holes is always safer than fixing one, you never know where the next exploit will come from.
Second: sendfile, as part of HTTP::Daemon, was authored by Gisle Aas. Gisle was one of ActiveState senior developers the last time I checked. Maybe he should get involved, if he's not already. He is no doubt far better qualified than I am.
Now what's wrong with sendfile after all ? Our friend 'stealth' has noticed that it makes a straight call to Perl's open() function. Look at the code fragment he gives in his story :
$soap->call("X:HTTP::Daemon::ClientConn::send_file" => "|/bin/ps");
Scary. That's because, according to the Linux Secure-Programs-HOWTO,The perl open() function comes with, frankly, "way too much magic" for most secure programs; it interprets text that, if not carefully filtered, can create lots of security problems.
Problems like accepting pipes as input, which is a cracker's favorite trick to gain knowledge of a system operation.
The traditional workaround for this is to use sysopen() instead of open(), which gives more fine grained control on what the open logic does, closer to a C library open actually.
There are probably other more clever / modern ways of doing this. That's for Paul and Gisle do decide.
3:35:07 PM Google It!
|