Hi Arnaud,
Just a short response to point out why it seems to me that the
large-document problem is different from the security hole that the
disallow-doctype-decl feature (partly) addressed.
It's always possible for an application that uses Xerces to determine
precisely how large a document the parser is being given: It can preload
entities from the network, check the size of the resulting files. In
dynamic cases, it can always insert a filter between the source and the
parser, and abort if too many bytes are received.
On the other hand, unless an aplication wants to learn how to parse XML
itself, there's no way for it to avoid this entity-expansion problem.
To conclude: In an ideal world, we should allow apps to set some property
to abort if N bytes are received. But (1) we should first solve problems
which no non-XML parser can even in principle solve and (2) we should
probably only solve the large-document problem if we can find some way to
do so it that doesn't totally hose performance. My suspicion is that
counting every character sequence--or even implementing functionality to
allow that to happen if requested--would impose some pretty nontrivial
penalties.
Thoughts?
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Arnaud Le |
| | Hors/Cupertino/IB|
| | M@IBMUS |
| | |
| | 12/03/2002 12:18 |
| | PM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: <[EMAIL PROTECTED]>
|
| cc:
|
| Subject: RE: Security Alert - Xerces]
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
I'm fine with what's being done to address the immediate concern but I
should point out that this is far from the end of our troubles on that
front.
The fact is that there are many ways one can screw things up, by getting
the
parser into extremely CPU consuming processing or running out of memory.
To really address this someone would need to spend quite some time thinking
about all the different "holes".
For example, with the DOM it's easy to run out of memory. All it would take
is to send a document with one element containing a few Gigas of text...
I guess I favor the addition of parameters the application developer could
use to set various limits, even though as an application developer I would
probably have a hard time figuring out what to set them to... All these
limits should be set to infinite by defaults.
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
-----Original Message-----
From: Ted Leung [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 10:31 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Security Alert - Xerces]
The next version of Xerces-J will include a parser feature that will
turn off DOCTYPE processing. When activated, this feature will
prevent the entity expansion that causes this vulnerability. The Axis
team will be able to use this feature to close the hole.
The URI for the parser feature will be
"http://apache.org/xml/features/disallow-doctype-decl";
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
>
---------------------------------------------------------------------
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]
