RE: Composibility problems with refps

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 22:37:08 UTC