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

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.

And this problem is prevented in WS-A by requiring that REFps are not
echoed directly and unmodified as soap header blocks.

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.  

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 18:40:52 UTC