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. 

> 
> >   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 21:13:47 UTC