Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

XML Library Flaw — Sun, Apache, GNOME Affected

Soulskill posted more than 5 years ago | from the finding-fast-fixes-for-flaws dept.

Security 140

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

cancel ×

140 comments

Sorry! There are no comments related to the filter you selected.

ASCII Delimited Security Issues (2, Insightful)

Algorithmn (1601909) | more than 5 years ago | (#28959217)

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 (4, Insightful)

sys.stdout.write (1551563) | more than 5 years ago | (#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.

Re:ASCII Delimited Security Issues (1)

Pulse_Instance (698417) | more than 5 years ago | (#28959589)

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 (4, Funny)

jopsen (885607) | more than 5 years ago | (#28959689)

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:ASCII Delimited Security Issues (0)

Anonymous Coward | more than 5 years ago | (#28960005)

I prefer not to find my bugs...

Who do you work for?

Re:ASCII Delimited Security Issues (1)

someone1234 (830754) | more than 5 years ago | (#28960115)

Maybe he is in the hotel business.

Re:ASCII Delimited Security Issues (1)

masshuu (1260516) | more than 5 years ago | (#28960325)

no, he is most likely in the restaurant business, possibly 3 or 4 Star

Ive seen more bugs in those places than in Mcdonalds, but i guess even bugs won't touch that stuff.

Re:ASCII Delimited Security Issues (0)

Anonymous Coward | more than 5 years ago | (#28960663)

What a dumb question.

Microsoft, obviously!

Re:Unit Tests (2, Insightful)

trwww (545291) | more than 5 years ago | (#28961329)

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

Re:ASCII Delimited Security Issues (1)

Algorithmn (1601909) | more than 5 years ago | (#28961823)

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:ASCII Delimited Security Issues (0)

Anonymous Coward | more than 5 years ago | (#28962849)

Sorry, but if you write this kind of tests, you should test the good, the bad and the ugly cases. You should write tests that prove that your parser rejects wrongly coded data, and fail gracefully.

Re:ASCII Delimited Security Issues (1)

k.a.f. (168896) | more than 5 years ago | (#28963483)

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?

Re:ASCII Delimited Security Issues (3, Informative)

Z00L00K (682162) | more than 5 years ago | (#28959371)

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:ASCII Delimited Security Issues (2, Insightful)

$1uck (710826) | more than 5 years ago | (#28960163)

Just be happy you don't have to play with SGML.

Re:ASCII Delimited Security Issues (2, Interesting)

shutdown -p now (807394) | more than 5 years ago | (#28961025)

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.

Re:ASCII Delimited Security Issues (1)

RegularFry (137639) | more than 5 years ago | (#28963763)

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.

Re:ASCII Delimited Security Issues (2, Insightful)

morgan_greywolf (835522) | more than 5 years ago | (#28959495)

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?

Re:ASCII Delimited Security Issues (1)

Algorithmn (1601909) | more than 5 years ago | (#28960469)

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

Re:ASCII Delimited Security Issues (1)

GooberToo (74388) | more than 5 years ago | (#28962593)

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.

Re:ASCII Delimited Security Issues (0)

Anonymous Coward | more than 5 years ago | (#28959587)

Too bad these developers don't know how to write good unit tests

All 500 billion quintillion unit tests to ensure every possible input EVAR can be parsed?

I think you're not really clear on what unit tests are capable of achieving in the absence of psychic powers, the presence of which would have invalidated the need for the test in the first place.

Re:ASCII Delimited Security Issues (2, Insightful)

Algorithmn (1601909) | more than 5 years ago | (#28960483)

I hope your not a developer... http://en.wikipedia.org/wiki/Unit_testing [wikipedia.org]

Re:ASCII Delimited Security Issues (0)

Anonymous Coward | more than 5 years ago | (#28960587)

All this says to me is that unit-testing as a whole is more of a concept with a 'best practices' than it is a concrete idea that has 'one solid method' of achieving. I sort of fail to see the point, but that's just me.

And they said XML was easy to parse (0)

Anonymous Coward | more than 5 years ago | (#28959265)

CSV FTW.

Re:And they said XML was easy to parse (3, Insightful)

ShadowRangerRIT (1301549) | more than 5 years ago | (#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:And they said XML was easy to parse (1, Insightful)

Anonymous Coward | more than 5 years ago | (#28959681)

well, I'd like json and bencode for that matter.

Re:And they said XML was easy to parse (3, Informative)

Desler (1608317) | more than 5 years ago | (#28959979)

Except CSV isn't a standard.

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

Re:And they said XML was easy to parse (2, Informative)

Timothy Brownawell (627747) | more than 5 years ago | (#28960099)

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

Re:And they said XML was easy to parse (2, Insightful)

ShadowRangerRIT (1301549) | more than 5 years ago | (#28960191)

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.

Re:And they said XML was easy to parse (1)

mzs (595629) | more than 5 years ago | (#28962135)

sed has been around for more than 20 years though and I bet a couple of one liners can fix most anything right up.

Re:And they said XML was easy to parse (1)

Timothy Brownawell (627747) | more than 5 years ago | (#28959785)

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?

Re:And they said XML was easy to parse (1)

Richard24 (1036452) | more than 5 years ago | (#28960113)

Most of the things you ask about can be done with CSV as long as it's quoted properly. If it's not quoted properly, then it would be considered invalid. There's a nice RFC spec for it here: http://www.ietf.org/rfc/rfc4180.txt [ietf.org]

What happens when your data contains \r or \n characters?

It's perfectly acceptable as long as you quote it (#6 example of RFC 4180). If Oracle doesn't support that, then I would say their implementation is broken.

What happens if the data has commas in it, and the .csv was generated by something that doesn't add quotes?

It's invalid

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

I'd need a better example from you, but you can embed a csv record inside a csv field. It starts to get complicated really fast with all the "escaping" that needs to be done with the double-quotes. Such as something like a record containing "Last Name","First Name","Sub-Properties". The Sub-Properties could be embedded data such as sex, age, and height. For example:

"Doe","John","""male"",42,""5-10"""

Clearly, you can represent tree style data with CSV, but it has more flexibility than you think. 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.

Re:And they said XML was easy to parse (1)

Timothy Brownawell (627747) | more than 5 years ago | (#28961061)

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.

Re:And they said XML was easy to parse (1)

FromFrom (698207) | more than 5 years ago | (#28960121)

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

Are you serious? The same thing one would do in a relational database if your data is more complicated than a simple table...

CSV (1)

DragonWriter (970822) | more than 5 years ago | (#28961235)

What happens when your data contains \r or \n characters?

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

What happens if the data has commas in it, and the .csv was generated by something that doesn't add 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.)

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

You use more than one CSV file in some appropriate wrapper.

Open source (-1, Troll)

heffrey (229704) | more than 5 years ago | (#28959279)

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?

Re:Open source (1)

maxume (22995) | more than 5 years ago | (#28959359)

I suggest switching to a diet of hay, for the higher protein content.

Re:Open source (0)

Anonymous Coward | more than 5 years ago | (#28959361)

you want someone to tell you what to think?

Re:Open source (2, Funny)

heffrey (229704) | more than 5 years ago | (#28960055)

You think I've come to the right place?

Re:Open source (2, Interesting)

gila_monster (544999) | more than 5 years ago | (#28959377)

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 these things, so you never know you're vulnerable and thus can't adjust for it.

Re:Open source (1)

FudRucker (866063) | more than 5 years ago | (#28959547)

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

Re:Open source (1)

recoiledsnake (879048) | more than 5 years ago | (#28959639)

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 (0)

Anonymous Coward | more than 5 years ago | (#28959855)

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?

You're actually trying to make money?!?! Blashphemy!

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

When have open source fundamentalists ever been about using the right tool for the job? They've always excluded any tool that doesn't match up to their shifting goalposts definition of "free software" as being the wrong tool for the job at every point in time.

Re:Open source (0)

Anonymous Coward | more than 5 years ago | (#28959891)

i gotta agree with snake. First of all if you work at a corporation open-source isn't always an option. Second, if a closed source company produces a better piece of software than open, I'll choose close source all day long.

Re:Open source (1)

Desler (1608317) | more than 5 years ago | (#28960125)

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?

But with The GIMP you get to waste weeks of your time trying to wade through it's crappy codebase trying to fix it's buginess and try to cram in features that it still doesn't have that Photoshop has had for almost a decade. You non-corportistas just don't understand how this is a benefit and not a flaw of the software!

Re:Open source (1)

Desler (1608317) | more than 5 years ago | (#28960419)

Oops that was supposed to be "corportistas" not "non-corportistas".

Re:Open source (0)

Anonymous Coward | more than 5 years ago | (#28959721)

"I don't have statistics to support a statement that critical errors like this happen less often with open source"

Of course you don't.

"but I would have no trouble believing that."

What about unicorns?

Re:Open source (1)

heffrey (229704) | more than 5 years ago | (#28962189)

Do you have any hard evidence of that or is it just faith?

Don't get me wrong I'm a big fan of open source, free software in the RMS meaning of free. But I just don't really get along with faith. It's quite astonishing how much of the commentary on Slashdot is all about faith with no reference to evidence. I guess we're all human though, even us techie geeks!

Re:Open source (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#28959407)

Since it's open source, it won't be bashed for days on end like MS would be. That's the only difference.

Re:Open source (2, Insightful)

bberens (965711) | more than 5 years ago | (#28959737)

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.

Re:Open source (0)

Anonymous Coward | more than 5 years ago | (#28960305)

Also, in typical open source fashion, the real developers have no responsibility, and readers are left to ponder which of Sun, Apache, or GNOME are responsible.
I call this the "Linux is not an operating system" defense. As in, they are quick to claim responsibility for success, but not any failures of a system. For that, they shift into a faceless cloud of ether and we are directed to a name such as RedHat, Sun, Apache, etc. It's as bad as two commercial vendors pointing fingers at each other.

Go go open source project, oh, but the integration with all that other crap? Don't look at me, they're all f'ing crazy.

For this, I feel no sorrow when open source doesn't get any recognition or credit. Look how Sun and Apache's necks get stuck out here.

http://xmlsoft.org/ [xmlsoft.org]
Take some responsibility, and /., give it to them.

Re:Open source (-1, Troll)

Anonymous Coward | more than 5 years ago | (#28959433)

Open sores software has always been shit. Anyone who says otherwise is a bigger propagandist than an M$ marketeer

Re:Open source (4, Informative)

jpmorgan (517966) | more than 5 years ago | (#28959451)

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.

Re:Open source (1)

Volante3192 (953645) | more than 5 years ago | (#28959649)

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.

Re:Open source (1)

quickOnTheUptake (1450889) | more than 5 years ago | (#28959815)

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. decides this is worth fixing and rolls a patch.

Re:Open source (1)

Timothy Brownawell (627747) | more than 5 years ago | (#28959881)

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 (1)

AceofSpades19 (1107875) | more than 5 years ago | (#28960301)

If thats the case, then exploits in acrobat reader and flash should be fixed next day, or in a few hours.

Re:Open source (1)

Desler (1608317) | more than 5 years ago | (#28961295)

Yeah, because there are never bugs in open source software that don't linger for months or years without being fixed. Nope they are all fixed within sheer minutes of the bug report. Oh wait...

Re:Open source (1)

AceofSpades19 (1107875) | more than 5 years ago | (#28962085)

There are always going to be bugs that linger for awhile, but exploits are usually fixed pretty quickly in high-profile F/OSS projects and compared to Adobe or Microsoft, I think they do pretty decent without having tons of paid developers

Re:Open source (1)

Icegryphon (715550) | more than 5 years ago | (#28959455)

8/10

Re:Open source (3, Informative)

ChienAndalu (1293930) | more than 5 years ago | (#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] ."

Re:Open source (1)

Ralish (775196) | more than 5 years ago | (#28960861)

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 have been in the source first, before you try and divert the conversation? Further, the exploits weren't found by the project authors, but by a security vendor who applied protocol fuzzing tools. Fuzzing tools operate on the binaries, and thus, the source code is irrelevant, you can run these tools on any software irrespective of the source-code ideology behind it. Where the open-source aspect may come into play is largely in patch response times, but the argument that they may have been found quicker in closed-source software is in this case unsubstantiated, and especially tenuous considering the mechanism that found them is equally applicable.

Of course, they might turn out to be entirely mundane, as the specifics of the vulnerabilities have not been disclosed, and security vendors tend to exaggerate the severity of any given vulnerability they find. But still, have you considered fixing your own house before immediately running out to abuse entirely unrelated software? It might not be long before someone is wondering about various [google.com] vulnerabilities in [google.com] open-source software [google.com] . Some restraint is useful considering the complete lack of solid information.

Re:Open source (1)

Ralish (775196) | more than 5 years ago | (#28960913)

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:Open source (1)

AlphaBit (1244464) | more than 5 years ago | (#28959543)

Given that perfection is impossible... I believe that the open source process is much less likely to lead to problems such as this. When it goes well. The problem is that being open source defines so little about how the work is actually getting done. I could create an open source math library consisting of: add(a, b){ return a*b; } , make it open source, post it on source-forge and everything, and then simply refuse outside contribution. This is not really a problem for the community since anyone can fork and fix, but if I happen to be a software giant that has integrated my own faulty code into half of my products...

i just built firefox-3.5.2 from the sause (1)

FudRucker (866063) | more than 5 years ago | (#28959391)

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:i just built firefox-3.5.2 from the sause (1)

maxume (22995) | more than 5 years ago | (#28959471)

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:i just built firefox-3.5.2 from the sause (0)

Anonymous Coward | more than 5 years ago | (#28959597)

Firefox would need recompiling (after being fixed) not because of Python used in the build system, but because it would have its own included XML code that would be vulnerable to the flaws.

This really only applies to applications that statically link libxml... if the updated libraries are binary compatible and an application is dynamically linked to libxml, it would just require a restart of the application. There would be a lot of apps with libxml built right in though.

Re:i just built firefox-3.5.2 from the sause (1)

bberens (965711) | more than 5 years ago | (#28959801)

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.

Re:i just built firefox-3.5.2 from the sause (1)

Mr. DOS (1276020) | more than 5 years ago | (#28960481)

So... Gentoo users are screwed?

      --- Mr. DOS

Re:i just built firefox-3.5.2 from the sause (0, Redundant)

element-o.p. (939033) | more than 5 years ago | (#28960551)

So unless you literally roll your own of everything a simple update should suffice.

I'm a Gentoo user, you insensitive clod!

Re:i just built firefox-3.5.2 from the sause (1)

Desler (1608317) | more than 5 years ago | (#28961331)

You should be dynamically linking anyway so you only have to recompile the libs not the entire program.

Article?? (4, Insightful)

funkatron (912521) | more than 5 years ago | (#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.

Re:Article?? (1)

jpmorgan (517966) | more than 5 years ago | (#28959517)

Most responsible security researchers give developers an opportunity to fix and deploy patches to security flaws, before disclosing that kind of information.

Re:Article?? (2, Informative)

Anonymous Coward | more than 5 years ago | (#28959653)

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:Article?? (0)

Anonymous Coward | more than 5 years ago | (#28962277)

Really? Which cert advisory is that? I've been looking and I can't find one. These guys seem to be trying for publicity. Vague claims about vulnerabilities, no details, no specifics -- and no CERT advisory.

Crying Wolf (0)

Anonymous Coward | more than 5 years ago | (#28959677)

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.

Re:Article?? (1)

RichiP (18379) | more than 5 years ago | (#28959905)

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

Example (1)

ebcdic (39948) | more than 5 years ago | (#28960011)

Google for "billion laughs".

Re:Example (0)

Anonymous Coward | more than 5 years ago | (#28962425)

why? That is an old issue and this is supposedly a new one. As an example of a bug? Sure, but that isn't what the GP was asking for. The "security researchers" appear to be guilty of FUD for the sake of publicity.

Re:Article?? (2, Funny)

Odin's Raven (145278) | more than 5 years ago | (#28961637)

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? (4, Insightful)

neonprimetime (528653) | more than 5 years ago | (#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

Re:Why is Python excluded from Title? (5, Funny)

recoiledsnake (879048) | more than 5 years ago | (#28959701)

Because pythons are long and big and will not fit the title.

Re:Why is Python excluded from Title? (2, Insightful)

jDeepbeep (913892) | more than 5 years ago | (#28960513)

Because pythons are long and big and will not fit the title.

You should get the extra mod point on top of the current 4, just for the fact that your /. name has the word 'snake' in it.

Re:Why is Python excluded from Title? (2, Interesting)

kill-1 (36256) | more than 5 years ago | (#28959927)

Also, the linked article and the news on the Codenomicon website don't mention GNOME.

Re:Why is Gnome included in the Title? (1)

karavelov (863935) | more than 5 years ago | (#28960009)

Gnome parser is not even mentioned in the article but appears in the /. title...

Re:Why is Gnome included in the Title? (0)

Anonymous Coward | more than 5 years ago | (#28963317)

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.

Solution (2, Insightful)

vainvanevein (1428547) | more than 5 years ago | (#28959719)

The solution is clear to me. I would stop using XML.

DoS? (1)

mapinguari (110030) | more than 5 years ago | (#28959733)

could result in successful denial-of-service attacks

Ah yes, but could it result in successful denial-of-cellphone-service?

Which XML libraries? (3, Insightful)

wowbagger (69688) | more than 5 years ago | (#28960245)

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.

Re:Which XML libraries? (1)

inio (26835) | more than 5 years ago | (#28961093)

Considering GNOME is affected, it's probably libxml2 [xmlsoft.org] .

Array bound checking? (1)

Twillerror (536681) | more than 5 years ago | (#28960385)

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.

Re:Array bound checking? (1)

owlstead (636356) | more than 5 years ago | (#28961381)

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:Array bound checking? (1)

HiThere (15173) | more than 5 years ago | (#28961619)

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 run-time.] I could also have selected Java as an option, as I believe it defaults to including bounds checking, but an OS written in an interpreted language sort of bothers me...and gcj appears to have stalled [as of the last time I looked, about a year ago].)

Re:Array bound checking? P.S, (1)

HiThere (15173) | more than 5 years ago | (#28961813)

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

bitEch (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#28960771)

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

XML... (1, Interesting)

menkhaura (103150) | more than 5 years ago | (#28961059)

See signature.

random gibberish to make lameness filter happy.

Re:XML... (2, Interesting)

owlstead (636356) | more than 5 years ago | (#28961851)

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

Handling URI's (1)

owlstead (636356) | more than 5 years ago | (#28961443)

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.

Someone just rediscovered XML Entity Attacks (3, Interesting)

Rich (9681) | more than 5 years ago | (#28962499)

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 (2, Informative)

Anonymous Coward | more than 5 years ago | (#28963787)

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/

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?