every once in a while (last time a few months ago) someone emails one of the mailing lists about searching for an example binary, mostly for:

- reverse engineering for vulnerabilities, as a study tool.
- testing fuzzers

some of these exist, but i asked my employer, beyond security, to release our test application, specific for testing fuzzing (built for the bestorm fuzzer). they agreed to release the http version, following their agreement to release our ani xml specification.

the gui allows you to choose what port your want to run it on, as well as which vulnerabilities should be “active”.

it is called simple web server or sws, and has the following vulnerabilities:

1. off-by-one in content-length (integer overflow/malloc issue)
2. overflow in user-agent
3. overflow in method
4. overflow in uri
5. overflow in host
6. overflow in version
7. overflow in complete packet
8. off by one in receive function (linefeed/carriage return issue)
9. overflow in authorization type
10. overflow in base64 decoded
11. overflow in username of authorization
12. overflow in password of authorization
13. overflow in body
14. cross site scripting

it can be found on beyond security’s website, here:
http://www.beyondsecurity.com/sws_overview.html

gadi evron,
ge@beyondsecurity.com.

i was giving a lecture at nps yesterday, and while i was unlocking my laptop (xp), suddently, before unlocked, a file open window pops up. i could browse, and more importantly, open files. the first choice of the system was .hlp.

can someone say pwnage? anyone up to doing some monkey fuzzing on that interface?

gadi evron,
ge@beyondsecurity.com.

Window Snyder, the head of security strategy at Mozilla Corporation wrote this week about the Opera’s way to use Mozilla’s fuzzer for JavaScript. Mrs. Snyder is pointing to the post of Claudio Santambrogio from Opera Software:

While running the tool, we found four crashers – one of which might have some security implications.

When we are reading news like this from Microsoft and Apple?

Recently I have seen a lecture by John of Microsoft about their FuzzGuru framework, apparently their approach to fuzzing is through tight integration with code coverage tools, in similar fashion a recently published paper by Microsoft Research, Automated Whitebox Fuzz Testing, shows that this is in fact Microsoft’s approach to fuzzing.
Though this approach seems to provide good results to Microsoft, I am not sure it is a good approach to the majority of people that develop software, as in the security testing phase there is usually little chance that the source code will be available for code coverage testing.

Some would think that binary form code coverage might work as well, I disagree as generic code coverage will make the fuzzer confused as it would not concentrate on the parser part of the program which our fuzzer needs to test.

We’ve been toying with the idea of implementing both source code coverage and binary code coverage in beSTORM but I’m not sure I’m convinced yet that the code coverage approach is beneficial.

after being challenged by Sunshine, we decided to make the bestorm .ani file fuzzing module description available publicly.

this module is interesting because microsoft’s fuzzing team, using a template-based fuzzing module, missed during their testing a vulnerability that turned out to be a zero-day. we built it by simply feeding a few sample files into bestorm and using its autolearn feature to produce a file fuzzing module. the module we produced does catch the 0-day but we welcome any feedback as to how good or bad this module actually is.

the fuzzing module description is available here.

kowsik guruswami sent a message today to dd about using code coverage to help build better fuzzers.

i have many thoughts on this subject. here is my reply email:

on mon, 26 mar 2007, kowsik wrote:
> we just released rcov-0.1, an interactive/incremental code coverage
> tool to assist in building effective fuzzers.
>
> quick summary:
>
> – it’s a webrick browser-based application (ruby)
> – uses gcov’s notes/data files to get at blocks and function summaries
> – interactively/incrementally shows the coverage information while fuzzing
> – uses ctags to cross reference functions/prototypes/definitions/macros

hi kowsik, thanks for this.

i have a few notes though, as i believe this can be taken much further (at least my studies so far show that).

we have three levels or layers (depends on approach):
1. building better fuzzers (which you cover).
2. helping the fuzzing process, fuzzing better.
3. making the process of finding the actual vulnerability once an indication is found (a successful test case, or as they say in qa, a passing one) easier.

