T> direct access to fully qualified package names and thus arbitrary
T> commands can be executed on the remote machine.

T> How can we stop such attacks?

I've sent Paul private email with source code of exploit I've wrote
but I haven't got any response yet.

For now you may try to use this patch (diff against latest
SOAP::Lite). It is 'unofficial', I haven't tested it too much but it
does seem to protect against attacks which use fully qualified package
names. It least it seems to stop my exploit.

Of course there is NO WARRANTY that it does fix a problem or that it
doesn't cause any damage.

Hi, Ilya! Yes, this patch may work and thanks for bringing this up. ... I m offline since Saturday and will have only occasional online access till the end of

Message 6 of 9
, Apr 9, 2002

Hi, Ilya!

Yes, this patch may work and thanks for bringing this up.

> I've sent Paul private email with source code of exploit I've wrote
> but I haven't got any response yet.

I'm offline since Saturday and will have only occasional online
access till the end of this week. I wasn't aware about the
possibility of using phrack's exploit in such way, yet it seems like
it shouldn't work with -T option used on server side. Unfortunately
-T option doesn't stop you from using $object->$method() even if
$method string is tainted, which allows accessing already loaded
modules.

To disable it on server side you may use on_action handler:

->on_action(sub { die "Access denied\n" if $_[2] =~ /:|'/ })

There is also patch that adds checking of method name against methods
and classes allowed in dispatch_to(). Will go into the next release.
Sorry for the inconvenience.

PK> access till the end of this week. I wasn't aware about the
PK> possibility of using phrack's exploit in such way, yet it seems like
PK> it shouldn't work with -T option used on server side. Unfortunately
PK> -T option doesn't stop you from using $object->$method() even if
PK> $method string is tainted, which allows accessing already loaded
PK> modules.

Well, I've just sent you private email with modified exploit which
does work even if -T option is used on server side.

I have access to two versions of SOAP::Lite, one is 0.46 and one is 0.52. I have found 0.52 to be vulnerable to the phrack exploit, yet 0.46 seems to perform

Message 9 of 9
, Apr 10, 2002

I have access to two versions of SOAP::Lite, one is 0.46 and one is
0.52. I have found 0.52 to be vulnerable to the phrack exploit, yet
0.46 seems to perform some type of validation and hence is not
affected by the exact problem. This is quite a good thing, as last
time I checked ActiveState was still shipping 0.46 with their
distribution and making no later version available via PPM.

When I try the exploit on a SOAP::Lite 0.46 server, I recieve the
following fault message in reply ( dumped via Data::Dumper's
Dumper($response->fault) )