“WTF is NTFS Fuzzing?” Matasano Clarifies.

Thomas Ptacek | October 27th, 2006 | Filed Under: Development, Uncategorized

A comment from last night:

I have no freakin’ idea what you are talking about […] Can you write a post explaining NTFS fuzzing in little better […]? What do you mean by a malicious NTFS image?

Sure, I’ll take a shot. Thanks for asking. Skip to whatever part answers questions for you.

1.

Fuzzing is slang for fault injection via random inputs. The goal is to find bugs in software without reading code or designing detailed test cases. You can fuzz test anything that takes an input, including:

• File formats, by generating random (or randomly corrupted) files; for instance, attacking a browser by feeding it corrupt image files.

• Protocols, by generating randomly corrupted messages; for instance, attacking a web server by feeding it corrupt TLS records.

• API’s, by generating random (or randomly corrupted) function call arguments; for instance, attacking the OS X kernel by generating random system calls.

2.

Filesystem fuzzers fuzz filesystems. Particularly on Unix systems, filesystems are themselves just big interesting files; you can get to a “live” filesystem by reading and writing “/dev/rdisk*”, and you can create and modify test filesystems by loopback-mounting files and disk images.

An NTFS filesystem fuzzer is going to semi-randomly corrupt the filesystem metadata (the file tables, attributes, indices, etc) of an NTFS image. The goal is that when the image is loaded into a target system (say, because it resides on a USB thumb drive you just plugged in to the target), the kernel of the target system is going to read the corrupt filesystem, trigger a bug, and fail.

Filesystems are an interesting target for a couple reasons:

1. They’re complicated. Filesystems aren’t the easiest pieces of system code to write. Complicated code is buggy code and buggy code is insecure code.

2. They’re in the kernel. Ring zero exploits are terribly powerful; for example, if you can access privileged instructions on AMD and modern Intel, you can virtualize the running operating system under a hypervisor (think VMWare) and control the entire universe as the kernel sees it. (There are even worse things you can do than that with a ring zero exploit on some platforms with flash-programmable firmware).

3. They’re not well-tested, in part because of reasons 1 and 2 (making them a bit intimidating) and partly because people don’t see them as a viable attack vector, bringing us to:

4. They’re a deceptively viable attack vector on modern computers. You don’t need access to the PCI bus or root privs to force an OS to read a corrupted filesystem:

• Your OS will read a variety of filesystems off any USB drive you plug in

• SAN storage feeds blocks, not files, over the network, meaning the filesystem metadata is in transit over the network and exposed to attack

• Macs will read filesystems out of images downloaded off the Internet. This was not a great design decision.

3.

Consider a hypothetical NTFS vulnerability. Say, if the NTFS file record at the offset where the MFT lives has a “File Name” record that starts with “$MFT” but continues on with at least 2048 bytes, it overflows a kernel pool allocated buffer and corrupts the allocator. This is not a real vulnerability.

(The MFT is the Master File Table; think of it as the “root file record” in NTFS, which isn’t accurate but close enough).

In this parallel universe in which filesystems are vulnerable to attacks, and particularly the one I just mentioned, a “malicious NTFS image” is one with a pathological $MFT that corrupts the kernel allocator so that the next free() call the kernel does overwrites the stack and transfers code into kernel shellcode also resident in the NTFS image.

That’s what we’re looking for with a filesystem fuzzer.

4.

Again, the advantage of fuzzing is that you don’t have to think too much to create pathological test cases that find real bugs. Because of this, fuzzing tools exist on a spectrum of “format-awareness”. The more “format-aware” your tools are, the more well-formed your test messages are going to be, which has advantages and disadvantages:

• On the plus side, “better-formed” messages can do deeper testing. If the code you’re testing validates message length fields, or checksums, blindly splattering random bytes over messages will cause messages that could have scored a hit to be rejected.

• On the minus side, the big advantage of fuzzing is that by letting the computer do the work instead of your brain, you score hits you wouldn’t have thought of swinging for.

The spectrum looks like this:

• At the simplest end, you have tools like “mangle.c”, which “fsfuzzer” uses; “mangle” doesn’t know anything about the file formats it’s attacking (except that high-ASCII bytes are “more important”) —- it just sprays random bytes.

• In the middle of the spectrum you have framework tools like “spike”, which aren’t aware of any specific protocols or file formats, but provide functions for generating well-formed messages. The big problem most of these things solve is getting length fields right, so you can stuff 10 megs of crap into a message that is supposed to be 40 bytes long and not have to manually compute a 32 bit little endian word-counted length field.

• At the sophisticated end of the spectrum you have things like PROTOS, which are fully aware of the protocols they target and measure themselves by how many individual, protocol-specific test cases they have.

5.

The way I’m using the word “fuzzing”, which is incorrect, is “any security testing you do by generating pathological inputs conducted without understanding the code in the target”. I think my dirty secret is, I don’t “fuzz” anything; I just try to understand 10% of a protocol, API, or file format and then generate lots of thoughtless test cases.

If you just want to find crashers in your OS, download fsfuzzer and mount up filesystems it creates for you. You won’t need to think, and you will probably find bugs. Fsfuzzer is the simplest thing that can possibly works, and that’s clever, and I salute it.