use Perl Log In
Serious SOAP::Lite Security Hole Discovered
IlyaM writes "About four months ago there was Phrack article named RPC without borders which describes quite serious security hole in SOAP::Lite module. In short, SOAP::Lite allows to call any Perl subroutine on side of SOAP::Lite based server. Strangely enough it has gone mostly unnoticed and it hasn't been fixed. I've tried to research it further and wrote a simple exploit which instantly gives remote shell access to computer which runs a SOAP::Lite based server. It took me less than two hours to write this exploit. So assuming that security hole in SOAP::Lite have been known for a very long time, there is no reason to think that nobody else (i.e. blackhats) haven't done it."
This is a big one, and relates to how SOAP::Lite dispatches method calls at runtime, and how Perl executes dynamic method calls. The very best thing you can do is take down your SOAP servers until an update is available.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Calling all programmers. (Score:4, Insightful)
Casey West
Reply to This
Re:Calling all programmers. (Score:2, Funny)
XMLRPC::Lite, possibly Frontier::RPC (Score:3, Informative)
Part of the reason I wrote my RPC::XML at all was because I wasn't comfortable with the way that Frontier::RPC published functions simply by "redirecting" calls to a specified package name-space. I don't know that it would be vulnerable, but I suspect it probably is. I was also bothered by this aspect of SOAP::Lite when I started using it as well, but I lacked the bandwidth to try and roll my own on that count. I feel pretty certain (though not 100%) that the server classes in RPC::XML are not vulnerable to this. I don't route incoming calls to an arbitrary namespace, I use a method-table. If you don't have an engraved invitation, you don't get to dance.
So I'm doing the next best thing... joined up on the soaplite mailing list, am printing out the phrack article, and have in hand a sample exploit script Ilya was kind enough to send me. Looking forward to comparing notes with you guys tomorrow...
--rjray
--rjray
Reply to This
Re:XMLRPC::Lite, possibly Frontier::RPC (Score:2, Informative)
It was pointed out to me on perlmonks [perlmonks.org] that Frontier::Daemon doesn't behave in the way I thought it did; it, too, requires that methods be explicitly added. I thought I had seen an example of using it with a class-namespace dispatch configuration, but I can't find that now that I look for it again.
--rjray
--rjray
Patch (Score:3, Insightful)
Ilya Martynov (http://martynov.org/ [martynov.org])
Reply to This
SOAP::Lite (Score:2, Interesting)
NOTE TO SELF: When a user (especially an untrusted one!) gives you data that you expect to be in a particular format, CHECK THAT IT IS IN THAT FORMAT, FOR CHRISSAKES!
This whole thing would have been avoided if anyone had had, earlier on, the wits to do what Ilya M did, basically
die "BAD JUJU" unless m/\A[a-zA-Z][a-zA-Z_0-9]*\z/I say that unless Kulchenko shows up and immediately
Re:SOAP::Lite (Score:4, Insightful)
Reply to This
Parent
Re:SOAP::Lite (Score:1)
This mistake is common in other XML-RPC libraries I've seen. It's hard enough to make the durn things work in the first place, let alone get the security right. This bug can be fixed, although SOAP::Lite allows *a lot* of leeway in its dispatch method.
Some work is being done on the Frontier::RPC module(s). We'll have to look into this further.
Re:SOAP::Lite (Score:4, Informative)
I'm with you. I'm also astonished to find that it happened.
> CHECK THAT IT IS IN THAT FORMAT, FOR CHRISSAKES!
It's expected to be in that format. The reason for the problem is that method name wasn't verified against list of allowed methods when *class name is on the list of allowed classes*.
> MONTHS after this was mentioned in Phrack
Do you read Phrack daily? I don't read it at all. Randall brought it to my attention some time ago, and I was surprised to find later that it was discussed on perlmonks and nobody told me about that discussion. Unfortunaty with my schedule I'm only an occasional reader of use.perl, perlmonks and other perl sites.
> and ownership gets transferred immediately to someone else
Even though there is no such procedure, I wouldn't mind to know more about the person who would like to take this ownership.
I'm not trying to downplay the issue. It's my fault. In addition to that, it's probably the worse time for releasing a new version: I'm moving and have all my computers packed and shipped. I do have copies and repository with me, however I don't have my testing environment and only sporadic online access in my hotel. Still I plan to release bugfix by the next week. If you don't think it's reasonable, let me know.
Best wishes, Paul.
Reply to This
Parent
This is news? (Score:3, Insightful)
And while I'm posting mad, anyone that thought it was secure to run a public SOAP service on the Internet should get off the pipe. Villifying Paul for the total lack of security in SOAP is not cool. Yeah, sure, it was a bug in his code but everybody's code has bugs. If SOAP had a real security layer this kind of thing would be much less likely.
-sam
Reply to This
Re:This is news? (Score:1)
---ict / Spoon
Re:This is news? (Score:3, Insightful)
SOAP::Lite is free software. If you want a new release badly enough then you have every right to fork the module and release it yourself. However, impotent whining is not allowed.
-sam
Re:This is news? (Score:1)
C'mon: important security problem, you say he has a patch ready for the next release. It doesn't take that much effort to release, surely?
When was "Last I heard"? Last week? Last month? Last year?
---ict / Spoon
Likewise named code on CPAN (Score:2, Interesting)
I think you can.
The way I understand it, you can't overwrite his module, but you can realease your own module under a different name, and in that distribution include a version of SOAP::Lite that has patches fixed.
So I could upload a module called "MARKF::SOAP::Lite" and in that distribution also have a version of SOAP::Lite that I've fixed. Then from the CPAN.pm prompt when I said "install MARKF::SOAP::Lite" I'd get my version of SOAP::Lite a
Re:Likewise named code on CPAN (Score:2, Funny)
When someone patches it to require the coder to register SOAP-accessible subs, it could be called SOAP::Lightest.
eh?
-matt
Re:Likewise named code on CPAN (Score:2, Funny)
---ict / Spoon
Re:Likewise named code on CPAN (Score:2)
Why not, we have Acme::* :) ...but you have to put Fabio in there somewhere :)
Re:Likewise named code on CPAN (Score:4, Interesting)
Technically, you could do that but why be a buch of bastards? Any author can, at any time, upload any module as long as the distribution is not the exact same name as another. However, this is considered an act of assholery and at some point the module and possibly the author can and likely will be removed forcibly.
Plan B would be to email the modules@cpan.org list and ask, politely, what they would advise as a course of action. This is a serious security flaw in a reasonably popular module so chances are good that, if Paul doesn't pitch up, something may be agreeably worked out.
I wouldn't recommend doing the MARKF* solution as it's confusing to the end users and isn't the solution you ultimately want anyway.
In short, don't shit in your messkit unless you are fully prepared to eat fecal casserole for dinner.
Reply to This
Parent
Re:Likewise named code on CPAN (Score:2, Insightful)
What you'd have to do is make sure that you're not going to overwrite the default install of a module. By this I mean that when someone types "install SOAP::Lite" they better not get your version by default - that would be really wrong and bad, and as hfb says right royally kicked off of the CPAN. Your fixed module should only be there for the people that know about it and need it by typing the right
Re:This is news? (Score:2, Insightful)
I have a Net::Interface in my CPAN directoy,
even though I am not the official developer.
It appears to be abandonware and so I have
made a few updates. People still manage
to find and use it (probably more than my
other things), and you could always *publicize*
your version. It could then fade away gracefully
when deprecated.
I probably ought to look at snathcing Net::Interface, however I am not a C/XS
programmer.
Were that I say, pancakes?