Stories
Slash Boxes
Comments
typodupeerror delete not in

Book Reviews

Recent reviews from Slashdot readers:

Submitting a review for consideration is easy; please first read Slashdot's book review guidelines. Updated: 2008114 by samzenpus

Comments: 140 +-   XML Library Flaw — Sun, Apache, GNOME Affected on Wednesday August 05, @11:27AM

Posted by Soulskill on Wednesday August 05, @11:27AM
from the finding-fast-fixes-for-flaws dept.
security
software
sun
apache
it
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)."
story

Related Stories

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • 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..
    • by sys.stdout.write (1551563) on Wednesday August 05, @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.

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

      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)

        Just be happy you don't have to play with SGML.
      • 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.

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

  • 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...
      • Yeah, and I can't imagine that the major distros won't be putting up patched binaries of any applications which need it. So unless you literally roll your own of everything a simple update should suffice.
  • Article?? (Score:5, Insightful)

    by funkatron (912521) on Wednesday August 05, @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!

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

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

  • by neonprimetime (528653) on Wednesday August 05, @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
  • 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?

  • by wowbagger (69688) on Wednesday August 05, @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.

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

    See signature.

    random gibberish to make lameness filter happy.

    • Re: (Score:3, Interesting)

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

  • by Rich (9681) on Wednesday August 05, @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.

    • Re: (Score:3, Interesting)

      You'll probably getted tagged 'troll' for that, but I'll bite.

      It's not that open source is not susceptible to these things (all software is). But with open source, these things are usually found more quickly, and are generally patched/fixed more quickly. I don't have statistics to support a statement that critical errors like this happen less often with open source, but I would have no trouble believing that.

      Open source is usually more transparent about the problem, too. Many closed source vendors hide thes

      • to the parent & grandparent post, plus with the source available you can check for anything malicious in the code before the binary is built. or rebuild with different parameters making it more secured against flaws by leaving out or changing the parts that are flawed or adding your own patches further hardening the app against vulnerabilities.

        to the grandparent only: if you dont see the advantages of Open Source software to all users be it commercial or personal then you are not a user yourself and
        • to the grandparent only: if you dont see the advantages of Open Source software to all users be it commercial or personal then you are not a user yourself and are just a corporate type with the corportista mindset, i got news for you = money is not everything and people will go out of their way to get your greedy little paws out of their pockets.

          So, if I need Photoshop as part of my job to feed my family, I'm just a corporate type with the corportista mindset and I should either switch to Gimp and pull my hair and lose time and clients or let my family starve?

          Whatever happened to using the right tool for the job, instead of letting zealotry take over?

    • Re:Open source (Score:5, Informative)

      by jpmorgan (517966) on Wednesday August 05, @11:44AM (#28959451) Homepage
      Someone will undoubtedly say that the bug being found was part of the process, since it's open source and that means the source is auditable by anybody. Reality: it was discovered by the maker of a fuzzing tool. Fuzzing is the process of sending garbage into software to see if it breaks... it works quite well and generally doesn't require the source code.

      Also, fuzzing discovers DoSes. But many DoS attacks turn into vulnerabilities in the hands of a skilled hacker, and it's generally not safe to assume that a DoS is unexploitable without extensive code analysis.
      • it works quite well and generally doesn't require the source code.

        But here, since it's open source, we don't have to rely on coders in a white tower to patch the code directly or someone to hack an intermediate patch. We can start looking right away.

      • Way to beat that strawman!
        Couldn't you have at least waited until a linux fanboi didn't understand the summary and made a dumb comment?
        All that aside, the way these projects' being open source will make this better is by making a patch come out sooner. The community knows there is a problem. Someone will get on finding it right away, and in a day or two we will see patches getting pushed out that fix it. There's no sitting around helplessly hoping we don't get DoSed until someone at MegaSoft Corp. decide
        • All that aside, the way these projects' being open source will make this better is by making a patch come out sooner. The community knows there is a problem. Someone will get on finding it right away, and in a day or two we will see patches getting pushed out that fix it. There's no sitting around helplessly hoping we don't get DoSed until someone at MegaSoft Corp. decides this is worth fixing and rolls a patch.

          This is because the Community has unlimited volunteer resources available on very short notice, and large corporations with many paid full-time employees do not.

    • Re:Open source (Score:4, Informative)

      by ChienAndalu (1293930) on Wednesday August 05, @11:47AM (#28959499)

      Think "
      I wonder if [google.com] these vulnerabilites could have [google.com] been found earlier [google.com] if the code was [google.com]open source [google.com]."

      • Hey man, you did "adobe xml vulnerability" twice!! Admittedly, their security record is appalling, particularly as of late, but still, play fair ;)

        More seriously, an article comes out about multiple XML vulnerabilities in multiple open-source XML libraries and your immediate reaction is to rush out and try and shine the light on XML vulnerabilities in closed-source code?! How about you first wait to find out the severity of the exploits in the open-source software, and equally importantly, how long they hav

        • Only just noticed you were replying to a (hidden) troll, which changes the tone of my reply a little, but the point about applicability of fuzzing tools is in my view still entirely valid. Sorry about my remark that you rushed out to change the conversation.
      • Re: (Score:3, Insightful)

        Since MS is closed source, it wouldn't be fixed for months on end like open source is. That's the only difference. See? It works both ways, neither is really helpful.
    • by ShadowRangerRIT (1301549) on Wednesday August 05, @11:44AM (#28959453)
      Except CSV isn't a standard. While the general idea is similar, the details differ greatly from parser to parser. Do you need a trailing comma on the line? Do you allow leading or trailing space on an entry? Since most generators use slightly different conventions, parsers need to be significantly more complex. And CSV is far more limited in scope. I think of CSV as the scripting language to XML's high level OO VM language. Neither is a particularly efficient format, but they're both easier to work with than the alternative (binary coded data), and they're each good for different things. CSV works well for simple data structures, just like scripting languages are appropriate for small utility programs, while XML is good for complex, rigidly defined structures, just like a high level OO language is more appropriate to large projects where maintainability is a concern.
      • Re: (Score:3, Informative)

        Except CSV isn't a standard.

        The IETF [ietf.org] might disagree with you.

        • Except CSV isn't a standard.

          The IETF [ietf.org] might disagree with you.

          "This memo provides information for the Internet community. It does not specify an Internet standard of any kind. "

        • Interesting. Of course, it was only published in 2005. If they'd written this up 20 years ago, it might have been more helpful. As is, the various CSV writers have been around so long that a lot of non-conformant CSV is out there. So the parsers remain fairly complex, to account for the previously undefined behaviors. And of course, that standard is for a MIME type; non-web focused CSV generators will still ignore parts of it.
    • CSV FTW.

      What happens when your data contains \r or \n characters? (I know Oracle's sqlldr / external tables at least will reject that row, and I don't believe they recognize any escape sequence for this.) What happens if the data has commas in it, and the .csv was generated by something that doesn't add quotes?

      What do you do if your data is more complicated than a simple table?

        • If Oracle doesn't support that, then I would say their implementation is broken.

          I'd just suspect it's more than 4 years old (hmm, looks like the 10gR2 we're using was actually released in 2005, and that RFC is dated October 2005). The "standard" is "this seems to be what most people are doing" rather than "here's the definition of a cool new format".

          Clearly, you can represent tree style data with CSV, but it has more flexibility than you think.

          Hm, cool. Also, ick.

          Too many people roll their own CSV, because it seems so simple. Then they don't quote and escape quotes properly blaming any issues on garbage data.

          ...and then I have to tweak it into the csv dialect that Oracle understands.

Darth Vader sleeps with a Teddywookie.