Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security Software Sun Microsystems Apache IT

XML Library Flaw — Sun, Apache, GNOME Affected 140

Posted by Soulskill from the finding-fast-fixes-for-flaws dept.
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)."
This discussion has been archived. No new comments can be posted.

XML Library Flaw — Sun, Apache, GNOME Affected More

XML Library Flaw — Sun, Apache, GNOME Affected

Comments Filter:
  • 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..

    • Re:ASCII Delimited Security Issues (Score:5, Insightful)

      by sys.stdout.write ( 1551563 ) on Wednesday August 05, 2009 @11:39AM (#28959351)

      Too bad these developers don't know how to write good unit tests... This could have been avoided..

      That's unfair. I'm all about unit tests and they do help find bugs, but a unit test isn't going to find a precisely-crafted piece of malicious input.

      • A properly written unit test might have a chance of finding it if you take the approach of writing your unit tests by looking at how the function can fail. It is still unlikely that you will find it but the most important thing after something like this is found is to add it to your unit tests and look for similar mistakes elsewhere.

        • Re:ASCII Delimited Security Issues (Score:5, Funny)

          by jopsen ( 885607 ) <jopsen@gmail.com> on Wednesday August 05, 2009 @11:59AM (#28959689) Homepage

          A properly written unit test might have a chance of finding it if you take the approach of writing your unit tests by looking at how the function can fail.

          I prefer not to find my bugs...

        • Re:Unit Tests (Score:2, Insightful)

          by trwww ( 545291 )

          Exactly. Unit tests do not prove the absence of bugs. They prove the existence of bugs.

        • A properly written unit test might have a chance of finding it if you take the approach of writing your unit tests by looking at how the function can fail. It is still unlikely that you will find it but the most important thing after something like this is found is to add it to your unit tests and look for similar mistakes elsewhere.

          Presumably (especially considering how long the bug has managed to go unnoticed and how prevalent it is), it's obscure and an implementation detail (then again, most bugs are). You can't expect random developers to have this kind of knowledge of an underlying XML library -- especially when the rest of the world had no clue either. Despite being unit tested all around the world, nobody has managed to find and report this bug prior to this person. Doesn't that say anything?

          • It says plenty which is why I added the second half of what I said.

            It is still unlikely that you will find it but the most important thing after something like this is found is to add it to your unit tests and look for similar mistakes elsewhere.

            I've found that unit testing will catch obvious things and things that you have seen before. Now that this has been found if they unit test for it, not just in the location where it happened but anywhere it makes sense, they can be more sure that it does not happen again.

        • But this is the flaw inherent in such unit tests themselves -- they can only think of such unit tests that the developer is able to conceive of. If I look at a function and think of 10 ways for it to fail, you can be there will be an 11th that I missed. Blaming inadequate unit testing in this case (as OP has done) is indicative of a misguided faith in the capability of programmatic unit tests: they're intended to let you catch the things you can think of, and retroactively add coverage for those scenarios
      • I disagree. Unit tests are only as good as the author of the code. I like fuzzing. So if I were to unit test my own code I would try millions of possibilities. "Too bad" I just break and not make software.

      • Re: (Score:2)

        by k.a.f. ( 168896 )

        That's unfair. I'm all about unit tests and they do help find bugs, but a unit test isn't going to find a precisely-crafted piece of malicious input.

        No, probably not. The formal verification would have done that. And yes, I do think code that has the potential to introduce undefined behaviour into high-profile libraries must be verified before you may loose it on the world, why do you ask?

      • Too bad these developers don't know how to write good unit tests... This could have been avoided..

        That's unfair. I'm all about unit tests and they do help find bugs, but a unit test isn't going to find a precisely-crafted piece of malicious input.

        Yes, it could if you're talking about fuzzers. Having made fuzzers for a few programs, it really is amazing how many bugs they catch, how many crashes they cause, and how often they suggest the ability to control execution based on matching up the data in registers with data in the fuzzed input file. There should definitely be some fuzz testing done. I never really thought about it in the context of open-source software-- anybody know what practices are for different projects or where they would get comp

    • Re:ASCII Delimited Security Issues (Score:4, Informative)

      by Z00L00K ( 682162 ) on Wednesday August 05, 2009 @11:40AM (#28959371) Homepage Journal

      XML in itself is sometimes a denial of service with strange side-effects.

      As soon as you insert XML that isn't well-formed into a XML parser it will barf in one way or another. And then you will have to dedicate hours to figure out which tag/data in a 200kB XML request that was the culprit. If you are lucky you get a parsing exception, if not you get a Null pointer exception or an infinite loop in the parser.

      • Re: (Score:3, Insightful)

        by $1uck ( 710826 )
        Just be happy you don't have to play with SGML.

      • Re: (Score:3, Interesting)

        by shutdown -p now ( 807394 )

        Refusing to handle invalid input isn't denial of service. Also, I haven't seen any XML parser that would give you a null pointer/reference exception on invalid input. In fact, all that I've used will give the exact line/column number at which error happened.

        • Refusing to handle invalid input isn't denial of service.

          It is if the app developer omits to handle it because "oh, that'll never happen." This is not an uncommon attitude, unfortunately.

        • then you will have to dedicate hours to figure out which tag/data in a 200kB XML request that was the culprit

          Refusing to handle invalid input isn't denial of service

          I think he probably meant denial of service from the developer's employer's point of view.

      • Re: (Score:2)

        by lennier ( 44736 )

        "As soon as you insert XML that isn't well-formed into a XML parser it will barf in one way or another."

        So don't do that, then?

        "On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."

      • >>As soon as you insert XML that isn't well-formed into a XML parser it will barf in one way or another. And then you will have to dedicate hours to figure out which tag/data in a 200kB XML request that was the culprit. If you are lucky you get a parsing exception, if not you get a Null pointer exception or an infinite loop in the parser.

        What are you talking about?

        If by "you will have to dedicate hours to figure out which tag/data in a 200kB XML request that was the culprit...", you mean "reject the d

    • Re: (Score:2, Insightful)

      by morgan_greywolf ( 835522 )

      It's just as easy to fuzz a binary-encoded protocol, it just doesn't require specialized tools. Ever heard of TCP/IP-based DoS attacks?

      • I've written both ASCII and Binary fuzzers. Binary is harder. My ASCII fuzzer found over 10 million possible mutations while the Binary fuzzer found less then a million. If I had to argue with myself maybe I should have said "harder to write a successful fuzzer".

      • Actually this has been exploited very rarely; excluding MS Windows which had a gambit of well publicized issued of the last decade plus. Most notably being the packet of death which causes Windows boxes to crash/reboot.

        Most of the TCP/IP related DoS attacks stem from exploitation of the protocol, not the binary packet format.

  • 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...

    • Re: (Score:1)

      by maxume ( 22995 )

      If you are nuts. You would probably be better off spending 20 minutes to first figure out if there are any situations where you are feeding untrusted xml input into python, rather than completely spazzing out.

    • Re: (Score:2)

      by iYk6 ( 1425255 )

      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?

      No. It sounds like Firefox uses python build scripts. There is no risk from using an exploitable Python with "trusted" input, such as the Firefox build scripts. Additionally, this flaw will not "carry-over" from the build scripts to the Firefox code. As long as your Firefox got built, it didn't really matter which version of Python you used.

      The only way that this flaw could possibly have any bearing on the Firefox build scripts if Mozilla tried to exploit your computer using this flaw in their build scripts

  • Article?? (Score:5, Insightful)

    by funkatron ( 912521 ) on Wednesday August 05, 2009 @11:44AM (#28959439)
    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.
    • Most responsible security researchers give developers an opportunity to fix and deploy patches to security flaws, before disclosing that kind of information.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        I think they infact did it in very responsible way. If you read the CERT advisory and everything, it seems they have worked good part of the year with the industry and CERTs to make sure these problems are actually fixed before letting ppl know!

    • Re: (Score:2)

      by RichiP ( 18379 )

      I was thinking the same thing. The article was just too light on details. Even if I wanted to test my systems and even fix them, I wouldn't know where to begin. The article also doesn't mention if the people at Sun, Apache, Gnome, etc. were informed of the specifics of the vulnerability.

      Since XML is handled by these projects using libraries (libxml2 in Gnome and Xerces, Xerces2 and Xalan for Apache), wouldn't fixing these libraries effectively fix the "millions of these applications"?

    • Google for "billion laughs".

    • Re: (Score:3, Funny)

      by Odin's Raven ( 145278 )

      Would be interesting to see examples of the malicious XML and an explanation of how the vulnerabilities work.

      I've included a simple demonstration below - if your browser doesn't contain the flaw then you'll just see the literal XML exploit code (all 200+ lines of it), but if it's vulnerable then you'll only see the initial trigger element on either side of Cmdr Taco's favorite topic.

      <\0pwned>OMGPonies!!11one!<\0pwn3d/>

  • Why is Python excluded from Title? (Score:5, Insightful)

    by neonprimetime ( 528653 ) on Wednesday August 05, 2009 @11:50AM (#28959557)
    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

  • Solution (Score:2, Insightful)

    by vainvanevein ( 1428547 )
    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?

  • Which XML libraries? (Score:4, Insightful)

    by wowbagger ( 69688 ) on Wednesday August 05, 2009 @12:35PM (#28960245) Homepage Journal

    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.

  • 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.

    • Java (well, at least "Sun" code) and Python are in there, and since at least Java's XML libraries are fully native to the VM which *does* perform bounds checking, this is clearly something else. It's probably more in the semantics than in the syntax; e.g. treating URI's as URL's and following them without checking if they are from the same host.

    • Re: (Score:2)

      by HiThere ( 15173 )

      Optimization isn't what you want here. It has a tendency to remove expensive checks, like checks that an array boundary isn't being overwritten.

      There are a couple of reasonable ways to handle this, but optimization isn't one of them. (My favorite would be to re-write everything in D. I'd've mentioned Ada also, but gnat, by default, doesn't implement the array bounds checking that Ada includes. [It's there, but you've got to select a special compiler option to get it, because that check is expensive at r

      • 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 featur

  • XML... (Score:2, Interesting)

    by menkhaura ( 103150 )

    See signature.

    random gibberish to make lameness filter happy.

    • Re: (Score:3, Interesting)

      by owlstead ( 636356 )

      I would if the slashdot UI would have a link or button on the page to view the signature of individual messages.

  • 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

  • Someone just rediscovered XML Entity Attacks (Score:4, Interesting)

    by Rich ( 9681 ) on Wednesday August 05, 2009 @03:25PM (#28962499) Homepage

    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 [securiteam.com]
    http://www.sift.com.au/assets/downloads/SIFT-XML-Port-Scanning-v1-00.pdf [sift.com.au]

    I've used these attacks in real-world tests and they are still surprisingly effective - just not new.

  • Advisories released (Score:2, Informative)

    by Anonymous Coward

    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/

Slashdot Top Deals

Economists state their GNP growth projections to the nearest tenth of a percentage point to prove they have a sense of humor. -- Edgar R. Fiedler

Close