Continuous Fuzzing Made Simple.

Fuzzing as a service platform that fuzzes your code continuously to find bugs and vulnerabilities before the bad guys do.

Trusted By

Intro to Fuzzit

Fuzz like the big guys

Have the fuzzing power and knowledge of big tech companies so you can focus on building a great and secure product.

fuzzit ci integrations
CF/CD

Continuous Fuzzing

Easy integration with your existing CI. Run fast regression tests on every pull-request and long fuzzing jobs in the background.

Platform

Highly Scalable

Start small and expand as necessary to cover your fuzz target.

Analysis

Crash Deduplication

Accurate de-duplication of crashes to pin-point bugs.

C, C++, Java, Golang, Rust and SWIFT

State of The Art Fuzzers

We support all latest state of the art fuzzer for C, C+, Java, Golang, Rust and Swift. Run your current libFuzzer, AFL target at scale with deep analysis.

Latest Updates From our Blog

cargo-fuzz

How to Fuzz Rust Code with Cargo-Fuzz (Continuously)

What is fuzzing? Fuzzing or fuzz testing is an automated software technique that involves providing semi-random data as input to the test program in order to uncover bugs and crashes. In this short tutorial we will discuss cargo-fuzz. Why fuzz

Read More

GolangNYC: Continuous Go Fuzzing Video + Slides

Hey, It’s Yevgeny Pats here. I’ve had great time at Golang NYC September Meetup Special thanks to the organisers (Mofi rahman) , Dmitri Shuralyov from Go Team who also gave a very interesting talk and to Plated who hosted us.

Read More

Discovery and Analysis of 2 DoS vulnerabilities in Autodesk FBX (1 unpatched)

Introduction

In this blogpost we will discuss the discovery and analysis of 2 DoS CVEs in AutoDesk FBX. AutoDesk FBX is a cross-platform closed source SDK of AutoDesk which allows vendors to transfer existing content into the FBX format. The SDK code as-far-as we currently understand is also bundled in other AutoDesk products.

Continuous Fuzzing and Fuzzing in general  is getting more attention lately as a best practice in secure development of native/unsafe languages software (but not limited to – why go fuzz ). So we went on a mission to understand if companies really employ this technique. To answer this question we utilized binary fuzzing, specifically qemu-afl as we don’t usually have the source-code of the products we want to test.

Binary fuzzers are much slower and less efficient than compiler based fuzzer like libFuzzer or other source based fuzzers go-fuzz, jsfuzz, pythonfuzz. So, if we would find quickly low-hanging fruit vulnerabilities with binary fuzzer that would indicate a sad situation about the current state of the security of the source-code/product.

Disclosure Timeline

  • July 15 – filled-in this form https://www.autodesk.com/trust/contact-us – no response
  • Reached via linkedin to an executive who transferred me to psirt@autodesk.com on July 20.
  • Acknowledged July 22
  • Aug 7 got an email the issue was remediated
  • Aug 13, another email confirming it was not actually fixed and saying it will be fixed somewhere in October.
  • Never heard back
  • Oct 22 – 90 days passed
  • Oct 25 – Public Disclosure

The bugs

Two DoS bugs were found, 1 is a memory unalignment (this one was fixed) and 1 is std::bad_alloc. Here are the backtraces:

Samples:


Fuzzing & Reproduction

Following are the instruction to set-up afl-qemu fuzzing for fbx. We run it on one sample/function and found the bug over-night (we used afl multi-process mode). You are welcome to try and run it again, I won’t be surprised it will find more bugs we just didn’t have the time as we moved towards other things.


Summary

Binary fuzzing is a neat trick when you don’t have the source but in general it’s very inefficient. Fuzzing has to be integrated into the development cycle with fast code-instrumentation fuzzers, especially if the code is written in unsafe language and it’s running with high permission on peoples computer which in turn can serve as a vector for an RCE vulnerability. Of course, this advice/opinion is not limited to desktop applications but essentially to any critical components where attackers might have access to like world facing proxies, services etc…

