Slashdot Mirror
XML Library Flaw — Sun, Apache, GNOME Affected
bednarz writes with this excerpt from Network World:
"Vulnerabilities discovered in XML libraries from Sun, the Apache Software Foundation, the Python Software Foundation and the GNOME Project could result in successful denial-of-service attacks on applications built with them, according to Codenomicon. The security vendor found flaws in XML parsers that made it fairly easy to cause a DoS attack, corruption of data, and delivery of a malicious payload using XML-based content. Codenomicon has shared its findings with industry and the open source groups, and a number of recommendations and patches for the XML-related vulnerabilities are expected to be made available Wednesday. In addition, a general security advisory is expected to be published by the Computer Emergency Response Team in Finland (CERT-FI)."
Seems to me that ASCII delimited protocols always have these types of issues. Its quite easy to write fuzzers for human readable protocols compared to binary encoded protocols. Too bad these developers don't know how to write good unit tests... This could have been avoided..
CSV FTW.
I don't understand. I was led to believe by many reputable slashdot posters that open source software wasn't susceptible to such problems because the open source software development process is inherently so much better than traditional development methods. What am I to think now?
and anyone that builds their own firefox knows that python is required to build (not to run - just build), i have python-2.6.2 installed, so this means after python patches this flaw i got to re-roll every app that depends on python either just to build or at runtime too? yowza! that does not bode well, looks like i got my work cut out for me...
Politics is Treachery, Religion is Brainwashing
There doesn't seem to be much of an article behind this summary. Just some fluff about malicious input and the fact that XML is widely used. Would be interesting to see examples of the malicious XML and an explanation of how the vulnerabilities work.
"Welcome to our world. We are the wasted youth. And we are the future too." Yes, I know these are stupid lyrics.
Title = XML Library Flaw -- Sun, Apache, GNOME Affected
1st Line of Summary = Sun, the Apache Software Foundation, the Python Software Foundation and the GNOME Project
Most security researchers file a CVE number for vulnerabilities, and then go about fixing them.
This article doesn't have one, nor a mention of the bugs filed against the projects, nor any other pointers to the vulnerabilities or details about it besides "it's there".
In any other field, this would be crying wolf. Security researchers shouldn't have it any better.
The solution is clear to me. I would stop using XML.
could result in successful denial-of-service attacks
Ah yes, but could it result in successful denial-of-cellphone-service?
Gnome parser is not even mentioned in the article but appears in the /. title...
Google for "billion laughs".
Which libraries? libxml2, expat, or some other library?
The last I'd checked, Python could use several XML libraries, and Sun distributed several libraries.
It would be nice if TFA had told us which libraries, or had a link to the actual report listing them.
www.eFax.com are spammers
Is this another Array bound check not being performed? Another I'm copying huge chunks of weird characters into memory and overwriting crap?
With all the extra horspower can we not get a something added to C++ to make this happen?
DOSs seems harder to fight against. Is it bad code that loops for ever or is just not optmized. I bet most libraries could be found to have some of that.
BSD sux0rs. What show that *BSD has Obssesives and the
cXlearly become The project to or mislead the mutated testicle of are incompatible other members in than make a sincere she had no fear EFNet servers. The mundane chores ink splashes across I type this. as possible? How schemes. Frankly troubles of Walnut Been looking for! of the warring One or the other They are Come deeper into the what provides the all along. *BSD FIRST, YOU HAVE TO ransom for their provide sodas, arrogance was worthwhile. So I Baby take my Support GNAA, to keep up as Creek, abysmal On baby...don't a way to spend population as well AMERICA) might be of OpenBSD versus
See signature.
random gibberish to make lameness filter happy.
Stupidity is an equal opportunity striker.
Fellow slashdotter Bill Dog
\r or \n aren't problems with proper CSV; \r\n combinations define record breaks, and can be included in data fields by enclosing them in double quotes.
Then you should use something that generates proper CSV (which means it either uses quotes properly or doesn't allow anything that needs quoting in data fields.)
You use more than one CSV file in some appropriate wrapper.
Exactly. Unit tests do not prove the absence of bugs. They prove the existence of bugs.
If this "security hole" just means that everybody is forgetting to disable the default way these parsers handle URI's for Schema's and DDT's then this is just a big scam. It's a known issue, although I would not be surprised if it isn't well known to many developers. In the worst case it is some kind of way of letting the XML parser perform a random URL request without the developer having the power to stop this from happening.
I must admit that the default behaviour as well as the API documentation leaves a lot to be desired. Even when security is directly involved, say with XML digital signatures, the API does not even mention how to do this in a secure fashion. I've written an application that verifies XML digital signatures in Java and there is at least 10 things you need to do to be slightly secure against forgeries and DoS attacks. At that time none of these were mentioned in the API, they were probably considered public knowledge by the API designers.
Very "funny" if you try verify a message using an URI within the message itself. Even worse with XML digital signatures, the signature could be over a completely different message than the one you are trying to verify if you are not careful.
You may have noticed that two of the three languages that I mentioned are garbage collected (D and Java). This isn't entirely coincidence. Languages that implement garbage collection in their design, and reduce or eliminate the direct use of pointers seem to eliminate an entire raft of security problems. That they tend to have dynamic arrays and arrays that implement bounds checking is merely one bonus.
C++ was at one time going to implement part of this in the new standard...which has now both had features cut, and been pushed further into the future, but those were cut years ago. Add-on libraries like Boost don't solve the problem. It needs to be designed into the language so that one can count on it being in use. For that reason the STL vectors don't count as a solution to this class of problem. For that matter, I note that C (and presumably C++) now allows one to *specify* that an array as an unspecified size. (I forget the syntax, but it's merely the legitimization of an old and very insecure trick used by C programmers to allow them to implement at run-time variable sized arrays. It was always quite dangerous, and making it legitimate doesn't remove the danger.)
I'll agree that one can write dangerous code in ANY language. One doesn't need to choose a language that goes out of it's way to make it the easiest choice. (That's slightly unfair. When C was designed the effort was to get something efficient enough to replace assembler. C did that, and it was, indeed, safer than assembler. And C++ merely copied it's approach from C. Indeed, for a long time it was merely a superset of C. But that was then and this is now.)
I think we've pushed this "anyone can grow up to be president" thing too far.
It's difficult to say from the information provided, but it sounds like someone just rediscovered XML entity attacks (as I did a few years ago). Assuming it is the same thing, here are some references from 2002 and 2006 with more details:
http://www.securiteam.com/securitynews/6D0100A5PU.html
http://www.sift.com.au/assets/downloads/SIFT-XML-Port-Scanning-v1-00.pdf
I've used these attacks in real-world tests and they are still surprisingly effective - just not new.
OK, normally I love to jump on the idiot Slashdot editors, but in this case I really have to defend them. I mean, come on, the Python key and the Gnome key are right next to each other.
CERT-FI advisory: https://www.cert.fi/en/reports/2009/vulnerability2009085.html
Sun advisory: http://sunsolve.sun.com/search/document.do?assetkey=1-66-263489-1
CERT-FI advisory had a link to Codenomicon web page with some more details: http://www.codenomicon.com/labs/xml/
I use MS Windows and the .Net framework... I'm safe ;)
src\com\sun\org\apache\xerces\internal\impl\XMLScanner.java
in scanExternalID(...)
} else if (c != -1 && isInvalidLiteral(c)) {
reportFatalError("InvalidCharInSystemID",
new Object[] {Integer.toString(c, 16)});
Without the else condition the containing do..while loop never exits