Autodesk FBX SDK <= 2019.2 Heap Overflow Exploitation

Overview

A heap overflow exists in the Autodesk FBX SDK (<= 2019.2) when an FBX file's header is parsed.

This post shows how exploitation of this vulnerability can take place.

Exploitation has been tested on an Ubuntu system with ASLR disabled in order to write a quick proof-of-concept.

Exploitation

The file header can be altered with single bytes to cause the SDK to load more data than is expected into the heap.

An interesting nuance discovered when exploiting this is that the filename affects where the crash occurs. On the test system, a file name of 5 or more characters (excluding the format) crashes at fbxsdk::FbxChainedFile::Seek.

The Seek method is pretty simple, as shown by the image below:

The crash occurs at mov r11, qword [rax+0x28] since rax now contains a snippet from the file (which of course isn't a real address that can be read from). Following this is a jmp r11 which can be utilized by point rax to an address that points to an address we wish to jump to, with 0x28 bytes subtracted. (More or less the same as saying jmp [rax+0x28]).

Since the data we can write to is in the heap (a non-executable area), it's not possible to cause shellcode to be executed. However, a shell can be spawned using a single address. This is because libc contains a number of addresses which execute /bin/sh, provided particular registers or values at addresses are null. An example of this is shown below:

In this case, as long as rsp+0x40 is null (At this point in the program, it is), a shell can be spawned.

Since ASLR has been disabled, both the address of this libc call and the location in the heap are know. By writing the address of this location into the file, we can set the point in the file that is taken by rax to address_of_shell_in_heap - 0x28.
To make this a little clearer, here's the layout of the exploit in the file:

The video below shows how this works:

POC Video