RE: Composibility problems with refps

David,

My point is that if you have an intruder in the processing flow of an 
outgoing SOAP
message that is including an EPR that will result in a SOAP message back 
to the
originator of the EPR nasty stuff as a result, you are screwed regardless. 


What I was saying was that the pipelining hole you described, where stuff 
in the
outgoing message is not signed until the end, subjects the entire message 
to tampering
that cannot be detected.

What you are describing in the EPR "echo attack" case is only one form of 
vulnerability. 
If a hacker can inject code into the server system, both the client and 
server are vulnerable, period.

The interloper you describe could just as easily muck with any aspect of 
the outgoing message
in a manner that will be disadvantageous to either party. It could 
re-write the SequenceAcknowledgement
header thus causing the other endpoint to resend messages that have 
already been received, or
causing messages not received never to be sent. It could change the body 
of the message
so that instead of a credit of 100USD it was a debit.

What I don't understand is why you think that just because WS-A includes 
as part of its
processing model the echoing of EPR props/params as SOAP headers that 
makes it somehow special with regards
to the security model and its application to outbound messages. 

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"David Orchard" <dorchard@bea.com> wrote on 11/24/2004 05:37:03 PM:

> As you are a smart guy, I'm not sure how many different ways I can say
> the same thing to the "I don't get it" response.  I don't think you are
> purposefully diverting from the issue.  I'll try to explain again.
> 
> The hole applies to SOAP headers only because ref params and properties
> are echoed as soap headers.  The hole can only be taken advantage of
> because of the current design of refps which requires that refps are
> echoed as soap headers.
> 
> For example, a hacker cannot do something with WS-A in the EPR sender's
> pipeline that would cause the EPR receiver to echo a particular <body>,
> because EPR RefP echoing does not permit echoing of <body>. 
> 
> The hole I am talking about is where:
> 1) A client and server have a legitimate interface contract
> 2) The contract allows a client to send a transfer header to the service
> 3) The client and server exchange EPRs that the client uses to invoke
> services.  The server mints EPRs that the client then uses to "callback"
> 4) The hacker inserts code into the server system.  The hacker code
> inserts a transfer header as a refP into an EPR that is sent to the
> client. 
> 5) The client then blissfully echoes the transfer header and the service
> executes it as if the client had *really* requested the transfer header.
> 
> This hole is caused by: a contract that is a valid use of soap headers,
> a valid use of EPRs, and the WS-A processing model that requires Refps
> to be echoed as headers.  There are a variety of solutions to this
> "hole", including requiring that RefPs are echoed in a "wrapper" header
> block, so that the hacker can't maliciously make the client invoke
> legitimate header blocks.
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> > Sent: Wednesday, November 24, 2004 2:18 PM
> > To: David Orchard
> > Cc: Francisco Curbera; Martin Gudgin; public-ws-addressing@w3.org;
> public-
> > ws-addressing-request@w3.org
> > Subject: RE: Composibility problems with refps
> > 
> > Dave,
> > 
> > The "hole" you describe with pipelining applies equally to all SOAP
> > headers and the SOAP body as well. It is not constrained to
> > ref props/params. I don't understand what the issue is really.
> > 
> > Cheers,
> > 
> > Christopher Ferris
> > STSM, Emerging e-business Industry Architecture
> > email: chrisfer@us.ibm.com
> > blog: http://webpages.charter.net/chrisfer/blog.html
> > phone: +1 508 377 9295
> > 
> > public-ws-addressing-request@w3.org wrote on 11/24/2004 04:13:41 PM:
> > 
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> > > > Sent: Wednesday, November 24, 2004 11:58 AM
> > > > To: David Orchard; Francisco Curbera
> > > > Cc: Christopher B Ferris; public-ws-addressing@w3.org
> > > > Subject: RE: Composibility problems with refps
> > > >
> > > <snip/>
> > >
> > > > > I think it's just a) because b) is done by default in most
> > > > > cases, where
> > > > > the security stuff just signs whatever it's given and it's at
> > > > > the end of
> > > > > the pipeline - like Rich showed.
> > > >
> > > > But your still talking about comprimising the pipeline itself.
> It's
> > > not
> > > > an attack someone could mount on the wire.
> > >
> > > Depends if the pipeline is "on the wire".  The pipeline compromise
> could
> > > be within single node or cluster, but the pipeline could also be "on
> the
> > > wire".  One node might construct part of the message, another node
> might
> > > construct another part of the message, and another node might apply
> > > security.
> > >
> > > >
> > > > >   Very few systems that I've heard of
> > > > > have the software that generates message content (particularly
> EPRs)
> > > > > secure it right away - which would prevent the hole that I'm
> talking
> > > > > about.
> > > >
> > > > I'm not sure what you mean by 'right away'. Do you mean before it
> > > first
> > > > appears on the wire? Or while it's in the processing pipeline?
> > > >
> > >
> > > Right away as in just b4 being put in the pipeline or the immediate
> next
> > > step.  One way to prevent this attack would be to secure any EPRs
> before
> > > they were put into the pipeline.
> > > > >
> > > > > And it's not inserting into arbitrary parts of the message,
> > > > > it's just in
> > > > > an EPR.
> > > > >
> > > > > So, the hacker would have to be able to:
> > > > > a) inject arbitrary XML into EPR(s) in a message.
> > > >
> > > > I'm confused. Are we talking about seuring the
> wsa:EndpointReference
> > > > element? Or the headers which are inserted into a message? Or
> both?
> > > >
> > >
> > > I think both but I'm mostly concerned about headers.  WS-A defines 2
> > > headers that use EPRs, but other specs, like WS-Eventing,
> > > WS-ReliableMessaging, and WS-Coordination, use EPRs as well.  These
> all
> > > have the same vulnerability.
> > >
> > > > >
> > > > > And this problem is prevented in WS-A by requiring that REFps
> are
> > > not
> > > > > echoed directly and unmodified as soap header blocks.
> > > >
> > > > I'm not sure how this helps plug the security hole.
> > > >
> > >
> > > If the RefPs are echoed in a wrapper, then they aren't soap header
> > > blocks  - which I know you think is a big bug.  The header extension
> > > could be
> > > <header><transfer>
> > >
> > > And if the echoing is in a wrapper, like
> > > <header><RefP><transfer>
> > >
> > > Then the transfer header extension can never be set by the WS-A
> echoing
> > > processing model.  By putting the RefPs as a wrapper, the hacker
> can't
> > > get the echoer to invoke the soap header block functionality.  Thus
> the
> > > security hole is plugged.
> > >
> > > > >
> > > > > It seems hard to quantify the risk of this.  One approach is
> > > > > to say "oh
> > > > > well, so sad".  Another approach is to do some work in a spec
> > > > > to prevent
> > > > > the problem.
> > > >
> > > > I'm still not quite seeing exactly what that problem is.
> > > >
> > > > :-(
> > >
> > > :-( indeed.  I was hoping by now we could at least agree: 1) there
> is a
> > > hole and 2) there is at least 1 solution to the hole.  Then we can
> > > debate 3) the cost/benefit of plugging the hole, depending upon the
> > > solution.  Until we get to 1 & 2, we can't really debate 3.
> > >
> > > Dave
> > >
>

Received on Wednesday, 24 November 2004 23:55:00 UTC