several folks in the past few months have said that fuzzing isn’t new and has been done for years – that much is true.

some folks also said that fuzzing is as simple as it gets and has no where left to evolve. that is indeed very much false.

code coverage, static analysis, run-time analysis.. etc. all have a place in the future of fuzzing.
i see fuzzers development in coming years as changing the term “dumb fuzzing” to mean today’s protocol-based smart fuzzing, and “smart fuzzing” being about what interactive changes are happening as you fuzz.

the most that we see today (in most cases) is the engine running undisturbed, while the monitor (if such even exists) being a simple debugger.

evolving host and network monitoring to use profiling technologies, map functions and paths, watch for memory issues, etc. is fast coming.

today, changing the action of a fuzzer as it is running is difficult (there is no real driver, just an engine). a simple example for this evolution could be watching for cpu uage. if the cpu usage spikes it could mean:
1. we are sending too many requests per second – we should slow down the engine.
2. (if for the thread itself) we are on to something, we should explore this attack (likely 10000 “attacks” we went through) or adjust to a different fuzzing engine to explore that particular section of the program (as we mapped it – code coverage again).

the two don’t easily work together, not to mention even stopping a fuzzer, rewinding it or god forbid running a different one at the same time (on the same instance anyway).

which brings us to distributed fuzzing… but that’s a whole different subject yet again.

fuzzing has a long way to go, and we didn’t even really start to explore full intergration with static analysis tools (other than with results).

we had a discussion on the fuzzing mailing list recently about genetic fuzzing, but i dam not really a math geek. jared can explain that one better… and so on.

all that before we explore uses for fuzzing outside of the development cycle (mostly security qa) and vulnerability research, which is with client-side testing. perhaps fuzzers will help us force the hand of software vendors to develop more robust and secure code.

working for a fuzzing vendor i am only too familiar with the turing halting problem and seeking reality in the midst of eternal runs, but the most interesting thing i found in the past few months (which wasn’t technical) is the clash of cultures between qa engineers and security professionals. it will be very interesting to see where we end up.

thanks,

sunshine.

gadi evron,
ge@beyondsecurity.com.

catchconv: symbolic execution and run-time type inference for integer conversion errors

this is an interesting paper, and it seems like the fuzzing mailing list helped out a tad bit.

abstract. we propose an approach that combines symbolic execution and run-time type inference from a sample program run to generate test cases, and we apply our approach to signed/unsigned conversion errors in programs. a signed/unsigned conversion error occurs when a program makes control how decisions about a value based on treating it as a signed integer, but then later converts the value to an unsigned integer in a way that breaks the program’s implicit assumptions. our tool follows the approach of larson and austin in using an example input to pick a program path for analysis [21], and we use symbolic execution to attempt synthesis of a program input exhibiting an error [19, 17, 8, 34]. we describe a proof of concept implementation that uses the valgrind binary analysis framework and the stp decision procedure, and we report on preliminary experiences. our implementation is available at http://www.sf.net/projects/catchconv. keywords: software security, symbolic execution, test generation, decision procedure, dynamic binary analysis

gadi evron,
ge@beyondsecurity.com.

other presentations i enjoyed, which i just noticed online:
pdf george danezis, introducing traffic analysis

wmv georg wicherski, automated botnet detection and mitigation

wmv gadi evron, fuzzing in the corporate world (yes, mine)

wmv ilja van sprundel, unusual bugs

pdf ilja van sprundel, unusual bugs

wmv michael steil, inside vmware

more here [mirror]. all mirrors, etc. can be found here. i hope everything becomes available soon.

gadi evron,
ge@beyondsecurity.com.

Seems like blackbox testing tools (fuzzers) gain more ground, but not in the way I would expect.

