|
It may also be possible to use dlinfo to list all the symbols and then disallow anything other than that, though I have no idea how portable this solution is.
Well, dlinfo is also a GNU extension, as well dladdr which is easy to use.
Dladdr is defintely preferred. Unlike dlinfo it's present de-facto on most of supported by us platforms.
How carefully should this be handled? Is it OK to provide updated distribution packages with the fix (without sharing any information about the abuse mechanism beyond what is mentioned in the commit message)?
Previously we released packages and mentioned that they fix severe vulnerability. Details were disclosed approximately a month after it to let people update without great hurry.
TWIMC: I've tested this on windows (using fb 2.1 with win 2003, because that's what I needed) and this 'dll chaining' does not seem to work there. So the scope might be limited to *nix only.
I've also noticed that it is (still) possible to use 'internal' C++ symbols from fbudf.so, like Firebird::NoThrowTimeStamp::decode_timestamp (_ZN8Firebird16NoThrowTimeStamp16decode_timestampE13ISC_TIMESTAMPP2tmPi). May it be possible to use these to corrupt/manipulate memory in some unexpected ways? Is there a real need to make these symbols accessible in UDFs?
> 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.
Just for the record, it's already done in FB3. > May it be possible to use these to corrupt/manipulate memory in some unexpected ways?
Certainly possible. Moreover, it's very easy to corrupt something just passing invalid (i.e. unexpected by C code) parameters to absolutely valid entrypoints. The point of this issue is to avoid calling functions from underlying libraries, is not it so? >> The point of this issue is to avoid calling functions from underlying libraries, is not it so?
Absolutely. I was just wondering about other possible ways to use the default UDF functionality to escalate DBA to code exec and possible mitigations. MITRE assigned CVE-2017-6369 for this issue. Please let me know when the issue is ready for publication.
Will do.
Next week we plan to release 3.0.2 (2.5.7 is already out) and after it we should give one-two weeks for 3.0 users to upgrade. What is the simplest way to reproduce this issue?
I've tried here and only got an error 3900: SQL> DECLARE EXTERNAL FUNCTION EXEC cstring(4096), integer RETURNS integer BY VALUE ENTRY_POINT 'system' MODULE_NAME 'fbudf' ; SQL> select first 1 EXEC('touch /tmp/proof') from SALES; Statement failed, SQLSTATE = 39000 function EXEC could not be matched anything i should enable or grant? this is as the default sysdba user... George, 3.0.2 is released and people had time to upgrade. I suppose it's OK to publish it.
@anarcat
The following works for me: # ./isql -z employee ISQL Version: LI-V2.5.5.26952 Firebird 2.5 Server version: LI-V2.5.5.26952 Firebird 2.5 Database: employee SQL> DECLARE EXTERNAL FUNCTION system cstring(4096) RETURNS integer BY VALUE ENTRY_POINT 'system' MODULE_NAME 'fbudf'; SQL> select system('touch /tmp/proof') from rdb$database; SYSTEM ============ 0 SQL> shell ls /tmp/proof; /tmp/proof SQL> |
It seems some OSs have RTLD_FIRST to restrict lookups for only the passed library, but glibc does not have it.
Should it be checked with dladdr after dlsym? But dladdr is also a function that is not always present.