Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#45 Server security vulnerability with malformed XML packet

0.55
closed-fixed
Martin Kutter
Parsing (10)
9
2007-10-02
2004-04-12
Jon Kliegman
No

A malformed XML packet sent to a a SOAP::Lite server
can cause XML::Parser to abort with an error. The
problem is that the next request to that same process
will process the last sucessful request a second time,
returning it to the second caller.

Example flow:

Caller makes SOAP Request A
Server Processes Request A
Caller receives SOAP Response A

Cracker sends malformed XML packet
Server returns XML Parse error

Cracker makes SOAP Request B
Server Processes Request A
Cracker receives SOAP Response A'

The major security hole would be if Request A was a
login or other secure operation. If it returned a login
cookie/token, then the Cracker would have full access
to the users account.

The problem occurs because a specific class of
malformed XML packets cause the Final handler not to
be called when the parser aborts. As a result, the
SOAP::Parser object is not properly cleaned up after the
bad packet. The next packet received by the server
process will return the parse return the parse tree for
the last sucesful decode operation rather then for the
current packet. Future requests will be handled normally
as the Final handler is still called even though the wrong
parse tree is returned.

There appear to be two problems here:
1 - SOAP::Parser is not properly cleaning up for certain
malformed XML packets (other malformed packets do not
cause this behavior)
2- The server process is retaining a copy of data from
previous requests. This means that even closing this
current hole may leave others open.

I have a patch which solves problem #1 -- a change to
SOAP::Parser::decode to catch an exception and call
the Final handler to clean state. It is not in the same
style as the current code (unfortunately) and could be
compressed to fewer lines but we needed something
quick to address problems are users were having.
----------------------------
# diff -u Lite.pm.orig Lite.pm
--- Lite.pm.orig Wed Apr 7 23:16:58 2004
+++ Lite.pm Sun Apr 11 19:05:18 2004
@@ -1255,7 +1255,15 @@
End => sub { shift; $self->end(@_) },
Char => sub { shift; $self->char(@_) },
);
- $self->parser->parse($_[0]);
+ my $ret = undef;
+ eval {
+ $ret = $self->parser->parse($_[0]);
+ };
+ if ($@) {
+ $self->final; # Clean up in the event of an error
+ die $@; # Pass back the error
+ }
+ return $ret;
}

sub final {
----------------------------

I have not examined the ability to fix point two where
data from previous operations remain in the server
memory.

There are mitigating factors here:
- If clients are required to use the SOAPAction header,
then the both Requests must be for the same method or
the server will abort with an error (SOAPAction shall
match 'uri#method' if present).
- In a real deployment enviornment, it will be difficult
for a malicious user to ensure that they hit the same
process they sent the malformed packet to. While it will
still cause incorrect behavior, it reduces the ability of a
malicious attacker to compromise a specific account.

I have deliberately avoided posting an example of the
malformed packet here as this is an open forum and I
don't want to enable an attacker. I do have a pair of
simple perl scripts (one client, one server) which have
been able to reproduce this problem 100% of the time
and will provide them if asked (either publically or
privately).

Here are the system details that this problem occurred
on:
- Redhat 7.3
- SOAP::Lite 0.55 (from CPAN)
- perl-XML-Parser-2.30-15.rpm (from redhat)
- expat-1.95.2-2.rpm (from redhat)
- apache-1.3.27.4.rpm (from redhat) (not necessary for
reproduction - the problem is reproduceable using the
standalone HTTP server)

Please let me know if there is any other information you
need on this.

Discussion

  • Byrne Reese
    Byrne Reese
    2004-09-27

    Logged In: YES
    user_id=28043

    Suggested patch incorporated. Still have not addressed
    vulnerability.

     
  • Martin Kutter
    Martin Kutter
    2007-10-02

    Logged In: YES
    user_id=884175
    Originator: NO

    Closed, as Byrne already applied the patch a few years ago.

     
  • Martin Kutter
    Martin Kutter
    2007-10-02

    • priority: 5 --> 9
    • assigned_to: byrnereese --> kutterma
    • status: open --> closed-fixed