Hi Neil, I'd be interested in hearing about other potential security holes in Xerces, but I probably can't contribute much to the fixes. Can you add me to the list anyway? For the entity reference issue I made a fix that was suggested in the newsgroup earlier, that is limiting the total number of entity references that are resolved, configurable through a property (based on Xerces 1.4.4, though). If there's an interest to port that to he recent source, I could do that (from your comments I gather that you're not in favour of that solution, though).
Thanks, Corinna [EMAIL PROTECTED] wrote: > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
