▲ 219 points
back
116 comments
The irony is that CDATA isn't even very useful; there's no way to escape the ]]> closing tag so you still have to invent some special escaping mechanism to use it.
Nobody expects entity definitions in XML either, and yet about once a year some new service or software is found vulnerable to XXE attacks. (Summary: a lot of XML parsers can be made to open arbitrary files or network sockets and sometimes return the content.)
XML is a ridiculously complex document format designed for editing text documents. It is not a suitable data interchange format. Fortunately we have JSON now.
designed for editing text documents
This sort of argument has never held water, and it constantly perplexes me that it gets a pass in tech discussions. Even if we accept the dubious assertion that it was "designed" for editing text documents, the origins of some invention say literally nothing about its utility for a purpose.
Further, as complex as XML may be, comparing the robust, rich, diverse ecosystem of XML support with the amateur hour, barely credible JSON world is quite a contrast. JSON doesn't even have a date type (and everyone seems to roll their own). It lacks any sort of robust validation or transformation system: XML schemas are really one of XML's greatest features, and the nascent, mostly broken similes in JSON world don't compare.
JSON versus XML is a lot like NoSQL versus RDBMS -- the former is easier to pitch because its complete absence of a wide set of functionality seems like it makes implementations easier, when really it just pushes the complexity down the road.
I like XML for structured data. I also like XSL for self-documenting format to format conversion (or display). However I am going to respectfully disagree with you about XML schemas, they suck...
XML schemas don't "understand" XML the language, and as a result you cannot use schemas unless you're using XML wrongly. For example, in XML:
<myroot>
<thing>
<name>Robot</name>
<size>15</size>
</thing>
<person>
<name>John Smith</name>
<id>12345</id>
</person>
</myroot>
<myroot>
<person>
<name>John Smith</name>
<id>12345</id>
</person>
<thing>
<name>Robot</name>
<size>15</size>
</thing>
</myroot>
It is possible to do with just one node switch in the above example, but convoluted. As you add more and more nodes the definition becomes unmanageable, imagine 10+ nodes on the same "level" but they can be ordered randomly, and are all required (and your schema needs to check they exist).
XML schema sucks, really sucks, when you use XML correctly and ignore node order. So if you choose to use a schema you're then forced to also require everything in an exacting order which can be problematic when XML is automatically generated from dozens of different systems or people.
XML schema sucked so bad we wrote our own replacement in Java. It just generates an XML DOM tree (via the standard libraries), then it parses your "schema" file which is just a list of XPaths with either a required, optional, or excluded flag. It is like 20 lines of code and it is better than XML Schema language.
With JSON you use a programming language to transform your data. You also use a programming language to validate your data. Validating and transforming data are some of the most basic capabilities of all general-purpose programming languages, and reinventing these facilities badly in a not-exactly-programming-language like XSLT or XML Schema is a waste of time.
> XML schemas are really one of XML's greatest features
So great that you get to choose between the schema system that's horribly complex (XML Schema) and the schema system that no one uses (DTDs).
> JSON versus XML is a lot like NoSQL versus RDBMS -- the former is easier to pitch because its complete absence of a wide set of functionality seems like it makes implementations easier, when really it just pushes the complexity down the road.
XML is like CORBA: a complicated mess whose proponents seem genuinely unaware that it's possible to achieve the same goals in a much simpler way (like Protocol Buffers).
You are allowed to chain CDATA-tags: ]]]]><![CDATA[>
> CDATA sections may occur anywhere character data may occur;
Is it just me who sees this as a very bad idea?
> XML is a ridiculously complex document format designed for editing text documents. It is not a suitable data interchange format. Fortunately we have JSON now.
XML is about as simple as it gets for structured text documents. HTML is more complicated. Plain text is not expressive enough. Markdown, Asciidoc, reStructuredText, Wiki Creole, etc. all have pretty severe shortcomings by comparison to XML, and text processing systems will sometimes just convert those formats to XML. XML is easy to parse, easy to edit, and easy to emit.
XML also gives us SVG, which is lovely.
Yeah, use JSON everywhere else. But XML is not ridiculously complicated. The 1.0 specification http://www.w3.org/TR/REC-xml/ is not very long.
> XML also gives us SVG, which is lovely.
That implies that SVG needed XML. SVG just needed a structured data format. It could just as easily have used JSON or Protocol Buffers and it would still be SVG.
> XML is easy to parse
More like it seems easy to parse. Plenty of people think they are parsing XML but their ad hoc "parsers" know nothing about CDATA, DTDs, external entities, processing instructions, or comments.
> easy to edit
...except for gotchas like the fact that you need to entity-escape any ampersands in attributes (like "href").
> and easy to emit
Harder than it sounds. A single error renders the whole document invalid, and when you're compositing information from different data sources, it's easy to make mistakes: https://web.archive.org/web/20080701064734/http://diveintoma...
> The 1.0 specification http://www.w3.org/TR/REC-xml/ is not very long.
Sure, but combined with the other specs which are assumed to be part of a modern XML stack (namespaces at least, and often XML schema, XSLT, etc), you have grown a pretty complicated mess that isn't a great match for what it's often used for.
> But XML is not ridiculously complicated. The 1.0 specification http://www.w3.org/TR/REC-xml/ is not very long.
Also note that the XML 1.0 specification contains the specification of the data format and of a schema language for the format itself (DTD). Without the definition of DTD, XML could be much much simpler.
I second Norman Walsh's proposal for XML 2.0: Just drop the <!DOCTYPE> declaration [1]. XML is pretty good as it is for its intended scope (marking up text), dropping the DOCTYPE/DTD would remove the main source of complexity and insecurity.
[1] http://www.tbray.org/ongoing/When/200x/2005/12/15/Drop-the-D...
One of the main problems isn't just encoding XML correctly, but the additive mistakes that arise when information is copied and reused, where along the way some part of the chain does a mistake:
- Information scraped from a web page that was in ISO-8859-1
- Stored in a database that is Windows-1252
- Then emitted through an API in UTF-8 by someone who writes strings by ("<tag>" + string concatenatation + "</tag>")
- Then stored in a new database as UTF-8 but not sanity-checked (ie., MySQL instead of Postgres)
- Then emitted as an XML feed
...etc. Along the way someone forgets to encode the "&" and the data contains random spatterings of ISO-8895-1 characters, and you're screwed.
Most parsers I have encountered aren't lenient by default, and will barf on non-conformant input. So now the last link in the chain needs to sanitize and normalize, which is a pain.
XML and JSON are different data formats with different properties and different uses.
Please, don't blame one and praise the other, just use what's appropriate. It's somehow like with data structures - say, one won't generally use a graph when he actually needs a set, right?
Trying to stash data into a semantically inappropriate format leads to kludges, and I'd say some JSON-based formats (for example, HAL-JSON) feel like so. Obviously, it's the same (or, possibly, even worse) for XMLish abominations like SOAP. Neither XML nor JSON are silver bullets.
My point is, while sure, XML has its issues and arcane features, it's not universally terrible. Wonder if there's some standardized "XML Basic Profile" that's a as minimal as possible yet still functional and expressive subset of XML for the most typical use cases, huh. Somehow in a same manner, XML was "extracted" from SGML.
The problem discussed are that XML is somewhat complicated to parse correctly. If you only support a subset of XML then it is easy to parse. The problem is that I might not know what subset you are using. When I send you advanced XML (since you said you support XML) something might crash.
There is probably a need for a simpler subset of XML with its own name (like XML 2.0 or XML-WS or Mini-XML). Personally I would like to skip the requirement for a root element. Since json is a bit simpler it has less of these problems. Of course it has other problems but that is another thing.
Why the nasty words for SOAP/XML? I mean, it can be kind of unpleasant to work with, but it holds some major advantages over popular alternatives for building and consuming non-trivial web APIs. WSDL as a mechanism to describe serialization style, operations, endpoints, data types and enums, security bindings, etc., plus all the tooling it makes possible are quite powerful.
> Wonder if there's some standardized "XML Basic Profile" that's a as minimal as possible
If you ignore Schema (and all the WS-* stuff that requires them), the rest is as simple as it comes, even if you include DTDs. Which is why XML is used in a number of roles and people at one point thought it was the best invention since sliced bread.
XML is [...]* designed for editing text documents.*
Was this ever a stated design goal? SGML, sure, probably; but I've never seen any evidence that XML had "document markup" as its sole intended application.
I'm sure it's up for interpretation, but it's a reasonably defensible position. Here's what the XML 1.0 Spec has to say:
Abstract
The Extensible Markup Language (XML) is a subset of SGML
that is completely described in this document. Its goal is
to enable generic SGML to be served, received, and
processed on the Web in the way that is now possible with
HTML. XML has been designed for ease of implementation and
for interoperability with both SGML and HTML.
...
Extensible Markup Language, abbreviated XML, describes a
class of data objects called XML documents and partially
describes the behavior of computer programs which process
them. XML is an application profile or restricted form of
SGML, the Standard Generalized Markup Language [ISO 8879].
By construction, XML documents are conforming SGML documents.
XML documents are made up of storage units called entities,
which contain either parsed or unparsed data. Parsed data
is made up of characters, some of which form character
data, and some of which form markup. Markup encodes a
description of the document's storage layout and logical
structure. XML provides a mechanism to impose constraints
on the storage layout and logical structure.
...
...
The design goals for XML are:
XML shall be straightforwardly usable over the Internet.
XML shall support a wide variety of applications.
XML shall be compatible with SGML.
It shall be easy to write programs which process XML documents.
The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
XML documents should be human-legible and reasonably clear.
The XML design should be prepared quickly.
The design of XML shall be formal and concise.
XML documents shall be easy to create.
Terseness in XML markup is of minimal importance.
> Fortunately we have JSON now.
Of course, we had s-expressions long ago.
But I agree about XML.
> Fortunately we have JSON now.
Even JSON is really a sin. Using simple binary data formats like protocol buffers makes so much more sense.
The fact that some people don't properly configure their parsers isn't an argument against the format.
"Fortunately we have JSON now."
Which doesn't support big ints. JSON isn't a silver bullet.
I've been following posts about this tool for a few weeks and it is really remarkable how many interesting results are already popping out already. In particular since static analyzers have been around for years and years.
I'm assuming afl-fuzz is particularly CPU-bound, and it would be interesting to see some numbers about how many CPU years are being dedicated to it at the moment - and if we would see even more interesting stuff if a larger compute cluster was made available.
It's also super scary how "effortlessly" these bugs appear to be uncovered, even in "well-aged" software like "strings".
It would be pretty cool to have a public cluster that anyone can submit jobs to that are prioritized based on amount of donated CPU cycles. Instead of "Seti at home" it would be "fuzz at home".
Recently I find it harder and harder to believe that lcamtuf is just one person.
He just started running afl-fuzz few years ago and redirects fitting outputs as blog posts.
No kidding. Security work aside, he finds time to take up time-intensive hobbies like CNC milling for robot parts, and has the time to write up comprehensive documents about the hobby?! (http://lcamtuf.coredump.cx/gcnc/)
Maybe he doesn't sleep.
Just in case you're serious, he's been doing security for ages. As well as other interesting things - check out http://lcamtuf.coredump.cx
Heads-up to the "comment without reading the article" crowd: the title is not bemoaning a lack of handling for CDATA in existing parsers. It's discussing an interesting behavior of the AFL fuzzer when used with formats that require fixed strings in particular places...
Related: NOBODY EXPECTS THE SPANISH INQUISITION, either. :)
This is completely tangential, but I'm waiting for someone to create a breakfast cereal called Funroll Loops. You know, for the kids.
How long till afl-fuzz reaches consciousness?
About 13 years, if all goes as planned. Then another 5 after that until we are all running afl-fuzz.
Wow, what an enjoyable read. I recommend the story about randomly generating JPG files too.
This thread reminded me of a draft post I've been sitting on for a while, related to ENTITY tags in XML and XXE exploits.
Basically, it's really easy to leave default XML parsing settings (for things like consuming RSS feeds) and accidentally open yourself up to reading files off the filesystem.
I did a full write-up and POC here: http://mikeknoop.com/lxml-xxe-exploit
I'm actually not so surprised, given what the fuzzer does - mutating input to make forward progress in the code. Incremental string comparisons definitely fall under this category since they have a very straightforward definition of "forward progress"; either the byte is correct and we can enter a previously unvisited state, or it's incorrect and execution flows down the unsuccessful path. It's somewhat like the infinite monkey theorem, except the random stream is being filtered such that only a correct subsequence is needed to advance.
On the other hand, I'd be astonished if it managed to fuzz its way through a hash-based comparison (especially one involving crypto like SHA1 or MD5.)
It's kind of like breaking a password if you only have to guess 1 letter at a time until you get it right. Reminds me of the Weasel program: https://en.wikipedia.org/wiki/Weasel_program
It's just the simplest possible demonstration of evolution, where characters of a string are randomly changed, and kept if more of the characters match. In a short amount of time you get Shakespeare quotes.
Obviously hashes are designed to be difficult to break. Although I've never heard of anyone trying a method like this before. I've heard of people using things like SAT solvers to try to reason backwards what the solution should be. But this is the reverse, it's trying random solutions and propagating forward to see how far they get.
I doubt it would work, I'm just curious to know if this has been tried before and how well it does.
Yeah, hashes or even CRC codes would be non-starters... Unless the hash or cdc was stored in the input being fuzzed, then it's just a matter of iterating over the hash byte by byte.
Constant-time compares however would probably stump the fuzzer.
It can't. If you download the package you'll see it includes an example of patching PNG, as otherwise the CRC as the end of each block prevents afl from doing much at all.
But of course no one uses either when there's Atom/GitHub's favorite: CSON. https://github.com/bevry/cson
Tell the people that created the webservice I have to consume this!
I didn't expect a kind of Spanish Inquisition...
Maybe C based XML parsers don't, but JVM and .NET based XML parsers don't have any issues with CDATA sections.
Time to upgrade to more modern tools?
The reasons why we are still relying a lot on software written in low-level languages have been discussed to death, and are quite orthogonal to the insight in the article, which is that seemingly lo-tech techniques can discover much about an opaque, potentially vulnerable piece of software. And even some seemingly insurmountable difficulties (“the algorithm wouldn't be able to get past atomic, large-search-space checks such as …”) may simply, with a bit of luck, fail to materialise.
Still, quoting from a sentence a few lines down in the article:
“this particular example is often used as a benchmark - and often the most significant accomplishment - for multiple remarkably complex static analysis or symbolic execution frameworks”
The author is thinking of backwards-propagation static analysis or symbolic execution frameworks, for which is it indeed a feat to reverse-engineer the condition that leads to exploring the possibility that there is a “CDATA” in the input. Forwards-propagation static analysis needs no special trick to assume that the complex condition must be taken some of the times and to visit the statements in that part of the code. The drawback of static analysis (especially with respect to fuzzing) is then with the false positives that can result from the fact that a condition was partially, or not at all, understood.
It's not much relevant to the article as the author doesn't imply CDATA is poorly supported (and that's not the topic at hand) but CDATA sections are very common in RSS files, as a way to shoehorn text of any type into various elements, so I'd be surprised if any well used parser lacked support.. it's even more of a requirement than namespace support IMHO.
Have you actually read this post?
Did you read the article?
you didnt even read the article did you
The article... did you read it?
I am not sure but what is the actual harm of it?