RE: Composibility problems with refps

+1

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

"Martin Gudgin" <mgudgin@microsoft.com> wrote on 11/24/2004 12:19:58 PM:

> 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 17:42:52 UTC