Let me tell you the story of a security bug.
To harden our CMS against XXE attacks, we were implementing the procedures proposed by OWASP. This worked nicely for the deployed software but we ran into one case in which the XXE prevention simply did not seem to work when running a test. Fearing that the approach was somehow broken despite the reputable source, we did a root causes analysis. We found that the transformer factory was correctly configured to avoid inline DTDs and when creating a SAX parser internally it would also pass plausible security features to the parser. However, the parser did not understand the relevant security features, because it implemented an older JAXP version, in which other features had to be used for avoiding XXE attacks. The transformer factory on the other hand, expected a modern SAX parser to be generated, unaware that a JAXP plugin jar might replace the parser, but not the transformer factory implementation.
It turned out that the test was running in a JVM that also had a Xerces parser deployed. While we had forbidden Xerces as a Maven dependency for production code, we had not yet enforced that requirement for tests, too.
We were relieved to find that our Xerces-less production setup was not affected. However, we still contacted Oracle about the issue, who agreed to fix it as a defense in depth issue. After all, this is a pretty insidious bug. While the native XML handling of the JVM is generally preferred over Xerces these days, Xerces might be involuntarily introduced into a project as a transitive dependency. Tools like Maven make it so easy to add a handy new dependency that the full impact of such a change might be overlooked.
It was not a bug in the JDK, because you should not deploy an implementation of an old JAXP version in a JVM that needs a modern implementation. It was not a bug of Xerces, because Xerces never promised to implement the new JAXP standard. It was not a bug of the libraries that depended on Xerces, because they needed Xerces to do their work. It was a bug introduced by adding a dependency, but a bug that was extremely hard to foresee.
But still, I think we can learn a few things, all of them undoubtedly already learned again and again:
- Be careful when adding dependencies. Something that isn't there cannot break anything.
- Before you add magic (such as an XML parser auto-detection), think about it twice.
- If you change an API (such as the security feature flags of JAXP), try to stay compatible with the old API whenever possible.
- If you find a problem, talk those who can fix it. They want to be convinced, but in general there is a great willingness to improve.
- A little Jack-in-the-box may jump at you unexpectedly. Allow time to deal with it.
The good news: The patch is available in JDK 9.0.4 and in fact in the current patch releases for all relevant JDK versions.
