Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
firebird-automations opened this issue Sep 28, 2020 · 3 comments

Comments

@firebird-automations
Copy link
Collaborator

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
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

assignee: Alexander Peshkov [ alexpeshkoff ]

@firebird-automations
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Modified by: @AlexPeshkoff

priority: Critical [ 2 ] => Minor [ 4 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants