I'm not sure what the actual problem is but for sure the first thing to do is to detect recursion if we don't already do so. But I'm guessing somebody could still cause trouble by "simply" creating a huge number of entities. Nested or not. So I'm not sure having a max depth parameter would do much good. And the pb with this kind of stuff is that in practice you just never know what value would be "right". While Neil's suggestion seems indeed radical it may be the most practical one. It surely addresses the problem for a well defined set of applications: SOAP processors, which I think is the main target of this Security Alert. -- Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
-----Original Message----- From: Ted Leung [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 12:10 PM To: [EMAIL PROTECTED] Subject: Re: Fw: Security Alert - Xerces] Yikes. This solves the problem for sure, but it does seem kind of overkill. I like Joe's suggestion of a max recursion depth, but that seems like a lot of work and we'll probably loose some speed. A middle ground would be a feature to just turn off all entity expansion, but from the clients that I've dealt with, that would probably cause a lot of support problems... Ted ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 27, 2002 11:58 AM Subject: Re: Fw: Security Alert - Xerces] > 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 > > 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] > --------------------------------------------------------------------- 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]
