FirebirdSQL / firebird

Firebird server, client and tools
https://www.firebirdsql.org/
1.23k stars 213 forks source link

SRP authentication is vulnerable to SQL attacks because its metadata is not system objects [CORE6409] #6647

Open firebird-automations opened 3 years ago

firebird-automations commented 3 years ago

Submitted by: @luronumen

ACTUAL RESULT - SRP authentication is vulnerable to SQL attacks because its metadata is not system objects. - Any user with permissions to create tables technically could, through SQL commands, attack the SRP plugin metadata (PLG$SRP table and PLG$SRP_VIEW view). - Error on creating a SRP user because the SRP plugin metadata (PLG$SRP table and PLG$SRP_VIEW view) are not considered as reserved (system objects). - The following issue happen when it is tried to create the SYSDBA user inside the database using the SRP plugin where a PLG$SRP table and a PLG$SRP_VIEW view that does not match with the native Firebird 3.0 SRP plugin metadata already exists:

Database: TEST, User: SYSDBA SQL> Statement failed, SQLSTATE = 42S22 no operation specified -Dynamic SQL Error -SQL error code = -206 -Column unknown -PLG$SRP_VIEW.PLG$USER_NAME -At line 1, column 328 SQL>

EXPECTED RESULT - SRP authentication should NOT be vulnerable to SQL attacks. - No user with permission to create tables in the database could have permission to create/edit the SRP plugin metadata (PLG$SRP table and PLG$SRP_VIEW view). - The SRP plugin metadata (PLG$SRP table and PLG$SRP_VIEW view) should be considered as reserved (system objects) because the user should NOT be able to create/edit the PLG$SRP table and the PLG$SRP_VIEW view in the database. - The SRP is a native plugin for Firebird 3.0 and its metadata (PLG$SRP table and PLG$SRP_VIEW view) should work like MON$, RDB$ and SEC$ tables (system objects). - The PLG$SRP table, the PLG$SRP_VIEW view and all its permissions should be created automatically as reserved (system objects) when a Firebird 3.0 (ODS 12) database is created.

STEPS TO REPRODUCE THE ISSUE 1- Make sure that the FirebirdSQL 3.0 service is NOT running: net stop FirebirdServerDefaultInstance

2- Run the following command to create the TEST database: ECHO SET SQL DIALECT 3;CREATE DATABASE 'TEST' PAGE_SIZE 8192 DEFAULT CHARACTER SET WIN1252; | "C:\Program Files\Firebird\Firebird_3_0\isql.exe" -user SYSDBA

3- Run the following command to create a PLG$SRP table and a PLG$SRP_VIEW view that does not match with the native Firebird 3.0 SRP plugin metadata: ECHO CREATE TABLE PLG$SRP (ID BIGINT);COMMIT;CREATE VIEW PLG$SRP_VIEW (ID) AS SELECT ID FROM PLG$SRP;COMMIT; | "C:\Program Files\Firebird\Firebird_3_0\isql.exe" -user SYSDBA "TEST"

4- Run the following command to create the SYSDBA user inside the TEST database using the SRP plugin: ECHO CREATE OR ALTER USER SYSDBA SET PASSWORD 'masterkey' USING PLUGIN SRP;COMMIT; | "C:\Program Files\Firebird\Firebird_3_0\isql.exe" -user SYSDBA "TEST"

OTHER INFORMATION - Please see the "[firebird-support] Firebird 3.0 - About PLG$SRP table and PLG$SRP_VIEW view" discussion on mailto:firebird-support@googlegroups.com.

ENVIRONMENT SETUP

firebird.conf

⁠SETUP

UserManager = Srp, Legacy_UserManager WireCrypt = Enabled

databases.conf

TEST = D:\APPLICATIONS\LURONUMEN\DB\TEST.FDB { AuthServer = Srp SecurityDatabase = TEST UserManager = Srp }

firebird-automations commented 3 years ago
Modified by: @AlexPeshkoff assignee: Alexander Peshkov \[ alexpeshkoff \]
firebird-automations commented 3 years ago

Commented by: @AlexPeshkoff

Very "dangerous" attack - requires stopped server (i.e. embedded access to database) and sysdba-like rights (to be precise - not a problem when embedded access is possible). Yes, having embedded access one can break some functionality, it's well known fact, embedded access is only for trusted users.

PS. As soon as we introduce namespaces the issue will be gone, currently making temporary hack for such kind of issues makes no sense.

firebird-automations commented 3 years ago
Modified by: @AlexPeshkoff priority: Critical \[ 2 \] =\> Minor \[ 4 \]