RE: Composibility problems with refps

 

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

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

> 
> 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 securing the wsa:EndpointReference
element? Or the headers which are inserted into a message? Or both?

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

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

:-(

Gudge

> 
> Cheers,
> Dave
> 
> > -----Original Message-----
> > From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> > Sent: Wednesday, November 24, 2004 9:20 AM
> > To: David Orchard; Francisco Curbera
> > Cc: Christopher B Ferris; public-ws-addressing@w3.org
> > Subject: RE: Composibility problems with refps
> > 
> > But in order to do that, the hacker would have to have 
> enough control
> > over the system to
> > 
> > a) inject arbitrary XML into (parts of) the message.
> > b) get the security infrastructure to sign stuff from a)
> > 
> > If a system is compromised enough to allow a) and b) then I 
> think it's
> > toast.
> > 
> > Gudge
> > 
> > > -----Original Message-----
> > > From: public-ws-addressing-request@w3.org
> > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > > David Orchard
> > > Sent: 24 November 2004 17:04
> > > To: Francisco Curbera
> > > Cc: Christopher B Ferris; public-ws-addressing@w3.org
> > > Subject: RE: Composibility problems with refps
> > >
> > >
> > > I never said the hacker figures out how to sign arbitrary 
> documents
> or
> > > even manipulates the SOAP body.  Geez, stay with me here.  I said
> the
> > > hacker figured out how to put in a refP into an EPR and then
> > > the rest of
> > > the unhacked infrastructure takes care of signing, transmission,
> etc.
> > >
> > > Dave
> > >
> > > > -----Original Message-----
> > > > From: public-ws-addressing-request@w3.org
> > > [mailto:public-ws-addressing-
> > > > request@w3.org] On Behalf Of Francisco Curbera
> > > > Sent: Wednesday, November 24, 2004 6:30 AM
> > > > To: David Orchard
> > > > Cc: Christopher B Ferris; public-ws-addressing@w3.org
> > > > Subject: RE: Composibility problems with refps
> > > >
> > > >
> > > > Dave,
> > > >
> > > > I may be wrong about this, since I am no expert in security, but
> if
> > > the
> > > > hacker figures out how sign arbitrary documents on your
> > > behalf then I
> > > will
> > > > guess that SOAP header extensibility will not be at the top of
> your
> > > list
> > > > of
> > > > problems - certainly not the only one. Hackers will not
> > > need to worry
> > > > about
> > > > the SOAP header extensibility model to steal all you money
> > > (and maybe
> > > also
> > > > mine); there are already plenty of ways to do this by
> > > manipulating the
> > > > good
> > > > old SOAP body. That's what I was trying to say.
> > > >
> > > > As for IBM's security concerns, so far our experts tell us
> > > ref. props
> > > as
> > > > SOAP headers are ok as long as we consistently sign
> > > everything, which
> > > you
> > > > need to do in any case.
> > > >
> > > > Paco
> > > >
> > > >
> > > >
> > > >
> > > >                       "David Orchard"
> > > >                       <dorchard@bea.com        To:      
>  Francisco
> > > > Curbera/Watson/IBM@IBMUS
> > > >                       >                        cc:
> > > Christopher B
> > > > Ferris/Waltham/IBM@IBMUS, <public-ws-addressing@w3.org>
> > > >                                                Subject:  RE:
> > > Composibility
> > > > problems with refps
> > > >                       11/23/2004 01:27
> > > >                       PM
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Sure, everything can be hacked.  And the sky could fall and we
> could
> > > all
> > > > die.  So what?  By saying "well hacks happen and then the system
> is
> > > > totally broken" prevents us from talking about security problems
> of
> > > > systems.  And that can prevent us from thinking about 
> security and
> > > > making appropriate trade-offs of security vs other properties.
> > > >
> > > > Extending your analogy, nobody should switch to safer
> architectures
> > > > (like Java over C++ for the common string hack and stack
> > > overflows) or
> > > > operating systems(cough) or strongly typed languages 
> because well,
> > > > that's just too bad if systems get hacked or mistakes are made.
> > > >
> > > > Signing EPRs doesn't prevent this security problem.  I didn't
> point
> > > out
> > > > a widespread security failure in the software, I pointed out one
> > > > particular vulnerability that is fairly easily 
> prevented.  In the
> > > > pipeline model that lots of vendors offer, it's pretty simple to
> > > insert
> > > > a ref property well before the signing/encrypting code 
> is applied.
> > > Most
> > > > of the stuff I've seen out of vendors seems to indicate
> > > that security
> > > > happens at the touch points to the network - the last node
> > > on outbound
> > > > and first node on inbound messages.
> > > >
> > > > The point about SOAP is that SOAP offers a distributed
> extensibility
> > > > model with arbitrary ramifications, and the ws-a echoing
> processing
> > > > model could maliciously take advantage of that open ended
> > > extensibility
> > > > model.  This vulnerability can be prevented in a fairly simple
> way.
> > > >
> > > > I'll say again, there is a software vulnerability that 
> is created
> by
> > > the
> > > > combination of the ws-a processing model and the soap
> extensibility
> > > > model that can easily be prevented in ws-a.
> > > >
> > > > I'm surprised that I've now heard two IBMer's now adopt the "no
> > > problem,
> > > > nothing to see, move along" approach to this potential
> > > security issue.
> > > >
> > > > Cheers,
> > > > Dave
> > > >
> > > > > -----Original Message-----
> > > > > From: Francisco Curbera [mailto:curbera@us.ibm.com]
> > > > > Sent: Tuesday, November 23, 2004 6:13 AM
> > > > > To: David Orchard
> > > > > Cc: Christopher B Ferris; public-ws-addressing@w3.org;
> public-ws-
> > > > > addressing-request@w3.org
> > > > > Subject: RE: Composibility problems with refps
> > > > >
> > > > > The fact is that everything can be hacked if it is 
> not properly
> > > > protected.
> > > > > This includes SOAP headers but also SOAP bodies. The same
> > > model of a
> > > > > server
> > > > > sending opaque data to a client with the explicit
> > > understanding that
> > > > the
> > > > > client must include it in messages sent to the server is
> > > absolutely
> > > > > pervasive. This for example the case of an order number or a
> > > customer
> > > > id
> > > > > that a merchant sends back to his customer - it could 
> also be a
> > > > complex
> > > > > piece of XML. A hacker with access to the merchant's systems
> could
> > > > very
> > > > > well figure out how to manipulate that information so that all
> > > > payments
> > > > > are
> > > > > credited to his account for example. Since we assume he even
> > > > understands
> > > > > how to sign EPRs on behalf of anyone, he may just as well
> > > understand
> > > > how
> > > > > the internal processing at the merchant site works; the sky is
> the
> > > > limit
> > > > > then. He may include signed XML in which any conceivable
> > > promise is
> > > > made
> > > > > by
> > > > > the merchant to the customer, or vice versa if he hacks the
> > > customer's
> > > > > site. Everything is possible; I just don't see what is so
> special
> > > > about
> > > > > SOAP headers - maybe that us just me.
> > > > >
> > > > > Having the ability to sign EPRs as well as individual
> > > ref. property
> > > > > headers
> > > > > should be more than enough to reasonably put this concern to
> rest.
> > > > >
> > > > > Paco
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >                       "David Orchard"
> > > > >                       <dorchard@bea.com>              To:
> > > > > Christopher B Ferris/Waltham/IBM@IBMUS
> > > > >                       Sent by:                        cc:
> > > > <public-
> > > > > ws-addressing@w3.org>
> > > > >                       public-ws-addressing-req
> > > Subject:  RE:
> > > > > Composibility problems with refps
> > > > >                       uest@w3.org
> > > > >
> > > > >
> > > > >                       11/22/2004 06:15 PM
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I'm not worried about ref props/params interfering with
> > > WS-* use of
> > > > > headers by a bad interface design.  The owner of the interface
> > > > controls
> > > > > both the use of WS-* specs and the use of RefPs.  They
> > > will quickly
> > > > sort
> > > > > out any interface conflicts.  And my guess is that Rule #1 of
> RefP
> > > > usage
> > > > > will be: Thou shalt not use WS-* QNames in RefPs.
> > > > >
> > > > > I'm more sensitive to the issue 8 concern about ref 
> props/params
> > > being
> > > > > duplicates of user headers, particularly a security hole
> > > that allows
> > > a
> > > > > hacker to put a bad RefP into the EPR, ie
> > > > > <SendAssetsToGrandCayman amount="all" fromacct="chris"
> > > > toacct="hacker"/>
> > > > >
> > > > > This security problem isn't covered by signing the EPR but is
> > > covered
> > > > by
> > > > > a wrapper of some kind.
> > > > >
> > > > > Dave
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: public-ws-addressing-request@w3.org
> > > > > [mailto:public-ws-addressing-
> > > > > > request@w3.org] On Behalf Of Christopher B Ferris
> > > > > > Sent: Monday, November 22, 2004 1:10 PM
> > > > > > To: Anish Karmarkar
> > > > > > Cc: Jonathan Marsh; public-ws-addressing@w3.org;
> > > > public-ws-addressing-
> > > > > > request@w3.org; tom@coastin.com
> > > > > > Subject: Re: Composibility problems with refps
> > > > > >
> > > > > >
> > > > > > Anish/Tom,
> > > > > >
> > > > > > But then this means that the refps that under the current
> design
> > > > > become
> > > > > > SOAP headers, and subject to
> > > > > > the SOAP processing model, would no longer be subject
> > > to the SOAP
> > > > > > processing model. I think that this
> > > > > > would be a collossal mistake.
> > > > > >
> > > > > > Frankly, I think that the idea of reference 
> properties/params
> > > > > interfering
> > > > > > with other WS-* use of headers
> > > > > > is a red herring. Of course, it is always possible to
> > > do something
> > > > > that
> > > > > > would break any protocol. At most, I could
> > > > > > see adding a note in the spec that recommended caution when
> > > > including
> > > > > any
> > > > > > protocol elements
> > > > > > as reference property/parameters as their subsequent
> > > inclusion as
> > > > SOAP
> > > > > > header blocks in messages
> > > > > > addressed to the endpoint *might*, I repeat, *might*
> > > conflict with
> > > > > > constraints as to cardinality of such
> > > > > > header blocks in a message, etc.
> > > > > >
> > > > > > I would strongly discourage any thoughts of a wrapper
> > > element for
> > > > > > reference property/parameters.
> > > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > > > Anish Karmarkar <Anish.Karmarkar@oracle.com>
> > > > > > Sent by: public-ws-addressing-request@w3.org
> > > > > > 11/22/2004 02:03 PM
> > > > > >
> > > > > > To
> > > > > > tom@coastin.com
> > > > > > cc
> > > > > > Jonathan Marsh <jmarsh@microsoft.com>,
> > > public-ws-addressing@w3.org
> > > > > > Subject
> > > > > > Re: Composibility problems with refps
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I agree that would indeed solve the problem -- either refp
> > > specific
> > > > > > header(s) or the use of [to] property.
> > > > > >
> > > > > > -Anish
> > > > > > --
> > > > > >
> > > > > > Tom Rutt wrote:
> > > > > >
> > > > > > >
> > > > > > > As Glen has suggested before, encapsulating the ref parms
> and
> > > ref
> > > > > props
> > > > > > > in a ws-addressing specific header element would
> > > allow arbitrary
> > > > > > > qnames for the ref props and ref parms, without confusion.
> > > > > > >
> > > > > > > Tom Rutt
> > > > > > >
> > > > > > > Anish Karmarkar wrote:
> > > > > > >
> > > > > > >>
> > > > > > >> Yes.
> > > > > > >> Or in the context of SOAP, composability with any
> > > specification
> > > > > that
> > > > > > >> uses SOAP header(s) as a mechanism to convey information.
> > > > > > >>
> > > > > > >> -Anish
> > > > > > >> --
> > > > > > >>
> > > > > > >> Jonathan Marsh wrote:
> > > > > > >>
> > > > > > >>> Specifically, you're worried about the case where the
> > > reference
> > > > > > >>> properties and reference parameters are in a
> > > namespace used by
> > > > the
> > > > > > >>> reliability, security, etc. mechanisms, right?
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>> -----Original Message-----
> > > > > > >>>> From: public-ws-addressing-request@w3.org
> > > [mailto:public-ws-
> > > > > > >>>> addressing-request@w3.org] On Behalf Of Anish Karmarkar
> > > > > > >>>> Sent: Monday, November 15, 2004 11:10 AM
> > > > > > >>>> To: public-ws-addressing@w3.org
> > > > > > >>>> Subject: Composibility problems with refps
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> All,
> > > > > > >>>>
> > > > > > >>>> During last week's concall discussion of issue
> > > i008 I took an
> > > > > action
> > > > > > >>>> to
> > > > > > >>>> explain the composibility problem with refps 
> in an email.
> > > This
> > > > > email
> > > > > > >>>> fulfills that action.
> > > > > > >>>>
> > > > > > >>>> WS-Addressing [1] Submission includes [reference
> > > properties]
> > > > and
> > > > > > >>>> [reference parameters] in the info models for 
> EPR. These
> > > refps
> > > > > are
> > > > > > >>>> opaque to the consumer. In the SOAP binding of
> > > EPR, the refps
> > > > are
> > > > > > >>>> bound
> > > > > > >>>> as individual SOAP header blocks. I.e., a consumer of a
> EPR
> > > > using
> > > > > > SOAP
> > > > > > >>>> is required to copy the refps as individual SOAP header
> > > blocks
> > > > > > without
> > > > > > >>>> understanding what the blocks mean or do.
> > > > > > >>>>
> > > > > > >>>> Typically SOAP header blocks are part of a SOAP module
> and
> > > > > express
> > > > > > >>>> certain functionality. For example, WSS, 
> WS-Reliability,
> > > > > > >>>> WS-ReliableMessaging, WS-C, WS-T WS-Context 
> etc, specify
> > > header
> > > > > > blocks
> > > > > > >>>> that have a particular meaning that is 
> conveyed from the
> > > sender
> > > > > to
> > > > > > the
> > > > > > >>>> receiver. Specifications in the realm of Web 
> services are
> > > > > designed to
> > > > > > >>>> be
> > > > > > >>>> composible with other specs. For example, 
> WS-Context can
> be
> > > > > composed
> > > > > > >>>> with WS-Reliability and WSS.
> > > > > > >>>>
> > > > > > >>>> A consuming application that dereferences an EPR that
> > > contains
> > > > > refps
> > > > > > >>>> may
> > > > > > >>>> have some policies in place wrt to 
> reliability, security,
> > > > > > >>>> coordination,
> > > > > > >>>> transaction, privacy etc. Given that refps may contains
> any
> > > XML
> > > > > and
> > > > > > >>>> these refps are bound as SOAP header blocks, refps can
> > > > > potentially
> > > > > > >>>> interfere with composibility of WS-Addressing with
> > > other WS-*
> > > > > specs
> > > > > > >>>> that
> > > > > > >>>> the consumer may be using. The opacity of the
> > > refps prevents
> > > > the
> > > > > > >>>> consumer from making any inferences about the 
> refps in an
> > > EPR.
> > > > > > >>>>
> > > > > > >>>> This issue is slightly different from the security
> > > of EPRs --
> > > > > which
> > > > > > >>>> *may* potentially be resolved by requiring the
> > > minter of the
> > > > EPR
> > > > > to
> > > > > > >>>> sign
> > > > > > >>>> the EPR.
> > > > > > >>>>
> > > > > > >>>> HTH to clarify the issue.
> > > > > > >>>>
> > > > > > >>>> -Anish
> > > > > > >>>> --
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>> [1]
> > > > > http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
>

Received on Wednesday, 24 November 2004 19:58:01 UTC