Firebird fbudf Module string2blob() Function Remote Code Execution [CORE5518] #5787
Submitted by: Brian Martin (bmartin)
Relate to CORE5657
While working on a detection plugin for CVE-2017-6369 / VulnDB 154295, Tenable found an authenticated remote code execution vulnerability in Firebird SQL Server. It started with a pedestrian DOS that would just kill the server and after investigating, it turned into code execution. We tested this with a Firebird 2.5.7 32-bit Windows installation on a fresh "IE8 on Win7" VM. Since it was installed with default settings, it is configured as a system service, which means we get SYSTEM code exec.
The vulnerability exists due to a flaw in how external module functions are defined in Firebird SQL, along with how the string2blob() functoin is implemented in the fbudf module that ships with Firebird. If we declare an external function with the wrong parameters, we can manipulate the fields in a blob struct, which includes a function pointer. In string2blob(), the second parameter (outblob) is a blob and we can effectively set the outblob->blob_put_segment() function pointer by passing it a varchar instead of a blob. The string2blob() function then calls outblob->blob_put_segment() and we get control of the EIP.
On Windows 7 we were able to figure out how to pass shellcode that pops everyone's favorite utility (calc.exe) as the first parameter, and have outblob->blob_put_segment() point to it. This works reliably on a freshly running Firebird binary (it crashes the server after spawning calc), but on a server that's been running for awhile it just crashes the server. This is fine as fbguard will respawn the crashed server, so it just takes two attempts to exploit it properly.
You only require normal user database credentials in 2.5.7 to declare external functions, but in 3.0.2 you need database administrator credentials.
Here are the reproduction steps:
Caveat: If the server has been running for any period of time the exploit is unreliable and will only crash the server. Luckily we have fbguard running that will restart it, and the exploit seems to work 100% against a freshly started server. So if this is the first time running a6(), wait a few seconds for fbguard to restart the server and run the previous select a6() line again.
This is tailored for 2.5.7 32 bit on Windows 7, but we've confirmed that we can control EIP on a 64 bit Linux version and also version 3.0.2, so it's just a matter of developing a reliable exploit for these platforms.
Here's an additional denial of service PoC (NULL pointer deref causing server crash) for another function in the fbudf module. This simpler PoC should work on any version, any OS:
There are likely issues with more of the functions in fbudf and ib_udf, so the fix for this should ensure it covers any functions in the external modules that are shipped with Firebird SQL. Unfortunately, we did not have time to test them all.
The text was updated successfully, but these errors were encountered: