XML flaws threaten 'enormous' array of apps
Java, Python, and Apache - for starters
Updated Security researchers have uncovered critical flaws in open-source software that implements the Extensible Markup Language in a staggering array of applications used by banks, e-commerce websites, and consumers.
The bugs uncovered by researchers at Finland-based Codenomicon were contained in virtually every open-source XML library available, Ari Takanen, CTO of Finland-based security testing firm Codenomicon, told The Register. Many of them could allow attackers to crash machines running applications that use the libraries or even remotely execute malicious code. The Python and Java programming languages and Apache Xerces are already known to be affected, and Takanen said many more could be as well.
"The number of applications can be enormous," Takanen said. "Basically, any application or piece of software that's using XML libraries is vulnerable."
The discovery is significant because it highlights holes in the foundation upon which many of the world's applications are built. The programs drive cloud computing services, 3-dimensional programs, and a wide range of business software.
The discovery is the result of a program dubbed CROSS, or Codenomicon Robust Open Source Software, which uses software fuzzers to test the security of open-source programs by throwing manipulated data at them and seeing how they react. Codenomicon researchers tested every open-source library and all were found to contain vulnerabilities, though their severity varied from library to library.
The bugs "are related to the parsing of XML elements with unexpected byte values and recursive parentheses, which cause the program to access memory out of bounds, or to loop indefinitely," according to this advisory from the Computer Emergency Response Team in Finland, which has been working with Codenomicon to coordinate fixes among different software providers.
Codenomicon went on to say here that libraries built on the C language are at highest risk because exploits can include the execution attacks.
"Unfortunately, most libraries out there are written in C, and thus errors such as stack overflows are not that uncommon," the document stated. "When this is the case, exploitability depends on the anti-exploitation features of the platform (ASLR, DEP, NX bits, canaries etc.)."
C-based libraries used in communications software represent the highest risk because attacks could include remote execution. Libraries that merely process files are most likely vulnerable to only local attacks. The bugs could be exploited by tricking a user into opening a booby-trapped XML file or by sending malicious requests to XML-powered Web services.
CERT Finland continues to reach out to software makers who may have embedded the libraries in their offerings or used the libraries to help develop their programs. The Python Software Foundation is working on a fix, CERT said.
Sun issued at least two XML-related updates, one for OpenSSO Enterprise 8.0 Sun Java System Access Manager and the other in its Java Runtime Environment. The status of Apache Xerces remained unclear, although the foundation issued this patch in June that references Codenomicon.
The discovery is reminiscent of a vulnerability many of the Codenomicon principals found in 2001 and 2002 in a networking standard known as ASN.1. The ramifications of the bug were serious enough to lead of months of wrangling by hundreds of companies that relied on the technology and to warrant a briefing of then President George W. Bush.
It's impossible to know now if the flaws uncovered in XML will be as far reaching as all that. But if you value your organization's security, it might be a good idea to monitor the providers of your libraries to see what they have to say. ®
Story updated to add details about bug and fixes from Sun and Apache.
The problem is XML
XML is such a simple concept. Provide a language that permits you to write structured text (text with tags etc. to give hierarchy and structure to it). Unfortunately, if you go and read the XML standard you discover that the language is an absolute nightmare. It is packed full of special cases and idiosyncracies such that you need a mega-complex parser to handle it all. Just the section on auto-detecting which character set is in use is a nightmare. I've written a full XML parser so I'm well aware of how complex the language spec is and how easy it is to screw up when you implement the parser. Personally, I would love to drop the disaster that is XML in favour of something similar but much simpler. Get rid of a lot of the unneccessary fluff like DTDs and Entities. Have simple mark-up and escape characters. Also have an explicit way of figuring out what character set you use (probably with a fixed length magic string at the top of the file). If you want the complex stuff like DTDs and the like, write the specifications as add-ons, rather than as core language. And insist that the add-on will be a well formed version of the original language.
an obviously biased article asserting a lot of FUD against Open Source software.... or 'freetards choice' as the Register seems to angle such options.
at least they could test the Open Source stuff properly as they has access to the source for their fuzzer. like to predict how many proprietary software apps and libraries are just (if not more) vulnerable? I'd choose the Open Source stuff any day - at least fixes tend to be quite rapid rather than waiting a month or more (eh Cisco?) until some special patch day - or until a known exploit is out in the wild :-(