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


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 – no response
  • Reached via linkedin to an executive who transferred me to 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:


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.


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

Comments are closed.