Loading ...
Sorry, an error occurred while loading the content.

Preventing package name traversal attacks

Expand Messages
  • theonetowhommyrefers
    There is an article at Use::Perl which discusses a serious security hole in SOAP::Lite - http://use.perl.org/articles/02/04/09/000212.shtml?tid=5 This article
    Message 1 of 9 , Apr 9, 2002
    • 0 Attachment
      There is an article at Use::Perl which discusses a serious security
      hole in SOAP::Lite -
      http://use.perl.org/articles/02/04/09/000212.shtml?tid=5

      This article is based on another article at Phrack:
      http://www.phrack.com/show.php?p=58&a=9

      From what I can tell the security hole is that autodispatch allows
      direct access to fully qualified package names and thus arbitrary
      commands can be executed on the remote machine.

      How can we stop such attacks?
    • Ilya Martynov
      ... T There is an article at Use::Perl which discusses a serious security T hole in SOAP::Lite - T http://use.perl.org/articles/02/04/09/000212.shtml?tid=5
      Message 2 of 9 , Apr 9, 2002
      • 0 Attachment
        >>>>> On Tue, 09 Apr 2002 17:24:48 -0000, "theonetowhommyrefers" <theonetowhommyrefers@y..> said:

        T> There is an article at Use::Perl which discusses a serious security
        T> hole in SOAP::Lite -
        T> http://use.perl.org/articles/02/04/09/000212.shtml?tid=5

        T> This article is based on another article at Phrack:
        T> http://www.phrack.com/show.php?p=58&a=9

        >> From what I can tell the security hole is that autodispatch allows
        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.

        --- /home/ilya/tmp/Lite.pm Tue Apr 9 21:27:07 2002
        +++ /usr/share/perl5/SOAP/Lite.pm Tue Apr 9 21:40:10 2002
        @@ -2068,6 +2068,11 @@
        ($method_uri, $method_name) = ($request->namespaceuriof || '', $request->dataof->name)
        unless $method_name;

        + # don't allow method names which contain package names
        + # i.e package::method or package'method (old deprecated syntax)
        + die "Denied access to method ($method_name)"
        + if $method_name =~ /[:']/;
        +
        $self->on_action->(my $action = $self->action, $method_uri, $method_name);

        my($class, $static);


        --
        Ilya Martynov (http://martynov.org/)
      • Tom Mornini
        ... Don t use autodispatch! -- -- Tom Mornini -- InfoMania Printing and Prepress -- -- ICQ: 113526784, AOL: tmornini, Yahoo: tmornini, MSN: tmornini
        Message 3 of 9 , Apr 9, 2002
        • 0 Attachment
          On Tuesday, April 9, 2002, at 10:24 AM, theonetowhommyrefers wrote:

          > There is an article at Use::Perl which discusses a serious security
          > hole in SOAP::Lite -
          > http://use.perl.org/articles/02/04/09/000212.shtml?tid=5
          >
          > This article is based on another article at Phrack:
          > http://www.phrack.com/show.php?p=58&a=9
          >
          > >From what I can tell the security hole is that autodispatch allows
          > direct access to fully qualified package names and thus arbitrary
          > commands can be executed on the remote machine.
          >
          > How can we stop such attacks?

          Don't use autodispatch!

          --
          -- Tom Mornini
          -- InfoMania Printing and Prepress
          --
          -- ICQ: 113526784, AOL: tmornini, Yahoo: tmornini, MSN: tmornini
        • David Wright
          What we need is a way to just turn off autodispatch at the server side.
          Message 4 of 9 , Apr 9, 2002
          • 0 Attachment
            What we need is a way to just turn off autodispatch at the server side.
          • Joe Landman
            ... More than that, you need some level of access control for the object. This should be done at the SOAP level before the object is ever called. Basically
            Message 5 of 9 , Apr 9, 2002
            • 0 Attachment
              On Tue, 2002-04-09 at 15:28, David Wright wrote:
              >
              > What we need is a way to just turn off autodispatch at the server side.

              More than that, you need some level of access control for the object.
              This should be done at the SOAP level before the object is ever called.

              Basically need to set up something like this

              %access_control_list = (
              'public' => qw(method1 method2 ... methodN class1 class2 ...
              classN),
              'restricted' => {
              'restricted_method1' => {
              'users' => qw(user1 user2 ... userN),
              'hosts' => qw(host1 host2 ... hostn domain1 domain2 ...
              domainN),
              'logging' => "logfile"
              }
              );
              SOAP::Lite->set_access_control('object' => 'name', 'acl' =>
              %access_control_list);

              Or something similar.

              >
              >
              >
              > To unsubscribe from this group, send an email to:
              > soaplite-unsubscribe@yahoogroups.com
              >
              >
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
              >
            • Paul Kulchenko
              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
              • 0 Attachment
                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.

                Best wishes, Paul.

                --- Ilya Martynov <ilya@...> wrote:
                > >>>>> On Tue, 09 Apr 2002 17:24:48 -0000, "theonetowhommyrefers"
                > <theonetowhommyrefers@y..> said:
                >
                > T> There is an article at Use::Perl which discusses a serious
                > security
                > T> hole in SOAP::Lite -
                > T> http://use.perl.org/articles/02/04/09/000212.shtml?tid=5
                >
                > T> This article is based on another article at Phrack:
                > T> http://www.phrack.com/show.php?p=58&a=9
                >
                > >> From what I can tell the security hole is that autodispatch
                > allows
                > 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.
                >
                > --- /home/ilya/tmp/Lite.pm Tue Apr 9 21:27:07 2002
                > +++ /usr/share/perl5/SOAP/Lite.pm Tue Apr 9 21:40:10 2002
                > @@ -2068,6 +2068,11 @@
                > ($method_uri, $method_name) = ($request->namespaceuriof || '',
                > $request->dataof->name)
                > unless $method_name;
                >
                > + # don't allow method names which contain package names
                > + # i.e package::method or package'method (old deprecated syntax)
                > + die "Denied access to method ($method_name)"
                > + if $method_name =~ /[:']/;
                > +
                > $self->on_action->(my $action = $self->action, $method_uri,
                > $method_name);
                >
                > my($class, $static);
                >
                >
                > --
                > Ilya Martynov (http://martynov.org/)
                >
                > ------------------------ Yahoo! Groups Sponsor
                >
                > To unsubscribe from this group, send an email to:
                > soaplite-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                >
                >


                __________________________________________________
                Do You Yahoo!?
                Yahoo! Tax Center - online filing with TurboTax
                http://taxes.yahoo.com/
              • Ilya Martynov
                ... 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
                Message 7 of 9 , Apr 10, 2002
                • 0 Attachment
                  >>>>> On Tue, 9 Apr 2002 23:38:16 -0700 (PDT), Paul Kulchenko <paulclinger@...> said:

                  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.

                  --
                  Ilya Martynov (http://martynov.org/)
                • Robert Taylor
                  Thanks, Paul and Ilya, for addressing this serious issue. ... This server side check works for me. __________________________________________________ Do You
                  Message 8 of 9 , Apr 10, 2002
                  • 0 Attachment
                    Thanks, Paul and Ilya, for addressing this serious
                    issue.

                    --- Paul Kulchenko <paulclinger@...> wrote:
                    > Hi, Ilya!
                    > ...
                    >
                    > To disable it on server side you may use on_action
                    > handler:
                    >
                    > ->on_action(sub { die "Access denied\n" if $_[2]
                    > =~ /:|'/ })

                    This server side check works for me.




                    __________________________________________________
                    Do You Yahoo!?
                    Yahoo! Tax Center - online filing with TurboTax
                    http://taxes.yahoo.com/
                  • give_me_a_donut
                    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
                    • 0 Attachment
                      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) )

                      'faultcode' => 'SOAP-ENV:Client',
                      'detail' => 'SOAPAction shall match \'uri#method\' if present',
                      'faultstring' => 'Bad SOAPAction',
                      'faultactor' => 'http://hostname:port/'

                      If anyone has further information on this, or has seen a working
                      exploit on this version, please let me know.

                      Regards,
                      Michael
                    Your message has been successfully submitted and would be delivered to recipients shortly.