If you are writing in safe-languages and you want to see if you can employ fuzzing in your language check-out our previous post on why-go-fuzz

Featured Post
cargo-fuzz

How to Fuzz Rust Code with Cargo-Fuzz (Continuously)

What is fuzzing?

Fuzzing or fuzz testing is an automated software technique that involves providing semi-random data as input to the test program in order to uncover bugs and crashes. In this short tutorial we will discuss cargo-fuzz.


Why fuzz Rust code?

Rust is a safe language (mostly) and memory corruption issues are a thing of the past so we don’t need to fuzz our code, right? wrong:). Any code where stability quality and coverage are important is usually worth fuzzing. Also fuzzing can uncover logical bugs and Denial-of-service where in critical components can lead to security issues as well.

As a reference to almost infinite amount of bugs found with cargo-fuzz (only the documented one) you can look here. Also, you can check-out our previous discussion on why to fuzz go which is also a safe language.


Cargo-fuzz

cargo-fuzz is the current de-facto standard fuzzer for rust and essentially it is just a proxy layer to the well tested libFuzzer engine. This means the algorithm and the interface is all based on libFuzzer which wildly-used coverage guided fuzzer for c/c++ and some other languages that implemented a proxy layer just like cargo-fuzz.

libFuzzer (cargo-fuzz) and coverage-guided fuzzers in general have the following algorithm:


Building & Running

If you are already familiar with this part you can skip to Continuous Fuzzing section.

we will use https://github.com/fuzzitdev/example-rust as a simple example.

For the sake of the example we have a simple function with an off-by-one bug:

our fuzz function will look like this and will be called by libFuzzer in an infinite loop with the generated data according to the coverage-guided algorithm.

To run the fuzzer we need to build an instrumented version of the code together with the fuzz function. cargo-fuzz is doing for us the heavy lifting so it can be done with the following simple steps:

This find the bug in a few seconds, prints the “FUZZI” string that triggers the vulnerability and saves it to a file.


Continuous Fuzzing

From our experience integrating continuous fuzzing into OSS projects we believe the following two workflows brings the most value:

The fuzzing workflow helps find new bugs, generate new test-cases and guarantee that your most recent version of the code was fuzzed.

The regression workflow helps validate pull-requests and find bugs before merging. Essentially adding another (free!) layer of unit-tests.

Now let’s look at a concrete example of how .travis.yml looks like though the same logic can be implemented in any CI (Circle,GithubActions, Jenkins, etc…)

in .travis.yml you can see exactly the two workflows:

  • fuzzing – which builds the fuzzers and uploads them to fuzzit so they can run asynchrounsly without blocking the CI.
  • local regression – which run the fuzzers through all generated test-cases and the fixed crashes inline in your CI so it will fail the CI and immediately notify about the bugs.

the fuzzit.sh itself contains the bash script itself that build the fuzz targets and either uploads them to fuzzit or runs locally for regression via fuzzit open-source CLI.


Summary

Fuzzing is a great way to improve your code. Wanna join the fuzzing revolution? try out fuzzit for free for your OSS project.

Featured Post

GolangNYC: Continuous Go Fuzzing Video + Slides

Hey, It’s Yevgeny Pats here.

I’ve had great time at Golang NYC September Meetup Special thanks to the organisers (Mofi rahman) , Dmitri Shuralyov from Go Team who also gave a very interesting talk and to Plated who hosted us.

Here is the video from my talk together with the slides. Enjoy.

Featured Post

Hear From Others

Dmitry Vyukov
Dmitry Vyukov@dvyukov
Read More
Woohoo! go-fuzz is supported on @fuzzitdev! Overall integration was smooth and everything worked. 2 bugs found immediately (don't know how we missed them before). Go fuzz your Go! Continuously!
ΚLAUS ΡΟST
ΚLAUS ΡΟST@sh0dan
Read More
Added @fuzzitdev continous fuzzing to my #golang compression package though Travis. Fairly straightforward and the first bug was found after 10 hours. Give it a try if you have fuzzable packages!
Previous
Next

Free for Open Source.

Drop us a line at oss@fuzzit.dev