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]
