Issue Details (XML | Word | Printable)

Key: CORE-6409
Type: Bug Bug
Status: Open Open
Priority: Minor Minor
Assignee: Alexander Peshkov
Reporter: Luciano Mendes
Votes: 0
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
Firebird Core

SRP authentication is vulnerable to SQL attacks because its metadata is not system objects

Created: 28/Sep/20 10:15 AM   Updated: 06/Oct/20 04:58 PM
Component/s: None
Affects Version/s: 3.0.6, 3.0.7
Fix Version/s: None

Environment:
Windows 10 (x64) Version 2004
Firebird 3.0.7.33365 (snapshot)

QA Status: No test


 Description  « Hide
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 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
}

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 06/Oct/20 04:58 PM
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.