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:19:01 UTC