s l a m

today

articles
howtos
tools
reference

gnu/linux
os x
win32

security
scripting

groupware

Radio
Radio Docs
Frontier Docs

Wednesday, April 10, 2002

SOAP::Lite::Paul_Strikes_Back()
Dave directed my attention to Paul Kulchenko's answer to the full package name traversal exploit in SOAP::Lite. Read Paul's message in the soaplite group and the ensuing thread.
I suppose we'll get an updated package by next week. If Paul fixes the traversal vulnerability, the unprotected open() in HTTP::Daemon is less of a problem, though it would be better to fix it as well. Let's see if Gisle comes up with something.
I'm currently experimenting with SOAP::Lite (on a private network :-) to enable a source code formatting web service, which eventually will become part of s l a m. More on this later.

8:09:51 PM      Google It!

SOAP::Lite Exploit - continued
I took time this afternoon to read the SOAP::Lite exploit story in Phrack magazine volume XI issue 58. The author, who goes by the rather conspicuous handle of 'stealth', gives some details on how to get unauthorized access to system resources on a SOAP::Lite server. There seems to be several issues at hand.
First, 'stealth' notes that 'Perl allows functions to be called indirectly, no matter whether it is in tainted mode or not and the name/argument of that function is retrieved from outside or not.'
Well, that may be considered a feature, but the part about the function being retrieved from the outside in tainted mode is a problem.
Second, he notices that it is possible to 'breakout' of a package used as a SOAP::Lite handler by passing a full package name to the $method property of the package. 'stealth' being a Phrack contributor, the POSIX::system() package comes spontaneousIy to his mind.
I haven't tried to replicate this, but SOAP::Lite author's probably should. If confirmed, it's a serious weakness in the package.
Third, 'stealth' finds out to his delight that the SOAP::Transport::HTTP module requires the HTTP::Daemon module, which happens to include an unprotected open() call in the send_file method of HTTP::Daemon::ClientConn.
That's another bad one, but it's relatively easy to fix. I guess it comes under the bailiwick of Gisle Aas, author of the HTTP::Daemon package.
To wrap this up, I'm not sure I'd be able to gain 'instant shell access on any box which runs SOAP::Lite based server', as IlyaM writes, at least if the Perl code is run in tainted mode.
But the full package-name traversal and unprotected open call are bad enough, it means any function from any internal daemon running on the server may be accessed externally.
'stealth' may be pointing to a solution in his conclusion:
A way might be to put all allowed classes and function-names into a hash and look whether the received string is contained there. Frontier XML-RPC module for Perl does it that way, it has a hash of methods it allows like
my %funcs = ('callme' => &sub1);
where you may only call 'callme' function. You can try to call other functions until your face turns into green, you won't succeed.
SOAP::Lite's Paul Kulchenko has been alerted by IlyaM last week, more information is probably developing as I write this.

5:36:05 PM      Google It!

Dave Simpson Oops, it's past breakfast time in NYC, and s l a m 's referers list is already growing faster than I can hit the Refresh button. So much for anonymity... I know of only one person who can cause such a phenomenon...

10:14:41 AM