Hi Joe,
As you can imagine, we check for recursive entity references already; so
this exploit couldn't involve recursion.
I wonder what the default value for this property should be? I guess it
should be infinite, because anything else would be as XML incompliant as
the disallow-doctype feature. If so, this'll add another check at entity
expansion time. How would an application know what to set it too? Does
this have any value other than to solve this particular exploit?
I agree there probably aren't dramatic efficiency concerns here though.
I'm just wondering whether, if there are applications like SOAP that would
like not to process docs with DTD's anyway, perhaps this exploit gives us
an opportunity to serve them better. If a SOAP processor used DOM, for
instance, how would it detect a "SOAP-invalid" SOAP doc with a DTD?
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
|---------+---------------------------->
| | Joseph |
| | Kesselman/Watson/|
| | IBM@IBMUS |
| | |
| | 11/27/2002 03:35 |
| | PM |
| | Please respond to|
| | xerces-j-dev |
| | |
|---------+---------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: Fw: Security Alert - Xerces]
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
The proposed counter only has to be checked/updated when an entity
expansion is entered/exited. That's not going to be a lot of overhead,
given how rare entity boundaries are in typical data and how much other
computation is involved in the expansion. I'd bet it's close to
negligible... especially if it's count-down-and-compare-to-zero rather
than count-up-and-compare-to-maximum, since "!=0" is a free result of
subtraction in most architectures and a JIT compiler ought to be smart
enough to recognize that opportunity.
______________________________________
Joe Kesselman / IBM Research
---------------------------------------------------------------------
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]
