You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@poi.apache.org by Jon Gorrono <jp...@ucdavis.edu> on 2013/02/02 02:27:49 UTC

Re: XML processing vulnerabilities in POI

Hello again.  I'm back :)

The xmlbeans team suggests that secure processing options be set by
assigning an appropriate XMLReader using the XMLOptions api after
setting the various processing features. See [1] for reference to
setting features in javax.xml.parser* factories



http://xmlbeans.apache.org/docs/2.6.0/reference/org/apache/xmlbeans/XmlOptions.html#setLoadUseXMLReader(org.xml.sax.XMLReader)

One possible solution would be to create in intermediate class that is
an immediate ancestor for all the current implementations of the
XMLObject interface ... and which is extended by those classes...
Then, use that class as a place to determine if
the user wants to use custom XMLOptions... for example:


public class CTBubbleScaleImpl extends
org.apache.xmlbeans.impl.values.XmlComplexContentImpl implements
org.openxmlformats.schemas.drawingml.x2006.chart.CTBubbleScale

... create something like
org.poi.something.somethingelse.XmlContextContentImpl extends
org.apache.xmlbeans.impl.values.XmlComplexContentImpl

and override all the methods that have an XmlOptions alternate
signature ... in those, check for user supplied XmlOptions and
call the appropriate parent method

But I am just jabbing into the air :)  You all may have another,
better approach. I don't know for example if the above would cover all
the cases, yet... I just found that one hotspot where xmlbeans calls
where being made.


WDYT?

[1]
 http://docs.oracle.com/javase/6/docs/api/javax/xml/parsers/SAXParserFactory.html#setFeature(java.lang.String,
boolean)
 http://docs.oracle.com/javase/6/docs/api/javax/xml/parsers/DocumentBuilderFactory.html#setFeature(java.lang.String,
boolean)
 http://xerces.apache.org/xerces2-j/features.html

On Mon, Jan 14, 2013 at 3:14 PM, Jon Gorrono <jp...@ucdavis.edu> wrote:
> Thank you :)
>
> On Mon, Jan 14, 2013 at 1:35 PM, Nick Burch <ap...@gagravarr.org> wrote:
>> On Mon, 14 Jan 2013, Jon Gorrono wrote:
>>>
>>> OK, I'll check with xmlbeans ... hopefully they won't punt back citing
>>> user-configuration options.
>>
>>
>> If there are user-configuration parts that matter, let us know and we can
>> try to help you find the relevent bits of the POI source code!
>>
>> Nick
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
>> For additional commands, e-mail: user-help@poi.apache.org
>>
>
>
>
> --
> Jon Gorrono
> PGP Key: 0x5434509D -
> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
> http{middleware.ucdavis.edu}



--
Jon Gorrono
PGP Key: 0x5434509D -
http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
http{middleware.ucdavis.edu}

On Mon, Jan 14, 2013 at 3:14 PM, Jon Gorrono <jp...@ucdavis.edu> wrote:
> Thank you :)
>
> On Mon, Jan 14, 2013 at 1:35 PM, Nick Burch <ap...@gagravarr.org> wrote:
>> On Mon, 14 Jan 2013, Jon Gorrono wrote:
>>>
>>> OK, I'll check with xmlbeans ... hopefully they won't punt back citing
>>> user-configuration options.
>>
>>
>> If there are user-configuration parts that matter, let us know and we can
>> try to help you find the relevent bits of the POI source code!
>>
>> Nick
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
>> For additional commands, e-mail: user-help@poi.apache.org
>>
>
>
>
> --
> Jon Gorrono
> PGP Key: 0x5434509D -
> http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
> http{middleware.ucdavis.edu}



--
Jon Gorrono
PGP Key: 0x5434509D -
http{pgp.mit.edu:11371/pks/lookup?search=0x5434509D&op=index}
http{middleware.ucdavis.edu}

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org

Re: XML processing vulnerabilities in POI

Posted by Nick Burch <ap...@gagravarr.org>.
On Fri, 1 Feb 2013, Jon Gorrono wrote:
> One possible solution would be to create in intermediate class that is
> an immediate ancestor for all the current implementations of the
> XMLObject interface ... and which is extended by those classes...
> Then, use that class as a place to determine if
> the user wants to use custom XMLOptions... for example:
>
>
> public class CTBubbleScaleImpl extends
> org.apache.xmlbeans.impl.values.XmlComplexContentImpl implements
> org.openxmlformats.schemas.drawingml.x2006.chart.CTBubbleScale
>
> ... create something like
> org.poi.something.somethingelse.XmlContextContentImpl extends
> org.apache.xmlbeans.impl.values.XmlComplexContentImpl

All of the CT classes are automatically generated by XMLBeans, so I'm not 
sure we can easily change the class they extend from. It might be worth 
you going back to the xmlbeans list, and seeing how they recommend 
allowing for custom XmlOptions on a set of auto-generated schema classes 
as large as we have

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@poi.apache.org
For additional commands, e-mail: user-help@poi.apache.org