RE: Composibility problems with refps

Martin,

Comments inline.  But the biggest one to call out is that I am not, nor
have I ever been, talking about "a rogue service".  I am talking about a
legit service.  A client and server talk legitimately and the transfer
header block is completely legal in their contract.  The point is that
the hacker in the server gets the client to send the transfer header
block by the EPR hack.  The client has effectively requested the
transfer by the simple fact that they followed the WS-A processing
model, when in fact they had no intention of requesting the particular
transfer.

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: Wednesday, November 24, 2004 1:29 PM
> 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.
> 
> And messages are sent *unprotected* between these 3 nodes?

Sure.

> 
> >
> > >
> > > >   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.
> 
> isn't this generally true of any portion of the message? If your
> pipeline is compromised somewhere, then securing the pieces that are
> compromised before the attacker can access them will help...

Yup.

> 
> > > >
> > > > 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.
> 
> Let me restate. Are you concerned about securing elements whose type
is
> wsa:EndpointReferenceType (e.g. wsa:ReplyTo, wsa:FaultTo )? Or the
> headers which result from reading such an element and using it to
> address a message?

I think more the 2nd, but I'm thinking my concern spans the distinction
you are trying to make.  I'm concerned about the headers which result
from following the WS-A processing model when an EPR is received.  

> 
> >
> > > >
> > > > 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
> 
> I don't see how this helps from a security perspective. How does this
> stop the EPR from being hacked?

Oh, the EPR can still be hacked.  But it won't be able to invoke the
legitimate <transfer> header block.  Thus the hole is plugged even
though the EPR can be hacked.
 
> 
> >- 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.
> 
> Oh, I see. We're back to the 'you could get me to insert a header that
> will allow you to empty my bank account' argument...
> 
> As I've previously stated, I really don't buy this argument. I
certainly
> don't think this problem is unique to WS-Addressing. Any piece of
> information a sender uses to figure out which SOAP headers to put into
a
> message is potentially subject to this attack; WSDL, policy etc.
> 

I'm not following.  WSDL and Policy are metadata and describe a
contract.  WS-Addressing has an explicit processing model.  Metadata and
an explicit processing model are very different beasts.  A hacker will
need some of the metadata about the interface for sure, but it's just
not the same as a processing model.

> >  Thus the
> > security hole is plugged.
> 
> I'm unconvinced that there is a hole to be plugged. If there is, I'm
> unconvinced that this approach plugs it. It seems to me that you are
> trying to protect against collusion between a hacker that modifies
EPRs
> before they arrive at a consumer and a rogue service that is just
> waiting for clients to add a particular header so that it can empty
> their bank account. I have to ask, why is the client talking to this
> service in the first place? And if the service has software that
> processes elements A and B and performs whatever 'semantic' is
> associated with those elements what's to stop that service using that
> same semantic when the elements appear inside some wrapper element? I
> don't see what extra assurance the client gains in the wrapper case.
> 

I answered part of this earlier.  It's a legit service, part of the
contract that the client can utilize.  You are correct that there's
nothing stopping a service from deciding that it will invoke the
transfer service if transfer is a soap header block OR is inside a WS-A
referenceP header block.  Having said that, the semantics of the 2
header blocks are dramatically different and I believe there will be
different software they will use for the 2.

Dave

Received on Wednesday, 24 November 2004 21:57:25 UTC