Re: StAX Events - registered by default?
Hi, Bernd Eckenfels wrote on 03/03/2015 10:27:55 PM: > Hello, > > I noticed that since 2.10 Xerces-J will ship and register > implementations for StAX Event classes. I can see that this is a first > step to provide a full StAX Parser/Serializer. But until then I wonder > what can be done with those events? The same things you can do with any other object/abstract representations of XML. > It currently creates the situation that the default > XMLInput/OutputFactories are configured to use the Oracle defaults and > the Event Factory uses the Xerces brand. Is this really the best idea > to register one without the other? I don't see your point. Each factory is independent of the others. You could have a hybrid environment where every JAXP factory is provided by a different vendor/implementation. Certainly many applications use Xerces without Xalan today so it's already the case that they're getting parts of JAXP from one place (Apache) and others from somewhere else (e.g. whatever is in their JDK, or from other XML libraries like Woodstox). > > "%JAVA_1_8_HOME%\bin\java" -cp target\java-xml-test-0.0.1- > SNAPSHOT.jar;.m2\repository\xerces\xercesImpl\2.11.0\xercesImpl-2. > 11.0.jar net.eckenfels.test.xml.XMLInfoMain > > XMLInputFactory = com.sun.xml.internal.stream.XMLInputFactoryImpl >Java Runtime Environment/1.8.0_31 @ 1.8.0_31 > javax.xml.stream.allocator = null > javax.xml.stream.isCoalescing= false > javax.xml.stream.isNamespaceAware= true > javax.xml.stream.isReplacingEntityReferences = true > javax.xml.stream.isSupportingExternalEntities = true > javax.xml.stream.isValidating= false > javax.xml.stream.reporter= null > javax.xml.stream.resolver= null > javax.xml.stream.supportDTD = true > > XMLEventFactory = org.apache.xerces.stax.XMLEventFactoryImpl > null/null @ null > > SAXParserFactory = org.apache.xerces.jaxp.SAXParserFactoryImpl > null/null @ null > isNamespaceAware = false > isValidating = false > isXIncludeAware = false > http://javax.xml.XMLConstants/feature/secure-processing = false > > DocumentBuilderF = org.apache.xerces.jaxp.DocumentBuilderFactoryImpl > null/null @ null > > Xerces: Xerces-J 2.11.0 org.apache.xerces.impl.Version > null/null @ null > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
Hi, There has been some work done on the trunk [1] to make it easier for users to protect themselves but it isn't likely to change any defaults. Users need to configure XML parsers appropriately for their scenario and there are plenty of ways they can do that if they're concerned about XXE. Thanks. [1] http://markmail.org/message/cj2ytc62gczbplum Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Jim Manico wrote on 02/26/2015 07:38:54 AM: > Hello, > > I am a security researcher worried about the threat of XXE in Java parsers. > > https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing > > Java 8 made the choice to disable External Entities by default and > I'd love to see Xerces2 make the same choice. This is a pretty > serious risk to be left on by default. > > Has there been any discussion on this before? Forgive me if I am > late to the game here. > > Aloha, > -- > Jim Manico > @Manicode > (808) 652-3805 > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
With respect, XXE is a massive vulnerability that is turned off by default in Java 8 as well as IBM parsers. Is there any proof or risk model I could provide to convince Xerces to turn this off by default? I am honestly just a researcher who has watch several folks get brutally hacked because of this. Turning it off by default would make the world a safer place. Respectfully, -- Jim Manico @Manicode (808) 652-3805 > On Mar 4, 2015, at 8:56 AM, Michael Glavassevich wrote: > > Hi, > > There has been some work done on the trunk [1] to make it easier for users > to protect themselves but it isn't likely to change any defaults. Users > need to configure XML parsers appropriately for their scenario and there > are plenty of ways they can do that if they're concerned about XXE. > > Thanks. > > [1] http://markmail.org/message/cj2ytc62gczbplum > > Michael Glavassevich > XML Technologies and WAS Development > IBM Toronto Lab > E-mail: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > Jim Manico wrote on 02/26/2015 07:38:54 AM: > >> Hello, >> >> I am a security researcher worried about the threat of XXE in Java > parsers. >> >> https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing >> >> Java 8 made the choice to disable External Entities by default and >> I'd love to see Xerces2 make the same choice. This is a pretty >> serious risk to be left on by default. >> >> Has there been any discussion on this before? Forgive me if I am >> late to the game here. >> >> Aloha, >> -- >> Jim Manico >> @Manicode >> (808) 652-3805 >> - >> To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org >> For additional commands, e-mail: j-users-h...@xerces.apache.org > > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
On 3/4/15, 4:56 PM, "Michael Glavassevich" wrote: > >There has been some work done on the trunk [1] to make it easier for >users >to protect themselves but it isn't likely to change any defaults. Users >need to configure XML parsers appropriately for their scenario and there >are plenty of ways they can do that if they're concerned about XXE. Maybe we were mistaken, but my team's analysis of CVE-2013-4002 that addressed an issue in the JDK, and the fix here that was applied to trunk but never released, suggested to me that there's no way to configure any released version of Xerces safely unless the input document size is limited. This isn't an XXE issue per se, but it seemed relevant to ask since this response seems to reinforce the position that no release can be expected. -- Scott - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
On 3/4/15, 5:08 PM, "Jim Manico" wrote: >With respect, XXE is a massive vulnerability that is turned off by >default in Java 8 as well as IBM parsers. Is there any proof or risk >model I could provide to convince Xerces to turn this off by default? +1 And it's not the only unfixed vulnerability in play (per the note I just sent). -- Scott
Re: Hello and XXE
How can I help? I'm happy to submit a patch if you like... This is a fairly critical security issue and I'm willing to get my hands dirty and help code? wash your car? free trips to Hawaii? What do need? Aloha, -- Jim Manico @Manicode (808) 652-3805 > On Mar 4, 2015, at 9:16 AM, Cantor, Scott wrote: > > On 3/4/15, 5:08 PM, "Jim Manico" wrote: > > > >> With respect, XXE is a massive vulnerability that is turned off by >> default in Java 8 as well as IBM parsers. Is there any proof or risk >> model I could provide to convince Xerces to turn this off by default? > > +1 > > And it's not the only unfixed vulnerability in play (per the note I just > sent). > > -- Scott > > B‹CB•È [œÝXœØÜšX™KK[XZ[ˆ‹]\Ù\œË][œÝXœØÜšX™P \˜Ù\˘\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ‹]\Ù\œËZ[ \˜Ù\˘\XÚK›Ü™ÃB - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
On 3/4/15, 5:21 PM, "Jim Manico" wrote: >How can I help? I'm happy to submit a patch if you like... This is a >fairly critical security issue and I'm willing to get my hands dirty and >help code? wash your car? free trips to Hawaii? What do need? If you're directing that question to me, the vulnerability I spoke of is fixed in trunk already. But only in trunk, no release. And there's no setting that can block the bug, so the idea that applications are at fault in that particular case is simply untrue as far as we were able to determine. -- Scott
Re: Hello and XXE
"Cantor, Scott" wrote on 03/04/2015 12:15:02 PM: > On 3/4/15, 4:56 PM, "Michael Glavassevich" wrote: > > > > >There has been some work done on the trunk [1] to make it easier for > >users > >to protect themselves but it isn't likely to change any defaults. Users > >need to configure XML parsers appropriately for their scenario and there > >are plenty of ways they can do that if they're concerned about XXE. > > Maybe we were mistaken, but my team's analysis of CVE-2013-4002 that > addressed an issue in the JDK, and the fix here that was applied to trunk > but never released, suggested to me that there's no way to configure any > released version of Xerces safely unless the input document size is > limited. > > This isn't an XXE issue per se, but it seemed relevant to ask since this > response seems to reinforce the position that no release can be expected. The defect you're referring to had nothing to do with DTDs or entities. > -- Scott > > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
On 3/4/15, 6:10 PM, "Michael Glavassevich" wrote: > >The defect you're referring to had nothing to do with DTDs or entities. Which I acknowledged. You still have an unreleased security fix that is *not* a function of "applications configuring the parser correctly". -- Scott
Re: Hello and XXE
"Cantor, Scott" wrote on 03/04/2015 12:16:03 PM: > From: "Cantor, Scott" > To: "j-users@xerces.apache.org" , > Date: 03/04/2015 12:18 PM > Subject: Re: Hello and XXE > > On 3/4/15, 5:08 PM, "Jim Manico" wrote: > > > > >With respect, XXE is a massive vulnerability that is turned off by > >default in Java 8 as well as IBM parsers. Is there any proof or risk > >model I could provide to convince Xerces to turn this off by default? > > +1 > > And it's not the only unfixed vulnerability in play (per the note I just > sent). -1. XXE is not a vulnerability in the parser. It may be a vulnerability for an application/product, but that is the developer's responsibility to apply proper configuration to protect themselves in the right context. > -- Scott Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
On 3/4/15, 6:23 PM, "Michael Glavassevich" wrote: > >-1. XXE is not a vulnerability in the parser. It may be a vulnerability >for an application/product, but that is the developer's responsibility to >apply proper configuration to protect themselves in the right context. The issue is a trade-off between the time to do a release and the value of changing a default. It's not a vulnerability and nobody said it was. If you want to claim that the other vulnerability is in fact not a vulnerability, then that would be new and valuable information to me, which is why I asked about it again in this thread. -- Scott
Re: Hello and XXE
"Cantor, Scott" wrote on 03/04/2015 01:16:30 PM: > From: "Cantor, Scott" > To: "j-users@xerces.apache.org" , > Date: 03/04/2015 01:19 PM > Subject: Re: Hello and XXE > > On 3/4/15, 6:10 PM, "Michael Glavassevich" wrote: > > > > > >The defect you're referring to had nothing to do with DTDs or entities. > > Which I acknowledged. You still have an unreleased security fix that is > *not* a function of "applications configuring the parser correctly". And I was pointing out that it's irrelevant to Jim's concern. If you're interested in seeing a release which rolls up this and other fixes from the trunk, that's another discussion. The long period of time between Xerces releases boils down to a lack of time from developers and low interest from the community to motivate a new release. > -- Scott Michael Glavassevich XML Technologies and WAS Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
On 3/4/15, 6:34 PM, "Michael Glavassevich" wrote: > >And I was pointing out that it's irrelevant to Jim's concern. I'm betting Jim's concern is with the parser being secure, period, not just in one specific way, but he can speak for himself. >If you're interested in seeing a release which rolls up this and other >fixes from the trunk, that's another discussion. The long period of time >between Xerces releases boils down to a lack of time from developers and >low interest from the community to motivate a new release. I think the situation is clear to anybody reading this thread now that isn't hiding their heads in the sand, which was my only intention. -- Scott
Re: Hello and XXE
I politely disagree. This can only be fixed via parser configuration. It makes sense to turn external entities OFF by default since it's rarely used and does a lot of damage by default. Most XML parsers already default to turning this off. It's almost always a good idea to have safe defaults in software when you can. Note: IBM has a very expensive product •just• to handle this issue - which would be largely unnecessary if Xerces defaulted to turning external entities off by default. With respect, -- Jim Manico @Manicode (808) 652-3805 > On Mar 4, 2015, at 8:23 AM, Michael Glavassevich wrote: > > "Cantor, Scott" wrote on 03/04/2015 12:16:03 PM: > >> From: "Cantor, Scott" >> To: "j-users@xerces.apache.org" , >> Date: 03/04/2015 12:18 PM >> Subject: Re: Hello and XXE >> >> On 3/4/15, 5:08 PM, "Jim Manico" wrote: >> >> >> >>> With respect, XXE is a massive vulnerability that is turned off by >>> default in Java 8 as well as IBM parsers. Is there any proof or risk >>> model I could provide to convince Xerces to turn this off by default? >> >> +1 >> >> And it's not the only unfixed vulnerability in play (per the note I just > >> sent). > > -1. XXE is not a vulnerability in the parser. It may be a vulnerability > for an application/product, but that is the developer's responsibility to > apply proper configuration to protect themselves in the right context. > >> -- Scott > > Michael Glavassevich > XML Technologies and WAS Development > IBM Toronto Lab > E-mail: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > > > - > To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org > For additional commands, e-mail: j-users-h...@xerces.apache.org > - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
Re: Hello and XXE
That's true Scott. Xerces is a big player in the XML parsing world. I'm just a security activist trying to encourage important libraries like Xerces to use safe defaults when they can. And for XXE, for sure, there is precedent to turn it off by default since it's so dangerous. -- Jim Manico @Manicode (808) 652-3805 > On Mar 4, 2015, at 8:40 AM, Cantor, Scott wrote: > > On 3/4/15, 6:34 PM, "Michael Glavassevich" wrote: > > >> >> And I was pointing out that it's irrelevant to Jim's concern. > > I'm betting Jim's concern is with the parser being secure, period, not > just in one specific way, but he can speak for himself. > >> If you're interested in seeing a release which rolls up this and other >> fixes from the trunk, that's another discussion. The long period of time >> between Xerces releases boils down to a lack of time from developers and >> low interest from the community to motivate a new release. > > I think the situation is clear to anybody reading this thread now that > isn't hiding their heads in the sand, which was my only intention. > > -- Scott > > B‹CB•È [œÝXœØÜšX™KK[XZ[ˆ‹]\Ù\œË][œÝXœØÜšX™P \˜Ù\˘\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ‹]\Ù\œËZ[ \˜Ù\˘\XÚK›Ü™ÃB - To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
