11 ms·
Nobody expects CDATA sections in XML
- pjmlp 12y agoMaybe 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?
- xendo 12y agoHave you actually read this post?
- comboy 12y agoDid you read the article?
- petercooper 12y agoIt'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.
- pascal_cuoq 12y agoThe 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.
- benwilber0 12y agoyou didnt even read the article did you
- cmdrfred 12y agoThe article... did you read it?
- xendo 12y agoRecently I find it harder and harder to believe that lcamtuf is just one person.
- comboy 12y agoHe just started running afl-fuzz few years ago and redirects fitting outputs as blog posts.
- schoen 12y agoRunning it against an AI simulation of a human programmer, pattern-matching for the output "Wow that's awesome", no doubt.
- deleted 12y ago[deleted]
- viraptor 12y agoJust in case you're serious, he's been doing security for ages. As well as other interesting things - check out http://lcamtuf.coredump.cx http://lcamtuf.coredump.cx
- tootie 12y agoHe does all that and has two young kids. There goes my excuse.
- scott_karana 12y agoNo 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/ http://lcamtuf.coredump.cx/gcnc/) Maybe he doesn't sleep.
- seba_dos1 12y agoHow long till afl-fuzz reaches consciousness?
- jschwartzi 12y agoAbout 13 years, if all goes as planned. Then another 5 after that until we are all running afl-fuzz.
- 0x0 12y agoI'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".
- hueving 12y agoIt 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".
- dalke 12y agoI don't think that would be that efficient of a use of computing resources. Each instance explores the same instruction space. It keeps track of where it's explored, and uses various techniques to explore different parts of space. It's very likely that multiple instances, if run in parallel and with no data sharing, will explore a lot of the same space. Also, making a public cluster would be a security challenge. It runs arbitrary C/C++ code, and can trigger code paths that the developers didn't even realize. How would your box stand up to multiple grabs of 4GB of memory?
- hueving 12y agoDon't have instances explore the same programs starting from the same state. Have state reported back in intervals so other workers can be scheduled to resume the work if that one goes down. Security would be an issue. A VM would probably be a hard requirement. That can bound the memory usage, hardware calls, etc.
- dalke 12y ago
- NelsonMinar 12y agoThe 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.
- TimWolla 12y agoYou are allowed to chain CDATA-tags: ]]]]><![CDATA[> > CDATA sections may occur anywhere character data may occur; (http://www.w3.org/TR/REC-xml/#sec-cdata-sect http://www.w3.org/TR/REC-xml/#sec-cdata-sect)
- TheLoneWolfling 12y agoIs it just me who sees this as a very bad idea?
- dietrichepp 12y agoIt's really handy for some use cases. For example, if you are writing documentation involving XML, you might put your example XML in CDATA sections. The way CDATA works is also far simpler than XML's predecessor, SGML. I'd say it's a good feature. It sucks that there are some shoddy libraries out there, but oh well.
- deleted 12y ago[deleted]
- TheLoneWolfling 12y agoI mean chaining CDATA tags as a way to escape CDATA tags as a bad idea. It'll break anything that doesn't expect it - in particular I can see anything that does round-trips from/to XML breaking.
- bostonpete 12y agoI didn't expect a kind of Spanish Inquisition...
- al2o3cr 12y agoHeads-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. :)
- serve_yay 12y agoWow, what an enjoyable read. I recommend the story about randomly generating JPG files too.
- adnam 12y agoThis is completely tangential, but I'm waiting for someone to create a breakfast cereal called Funroll Loops. You know, for the kids.
- userbinator 12y agoI'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.)
- acveilleux 12y agoYeah, 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.
- Houshalter 12y agoIt'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 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.
- kalleboo 12y agoIn a way it reminds me of timing attacks only with a lot stronger signal.
- 12y ago
- nickbauman 12y agoTell the people that created the webservice I have to consume this!
- mikeknoop 12y agoThis 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 http://mikeknoop.com/lxml-xxe-exploit
- brabbit 12y agoI am not sure but what is the actual harm of it?
- backspaces 12y agoBut of course no one uses either when there's Atom/GitHub's favorite: CSON. https://github.com/bevry/cson https://github.com/bevry/cson