Unknown – Noise

Last call for RSS subscribers: please migrate off this feed

Unknown — Fri, 12 Jul 2024 19:52:00 +0000

This is just a final call for any remaining RSS subscribers: if you're still subscribed to this publication, it will not be getting any future updates.Instead, please subscribe by email or via RSS to https://lcamtuf.substack.com/. It's a project I...

Officially retiring this…

Unknown — Fri, 21 Oct 2022 23:15:00 +0000

Thank you for stopping by.After more than a decade of posting infosec commentary on this blog, I decided to pull the plug. I still publish quite a bit, but I'm less and less inclined to use blogspot.com. For one, the platform just doesn't seem to ...

Practical Doomsday

Unknown — Sat, 07 Aug 2021 01:51:00 +0000

Practical Doomsday is an enjoyable, data-packed romp through the world of rational emergency preparedness. It cuts through the noise of 24-hour news to help you zero in on what actually matters: building a diversified rainy-day fund, staying safe...

Getting product security engineering right

Unknown — Sun, 25 Feb 2018 03:36:00 +0000

Product security is an interesting animal: it is a uniquely cross-disciplinary endeavor that spans policy, consulting, process automation, in-depth software engineering, and cutting-edge vulnerability research. And in contrast to many other specializa...

AFL experiments, or please eat your brötli

Unknown — Sat, 22 Apr 2017 22:48:00 +0000

When messing around with AFL, you sometimes stumble upon something unexpected or amusing. Say, having the fuzzer spontaneously synthesize JPEG files, come up with non-trivial XML syntax, or discover SQL semantics. It is also fun to challenge yourse...

CSS mix-blend-mode is bad for your browsing history

Unknown — Thu, 04 Aug 2016 16:23:00 +0000

Up until mid-2010, any rogue website could get a good sense of your browsing habits by specifying a distinctive :visited CSS pseudo-class for any links on the page, rendering thousands of interesting URLs off-screen, and then calling the getComputedSt...

Clearing up some misconceptions around the "ImageTragick" bug

Unknown — Wed, 11 May 2016 17:15:00 +0000

The recent, highly publicized "ImageTragick" vulnerability had countless web developers scrambling to fix a remote code execution vector in ImageMagick - a popular bitmap manipulation tool commonly used to resize, transcode, or annotate user-supplied ...

Automatically inferring file syntax with afl-analyze

Unknown — Tue, 09 Feb 2016 20:45:00 +0000

The nice thing about the control flow instrumentation used by American Fuzzy Lop is that it allows you to do much more than just, well, fuzzing stuff. For example, the suite has long shipped with a standalone tool called afl-tmin, capable of automatic...

New in AFL: persistent mode

Unknown — Thu, 11 Jun 2015 22:15:00 +0000

Although American Fuzzy Lop comes with a couple of nifty performance optimizations, it still relies on a fairly resource-intensive routine that is common to most general-purpose fuzzers: it continually creates new processes, feeds them a single test c...

Finding bugs in SQLite, the easy way

Unknown — Tue, 14 Apr 2015 18:32:00 +0000

SQLite is probably the most popular embedded database in use today; it is also known for being exceptionally well-tested and robust. In contrast to traditional SQL solutions, it does not rely on the usual network-based client-server architecture and do...

On journeys

Unknown — Mon, 30 Mar 2015 09:42:00 +0000

- 1 - Poland is an ancient country whose history is deeply intertwined with that of the western civilization. In its glory days, the Polish-Lithuanian Commonwealth sprawled across vast expanses of land in central Europe, from Black Sea to Baltic Se...

Another round of image bugs: PNG and JPEG XR

Unknown — Wed, 11 Mar 2015 07:38:00 +0000

Today's release of MS15-024 and MS15-029 addresses two more image-related memory disclosure vulnerabilities in Internet Explorer - this time, affecting the little-known JPEG XR format supported by this browser, plus the far more familiar PNG. Similarl...

Bi-level TIFFs and the tale of the unexpectedly early patch

Unknown — Tue, 10 Feb 2015 18:55:00 +0000

Today's release of MS15-016 (CVE-2015-0061) fixes another of the series of browser memory disclosure bugs found with afl-fuzz - this time, related to the handling of bi-level (1-bpp) TIFFs in Internet Explorer (yup, MSIE displays TIFFs!). You can check...

afl-fuzz: making up grammar with a dictionary in hand

Unknown — Sat, 10 Jan 2015 03:22:00 +0000

One of the most significant limitations of afl-fuzz is that its mutation engine is syntax-blind and optimized for compact data formats, such as binary files (e.g., archives, multimedia) or terse human-readable languages (RTF, shell scripts). Any genera...

afl-fuzz: nobody expects CDATA sections in XML

Unknown — Sun, 30 Nov 2014 21:39:00 +0000

I made a very explicit, pragmatic design decision with afl-fuzz: for performance and reliability reasons, I did not want to get into static analysis or symbolic execution to understand what the program is actually doing with the data we are feeding to it. The basic algorithm for the fuzzer can be just summed up as randomly mutating the input files, and gently nudging the process toward new state transitions discovered in the targeted binary. That discovery part is done with the help of lightweight and extremely simple instrumentation injected by the compiler.

I had a working theory that this would make the fuzzer a bit smarter than a potato, but I wasn't expecting any fireworks. So, when the algorithm managed to not only find some useful real-world bugs, but to successfully synthesize a JPEG file out of nothing, I was genuinely surprised by the outcome.

