Hi Neil,
Its good that finally I could draw your attention on it :-) I would like
to say that disallow-doctype-decl feature addition is good thing. What I was
trying to say that its not complete solution. It doesn't address all kind of
applications. That said, now since we all agree that there is something more
that need to be addressed, lets concentrate on the problem and put all our
thoughts on how to fix it.
> We'll probably want to
> take the details off-line--this forum is both public and
> publicly-archived and it would be most unfortunate if hackers
> found out about potential security holes before we have fixes
> in hand for them...
> So, could people who are interested in tackling this problem
> identify themselves? Then we can take the discussion off-line
> with all interested folks, make sure we've got a comprehensive
> list of potential holes and get volunteers to work on them.
You said it right, I would like to be involved. Count me in :-) Have you got
someone else who would like to work on this issue with us ? Let's discuss about
it in more detail and fix it. I will send you a mail shortly.
thanks
Neeraj
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> list-help: <mailto:[EMAIL PROTECTED]>
> list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> list-post: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> Subject: Re: Fw: Security Alert - Xerces]
> To: [EMAIL PROTECTED]
> From: [EMAIL PROTECTED]
> Date: Fri, 6 Dec 2002 18:10:13 -0500
> X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 5.0.9a |January
7, 2002) at 12/06/2002 06:10:15 PM
> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
>
> Hi Gopal and Neeraj,
>
> The main reason why I proposed the disallow-doctype-decl
> feature is that, in addition to resolving this critical
> security problem (at least in the SOAP context), it has an
> independent value--it provides a way for applications,
> particularly those which make use of the DOM, to reject
> documents which aren't allowed, for whatever reason, to have a
> DOCTYPE property in their infoset.
>
> The trouble with the idea of setting some limit on entity
> expansion is that it has no such dual value. The other problem
> with the idea is that unfortunately, this is not likely to be
> the only means of mounting such an exploit against Xerces (ask
> me off-line if you want two more examples that I know of; for
> security reasons I won't get into that in this forum). Note
> further that this compromise and the others I have in mind are
> different from Arnaud's; see my response to him for details.
>
> So, what I think we'll eventually need is some feature whose
> semantics will be something like "cause Xerces to behave in a
> spec-noncompliant way in situations where spec compliance could
> be used in a denial-of-service exploit. Such situations
> include ..." This way, an application with such needs can set
> only one feature, rather than having to worry about rootling
> around in our documentation to make sure that the properties
> we've established for every such exploit are properly set.
>
> That said, we probably will need to expose properties for each
> such exploit, to allow applications which *don't* mind rootling
> around in our documentation to get the precise behaviour they
> want; it's unlikely that the default values we arbitrarily
> choose will work in all situations.
>
> Clearly, we'll want to decide on this list whether this is the
> right way to go or whether there's another, cleaner or better
> solution. But once we've done that, We'll probably want to
> take the details off-line--this forum is both public and
> publicly-archived and it would be most unfortunate if hackers
> found out about potential security holes before we have fixes
> in hand for them...
> So, could people who are interested in tackling this problem
> identify themselves? Then we can take the discussion off-line
> with all interested folks, make sure we've got a comprehensive
> list of potential holes and get volunteers to work on them.
>
> I'm betting Gopal and Neeraj would like to be involved? :)
>
> Cheers!
> Neil
> Neil Graham
> XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: [EMAIL PROTECTED]
>
>
>
>
> |---------+---------------------------->
> | | gopal sharma |
> | | <gopal.sharma@Sun|
> | | .COM> |
> | | Sent by: |
> | | Gopal.Sharma@Sun.|
> | | COM |
> | | |
> | | |
> | | 12/03/2002 07:01 |
> | | AM |
> | | Please respond to|
> | | xerces-j-dev |
> | | |
> |---------+---------------------------->
>
>-------------------------------------------------------------------------------
--------------------------------------------------------------|
> |
|
> | To: [EMAIL PROTECTED]
|
> | cc:
|
> | Subject: Re: Fw: Security Alert - Xerces]
|
> |
|
> |
|
>
>-------------------------------------------------------------------------------
--------------------------------------------------------------|
>
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Hi Ted and all,
> >
> > In the forked copy of Xerces that we maintain (a.k.a. XML4J :) ), we're
> > planning to solve this as follows: add a feature called
> >
> > http://apache.org/xml/features/disallow-doctype-decl
>
>
> Neil,
>
> I agree introducing above feature with default *OFF* obviously :)
> But, It doesn't sound a complete solution to me. It's good for a certain
> type
> of applications which you have already mentioned.
>
> I see Joe's suggestion -- controlling entity expansion -- as another half
> to
> complete it. Reason is simple, We can't only count on SOAP messages. DoS
> (Denial of Service) will still be there, if it's simple parsing and we
> don't give
> flexibility to users to control it within a reasonable limit per their
> configuration.
> Why shouldn't we provide solution to each and every application as far as
> we can.
>
>
> Thanks
> - Gopal
>
> >
> > which, when true, will cause the parser to emit a fatalError upon
> detection
> > of a DOCTYPE. Obviously, this is wholly incompatible with XML 1.0, and
> it
> > goes without saying it'll be false by default. But, as SOAP's a pretty
> > important spec--and is not the only spec that disallows a DOCTYPE
> property
> > in the infoset of conforming documents (the WSDL 1.2 WD does as well,
> IIRC)
> > --this kind of feature would seem to have at least some general utility,
> > aside from providing a workaround for this particular bug.
> >
> > What do people think about this? Providing functionality--even disabled
> by
> > default--that's so clearly contrary to the spirit of XML is not something
> > we should do lightly; but perhaps in this instance it's not unreasonable.
> >
> > All comments welcome!
> >
> > Cheers,
> > Neil
> > Neil Graham
> > XML Parser Development
> > IBM Toronto Lab
> > Phone: 905-413-3519, T/L 969-3519
> > E-mail: [EMAIL PROTECTED]
> >
> > |---------+---------------------------->
> > | | "Ted Leung" |
> > | | <[EMAIL PROTECTED]|
> > | | om> |
> > | | |
> > | | 11/27/2002 02:28 |
> > | | PM |
> > | | Please respond to|
> > | | xerces-j-dev |
> > | | |
> > |---------+---------------------------->
> > >
>
--------------------------------------------------------------------------------
-------------------------------------------------------------|
>
> > |
> |
> > | To: <[EMAIL PROTECTED]>
> |
> > | cc: <[EMAIL PROTECTED]>
> |
> > | Subject: Fw: Security Alert - Xerces]
> |
> > |
> |
> > |
> |
> > >
>
--------------------------------------------------------------------------------
-------------------------------------------------------------|
>
> >
> > Okay, It looks like Sanctum has decided that Xerces is the problem, and
> > they are going to issue a security
> > alert against us. Other than Sanjiva's suggetsion of a flag to turn off
> > internal (or probably all) entity expansion,
> > does anyone have any other ideas of how to fix this?
> >
> > Ted
> > ----- Original Message -----
> > From: "Ben Laurie" <[EMAIL PROTECTED]>
> > To: "Ted Leung" <[EMAIL PROTECTED]>
> > Sent: Wednesday, November 27, 2002 3:37 AM
> > Subject: [Fwd: Security Alert - Xerces]
> >
> > > Here ya go. Please keep security@ copied on any followups...
> > >
> > > Cheers,
> > >
> > > Ben.
> > >
> > > --
> > > http://www.apache-ssl.org/ben.html http://www.thebunker.net/
> > >
> > > "There is no limit to what a man can do or how far he can go if he
> > > doesn't mind who gets the credit." - Robert Woodruff
> > >
> >
> > X-Sieve: cmu-sieve 2.0
> > Return-Path: <[EMAIL PROTECTED]>
> > Delivered-To: [EMAIL PROTECTED]
> > Received: from mailgate.algroup.co.uk (localhost [127.0.0.1]) by
> > scuzzy.ben.algroup.co.uk (Postfix) with SMTP id 6DA5D8B87D for
> > <[EMAIL PROTECTED]>; Thu, 14 Nov 2002 19:17:53 +0000 (GMT)
> > Received: (qmail 23867 invoked by uid 1019); 14 Nov 2002 19:17:53 -0000
> > Delivered-To: [EMAIL PROTECTED]
> > Received: (qmail 23863 invoked by uid 1015); 14 Nov 2002 19:17:53 -0000
> > Received: from [EMAIL PROTECTED] by
> > zhora.inv.thebunker.net by uid 1015 with qmail-scanner-1.14 ( Clear:.
> > Processed in 0.056984 secs); 14 Nov 2002 19:17:53 -0000
> > Received: from daedalus.apache.org (HELO apache.org) (63.251.56.142) by
> > mailgate.algroup.co.uk with SMTP; 14 Nov 2002 19:17:52 -0000
> > Received: (qmail 24291 invoked by uid 500); 14 Nov 2002 19:17:46 -0000
> > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> > Precedence: bulk
> > Reply-To: [EMAIL PROTECTED]
> > list-help: <mailto:[EMAIL PROTECTED]>
> > list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> > list-post: <mailto:[EMAIL PROTECTED]>
> > Delivered-To: mailing list [EMAIL PROTECTED]
> > Received: (qmail 24278 invoked from network); 14 Nov 2002 19:17:46 -0000
> > Received: from unknown (HELO iris.sanctuminc.com) (206.135.172.110) by
> > daedalus.apache.org with SMTP; 14 Nov 2002 19:17:46 -0000
> > Received: by IRIS with Internet Mail Service (5.5.2650.21) id
> <WW3B980Y>;
> > Thu, 14 Nov 2002 11:10:29 -0800
> > Message-ID: <F4158E9E43A9D511BE1100065B043249EFA08F@perfectopdc>
> > From: Amit Klein <[EMAIL PROTECTED]>
> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> > Cc: Ory Segal <[EMAIL PROTECTED]>
> > Subject: Security Alert - Xerces
> > Date: Thu, 14 Nov 2002 11:15:23 -0800
> > MIME-Version: 1.0
> > X-Mailer: Internet Mail Service (5.5.2650.21)
> > Content-Type: multipart/mixed; boundary="
> > ----_=_NextPart_000_01C28C11.7EA773D2"
> > X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
> > Sender: [EMAIL PROTECTED]
> > X-Spam-Status: No, hits=-0.7 required=5.0
> > tests=DEAR_EMAIL,EXCHANGE_SERVER,PTS2,SPAM_PHRASE_01_02 version=2.42
> > X-Spam-Level:
> >
> > Dear [EMAIL PROTECTED],
> >
> > During a recent security audit at one of our customers, Sanctum found a
> > security vulnerability in your product Xerces.
> > The details of this vulnerability are described in the attached text
> file.
> >
> > We intend to issue a public advisory on BugTraq, SecuriTeam and other
> site
> > forums about this vulnerability the last week of November. Please note,
> > the
> > advisory will not contain specifics that might enable someone to exploit
> > the
> > vulnerability.
> >
> > We would appreciate it if you could issue a patch in that timeline (i.e.
> > around November 25th), so it can be linked to our advisory.
> >
> > Please feel free to contact me for more information/help.
> >
> > Thanks,
> > -Amit
> >
> > <<XML_DTD_Xerces.txt>>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > #### XML_DTD_Xerces.txt has been removed from this note on November 27
> 2002
> > by Neil Graham
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
>
> Thanks
>
> - Gopal
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
-- Neeraj
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
