Posted on November 11th, 2006 by Matthew Murphy
Filed under: Commentary, Full Disclosure, Fuzzing, Interviews | 8 Comments »
November has been informally designated the “Month of Kernel Bugs” in security circles. The Month of Kernel Bugs began on November 1, with the publication of a vulnerability in Apple’s AirPort drivers. SecuriTeam blogs did an interview with LMH, who hosts the Month of Kernel Bugs project (aka MoKB); the text of our interview is below (after the jump).
Posted on November 9th, 2006 by Aviram
Filed under: Commentary, Fuzzing | 1 Comment »
A while ago I tried to start a discussion on the Daily Dave mailing list using the provocative subject line “Does Fuzzing really work?”.
I was hoping to start some fruitful information exchange. After all, I know there are many people out there that are either busy developing fuzzers or busy using them (we’re doing the former), and why not share some information and see what makes sense and what doesn’t?
Well, no real discussion came out of that post (I don’t count pissing contests as a meaningful discussion), which might mean that there are less ‘fuzzing’ people out there than I thought.
Two interesting dialogs did come out of that, though – both by private email replies.
One was an intriguing discussion with Robert Fly, that heads up a security team in Microsoft that works across a number of product groups. Robert described the security testing procedures and the fuzzing technology that is used in their testing. Let me sum it up by saying it was nothing short of amazing. Those guys seem to be on top of most (if not all) of the fuzzing technology improvements, but what’s more amazing is that they have a testing procedure in place, one that’s right out of the text book. Did I mention I was impressed?
Posted on November 7th, 2006 by Ami
Filed under: Digest, Fuzzing | No Comments »
Recently, h07 published a vulnerability in Easy File Sharing FTP Server. Apparently a simple buffer overflow in the PASS command. This vulnerability is a nice example where fuzzing won’t cut it.
But the catch in the vulnerability is a comma. Only passwords starting with a comma (0x2c) can be overflowed. Why is this so important?
A fuzzer will usually take a legal FTP session, and will try to overflow interesting sections. The password field is a prime candidate, but the problem is, if you test for a simple overflow you’ll just send many ‘A’ characters or something similar. This is because fuzzers tend to look for the coin under the street-light.
Fuzzers today are sophisticated enough to look for many different types of programmer errors, but will usually look for the poster-child of each. For example, to find a format string, just send many %x. This is not done due to programmer lazyness, this is due to the sheer amount of possibilities to check. FTP is a relatively simple protocol, but with vendor extensions it has dozens of commands. Checking every command for vulnerabilities could take a long time, and with network considirations we’re talking weeks and months of continous bombardment on the target server.