Of course, while it was an interesting result, it wasn't an impossible one. In the end, the fuzzer simply managed to wiggle its way through a long and winding sequence of conditionals that operated on individual bytes, making them well-suited for the guided brute-force approach. What seemed perfectly clear, though, is that the algorithm wouldn't be able to get past "atomic", large-search-space checks such as:

if (strcmp(header.magic_password, "h4ck3d by p1gZ")) goto terminate_now;

...or:

if (header.magic_value == 0x12345678) goto terminate_now;

This constraint made the tool less useful for properly exploring extremely verbose, human-readable formats such as HTML or JavaScript.

Some doubts started to set in when afl-fuzz effortlessly pulled out four-byte magic values and synthesized ELF files when testing programs such as objdump or file. As I later found out, this particular example is often used as a benchmark for complex static analysis or symbolic execution frameworks. But still, guessing four bytes could have been just a happy accident. With fast targets, the fuzzer can pull off billions of execs per day on a single machine, so it could have been dumb luck.

(As an aside: to deal with strings, I had this very speculative idea of special-casing memory comparison functions such as strcmp() and memcmp() by replacing them with non-optimized versions that can be instrumented easily. I have one simple demo of that principle bundled with the fuzzer in experimental/instrumented_cmp/, but I never got around to actually implementing it in the fuzzer itself.)

Anyway, nothing quite prepared me for what the recent versions were capable of doing with libxml2. I seeded the session with:

...and simply used that as the input for a vanilla copy of xmllint. I was merely hoping to stress-test the very basic aspects of the parser, without getting into any higher-order features of the language. Yet, after two days on a single machine, I found this buried in test case #4641 in the output directory:

...<![<CDATA[C%Ada b="c":]]]>...

What the heck?!

As most of you probably know, CDATA is a special, differently parsed section within XML, separated from everything else by fairly complex syntax - a nine-character sequence of bytes that can't be realistically discovered by just randomly flipping bits.

The finding is actually not magic; there are two possible explanations:

As a recent "well, it's cheap, so let's see what happens" optimization, AFL automatically sets -O3 -funroll-loops when calling the compiler for instrumented binaries, and some of the shorter fixed-string comparisons will be actually just expanded inline. For example, if the stars align just right, strcmp(buf, "foo") may be unrolled to:
```
cmpb   $0x66,0x200c32(%rip)        # 'f'
jne    4004b6 
cmpb   $0x6f,0x200c2a(%rip)        # 'o'
jne    4004b6 
cmpb   $0x6f,0x200c22(%rip)        # 'o'
jne    4004b6 
cmpb   $0x0,0x200c1a(%rip)         # NUL
jne    4004b6 
```
...which, by the virtue of having a series of explicit and distinct branch points, can be readily instrumented on a per-character basis by afl-fuzz.
If that fails, it just so happens that some of the string comparisons in libxml2 in parser.c are done using a bunch of macros that will compile to similarly-structured code (as spotted by Ben Hawkes). This is presumably done so that the compiler can optimize this into a tree-style parser - whereas a linear sequence of strcmp() calls would lead to repeated and unnecessary comparisons of the already-examined chars.
(Although done by hand in this particular case, the pattern is fairly common for automatically generated parsers of all sorts.)

The progression of test cases seems to support both of these possibilities:


<![

<![C b="c">

<![CDb m="c">

<![CDAĹĹ@

<![CDAT<!

...

I find this result a bit spooky because it's an example of the fuzzer defiantly and secretly working around one of its intentional and explicit design limitations - and definitely not something I was aiming for =)

Of course, treat this first and foremost as a novelty; there are many other circumstances where similar types of highly verbose text-based syntax would not be discoverable to afl-fuzz - or where, even if the syntax could be discovered through some special-cased shims, it would be a waste of CPU time to do it with afl-fuzz, rather than a simple syntax-aware, template-based tool.

(Coming up with an API to make template-based generators pluggable into AFL may be a good plan.)

By the way, here are some other gems from the randomly generated test cases:

<!DOCTY.

<?xml version="2.666666666666666666667666666">

<?xml standalone?>

afl-fuzz: crash exploration mode

Unknown — Tue, 25 Nov 2014 06:00:00 +0000

One of the most labor-intensive portions of any fuzzing project is the work needed to determine if a particular crash poses a security risk. A small minority of all fault conditions will have obvious implications; for example, attempts to write or jump...

Pulling JPEGs out of thin air

Unknown — Fri, 07 Nov 2014 23:03:00 +0000

This is an interesting demonstration of the capabilities of afl; I was actually pretty surprised that it worked!$ mkdir in_dir $ echo 'hello' >in_dir/hello $ ./afl-fuzz -i in_dir -o out_dir ./jpeg-9a/djpegIn essence, I created a text file conta...

PSA: don’t run ‘strings’ on untrusted files (CVE-2014-8485)

Unknown — Sat, 25 Oct 2014 04:49:00 +0000

Many shell users, and certainly most of the people working in computer forensics or other fields of information security, have a habit of running /usr/bin/strings on binary files originating from the Internet. Their understanding is that the tool simpl...

Two more browser memory disclosure bugs (CVE-2014-1580 and #19611cz)

Unknown — Tue, 14 Oct 2014 19:10:00 +0000

To add several more trophies to afl's pile of image parsing memory disclosure vulnerabilities: MSFA 2014-78 (CVE-2014-1580) fixes another case of uninitialized memory disclosure in Firefox - this time, when rendering truncated GIF images on <c...

Fuzzing random programs without execve()

Unknown — Tue, 14 Oct 2014 09:02:00 +0000

The most common way to fuzz data parsing libraries is to find a simple binary that exercises the interesting functionality, and then simply keep executing it over and over again - of course, with slightly different, randomly mutated inputs in each run....