RE: Composibility problems with refps

 

> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com] 
> Sent: 24 November 2004 21:14
> To: Martin Gudgin; Francisco Curbera
> Cc: Christopher B Ferris; public-ws-addressing@w3.org
> Subject: RE: Composibility problems with refps
> 
> 
> 
> > -----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. 

And messages are sent *unprotected* between these 3 nodes?

> 
> > 
> > >   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...

> > >
> > > 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?

> 
> > >
> > > 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?

>- 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.

>  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.

> 
> > >
> > > 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 21:29:30 UTC