I expected software/networking vendors to be buying commercial fuzzers to check their products for security holes (or using open source fuzzing tools as part of the development cycle). Surprisingly, most companies I know that have implemented fuzzers are not the ones writing code, but those who rely on other people’s products – telcos, cell phone providers, financial institutions, and equipment suppliers.

Apparently, some of these companies check 3^rd party products for security holes before they install them in their network.

While this ‘certification’ attitude is expected from financial institutions, it’s pleasantly surprising to see it from equipment suppliers, for example. One large telco went as far as informing several networking equipment vendors that any new version of their networking products will undergo extensive security tests before it is purchased. Since the tests are done with a commercial fuzzing product, the networking vendor has a chance to buy a similar product and do its testing already in the development lab – saving the shame of having the customer find its security holes for him.

Perhaps I shouldn’t be too surprised – there were many instances of organizations running nessus on their networking equipment and sending the vendor a ‘report card’ with all the known vulnerabilities present in the product. But doing a quick nessus run is way different from implementing security testing as part of the acceptance process. At least one company picked up on this upcoming trend – BreakingPoint‘s business model is around companies benchmarking security products before deciding which ones to buy. Will this trend tie up with testing products for security holes before deciding which ones to buy?

Another pleasant surprise is that Microsoft, who has been behind in terms of security for many years (to a point where many people, myself included, were convinced that they “just don’t get it”), has implemented a fuzzing infrastructure that is more advanced than anything else I’ve seen. A couple of networking vendors are not too far behind, but the rest of the software development world seems to be in the security testing dark ages.

This is obviously a good step for the security world – if large customers begin to pressure product vendors to develop more secure products (rather than spend marketing dollars on branding themselves as secure), product security will have a clearer ROI and the result will be more secure products.

A cynical friend of mine told me that this is yet another proof that product vendors will not take steps to increase their product’s security unless pushed to do so by external forces. I tend to think that whatever the reasons, a net result of less security holes is good for everyone.

Since 5th December we have seen three separate, serious vulnerabilities in Microsoft Word:

[Disclosed - original reference - CVE name
Affected products and product versions]

Tue 5th Dec – MS Security Advisory #929433 – CVE-2006-5994 and FAQ
Word 2003/2002/2000, Word 2004/v. X for Mac, Works 2006/2005/2004, Word Viewer 2003

Sat 9th Dec – MSRC Blog entry 10th Dec – CVE-2006-6456
Word 2003/2002/2000, Word Viewer 2003

Tue 12th Dec – Fuzzing list posting – CVE-2006-6561
Word 2003/2002/2000, Word 2004/v. X for Mac, Word Viewer 2003, OpenOffice.org 2/1.1.3, AbiWord 2.2

Related to the third issue new submission to VirusTotal has been done. There is some better results now:

# 12.15.2006 01:04:58 (CET)

AntiVir 14th Dec: EXP/W97M.DuBug
BitDefender 15th Dec: Exploit.MSWord.Gen.2
Fortinet 14th Dec: W32/CVE20065994!exploit (the CVE of 1st issue)
Ikarus 14th Dec: Exploit.MSWord.Gen.2
McAfee 14th Dec: Exploit-MSWord.c.demo
NOD32v2 14th Dec: W97M/Exploit.1Table.NAE
Panda 15th Dec: Trj/1Table.D

Symantec is not listed, but they have released Bloodhound.Exploit.108.

the month of kernel bugs (mokb) released an advisory (mokb-11-11-2006) today on a wireless vulnerability in broadcom’s wireless driver.

zert, in cooperation with metasploit, the sans isc and indeed, securiteam, issued an advisory on the issue, explaining why it is critical, etc.:

http://isotf.org/advisories/zert-01-111106.htm

the advisory was written by h d moore, gadi evron (me) and johannes ullrich.

worth a read, this is serious.

also:
http://blog.washingtonpost.com/securityfix/2006/11/exploit_targets_widely_deploye.html

gadi evron,
ge@beyondsecurity.com.

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).

(more…)

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?
(more…)

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.

Ami.