Firebird Security (in English): The Past and The Future

Security in Firebird: 2.1, 2.5, 3.0

Alex Peshkov

(peshkoff at mail.ru)

First years of InterBase

In order to understand security problems of Firebird, we should consider historical issues

At that time there was another approach to database and server security

1984 – hardware and software was not like today

No Internet like we see it today

Hardware (PDP11, VAX11) requirements to run RDBMS

Multiuser mode is 'many processes', not 'many threads' – relatively safe even in case of buffer overflow

No strong requirements to RDBMS security

No abilities to support strong requirements even if they presented

-- as the result --

Lot of small buffers without overflow control

External tables and UDFs – one can store any data as external table and call as UDF

'root' runuser

RDBMS is anyway safe!

Approach to security in Borland

1992-1993:

Windows 3.X port

Need to have own users list – database isc4.gdb

Access to it from server itself for authentication purposes (use of login 'politically' and password 'correct' for it)‏

Local access protocol using Windows events (PostEvent(), etc.)‏

Windows NT (95) port

Use of multi-thread access model instead of mutli-process

No buffers' size review (!)

No integration between own users list and host OS accounts

Local protocol is still using Windows Events

Runs as LocalSystem account

Borland security solutions for InterBase

Firebird security development

Year 2002: 1.0

Fixed serious vulnerability was eliminated

“ politically correct” left the building

Assessment of the most dangerous places in firebird code base

Year 2004: 1.5

Fixed vulnerabilities:

'root' (LocalSystem) server execution (in Windows – prevents use of local access protocol)‏

Arbitrary code execution using standard SQL language tools (External Table + UDF)‏

Access to any database as a 'raw' file

Some buffers overflows

Year 2006: 2.0

Fixed vulnerabilities:

More buffers overflows fixed

Ability to read passwords' hashes from security database using any valid login

Started code review in order to completely avoid buffer overflows in strings (file names, etc.)‏

New feature:

User can change own password (only superuser could change any password before)‏

Firebird 2.1- what's new

Fixed vulnerability:

Finished buffers overflow hunting – no new bugreports during last year.

New feature:

Use Windows trusted authentication to login to Firebird server

Firebird 2.1: windows trusted authentication

Authentication using own security database

Client Server Attach Accept (or reject)‏

Firebird 2.1: windows trusted authentication

Using windows trusted authentication

Client Server ......

May require passing data between client and server many times.

Use native authentication API

Attach trusted Request to adjust security contex Adjusted security context Accept (or reject)‏

Traditional authentication (client)‏ fbclient library isc_dpb_user_name isc_dpb_password ......... Environment variables isc_dpb_user_name isc_dpb_password ......... Login/password may be picked up from environment by client library ISC_USER=..

Traditional authentication (server)‏ Network listener Database engine Validation in security database isc_dpb_user_name isc_dpb_password ......... isc_dpb_user_name isc_dpb_password Validation is performed by DB engine

Trusted authentication (client)‏ isc_dpb_trusted ......... ......... ......... Environment variables fbclient library Client library automatically adds trusted auth request to DPB

Trusted Authentication (client)‏ ......... ......... isc_dpb_user_name isc_dpb_password ......... Environment variables fbclient library Login is picked up from environmnet (backward compatibility)‏ ISC_USER=..

Trusted Authentication (client)‏ isc_dpb_trusted isc_dpb_trusted ......... ......... Environment variables fbclient library Adding isc_dpb_trusted by application to force trusted auth. ISC_USER=..

Trusted Authentication (server)‏ isc_dpb_trusted Network listener .......... isc_dpb_trusted ......... DB engine Host OS validation (callback)‏ Network listener does all work, on success puts internal tag into DPB.

Trusted Authentication (server)‏ isc_dpb_trusted Network listener .......... isc_dpb_trusted ......... isc_dpb_trusted Host OS validation (callback)‏ DB engine Safe - network listener removes extra isc_dpb_trusted tags from DPB

Firebird 2.5 - what's new

Fixed vulnerabilities

Attack on server using large packets with garbage

New features

User management in SQL (CREATE / ALTER / DROP USER)‏

System role RDB$ADMIN

Configure mapping of domain administrators to RDB$ADMIN role using SQL

New GRANTED BY clause in GRANT and REVOKE operators

User management in SQL

CREATE USER name PASSWORD 'pw' FIRSTNAME 'first' MIDDLENAME 'middle' LASTNAME 'last'

ALTER USER name PASSWORD 'pw' FIRSTNAME 'first' MIDDLENAME 'middle' LASTNAME 'last'

DROP USER name

User management in SQL

In firebird 2.5 this commands always work with common security database security2.fdb

Alter User <Current_user> is available for all users, the rest – only to SYSDBA

System role RDB$ADMIN

GRANT “RDB$ADMIN” TO GUEST1

When attaching to current database with role RDB$ADMIN user GUEST1 will have all rights of database administrator (SYSDBA)‏

REVOKE “RDB$ADMIN” FROM GUEST1

Configure mapping of domain administrators to RDB$ADMIN role using SQL

ALTER ROLE RDB$ADMIN SET / DROP AUTO ADMIN MAPPING

This is restricted form of a command, planned to control mapping of host OS objects to database objects in firebird 3

New GRANTED BY clause in GRANT and REVOKE operators

Makes it possible for SYSDBA to revoke rights, granted by other users

sysdba:

CREATE ROLE role1;

GRANT role1 TO user1 WITH ADMIN OPTION;

user1:

GRANT role1 TO PUBLIC;

sysdba:

REVOKE role1 FROM PUBLIC GRANTED BY user1;

Firebird 3 (plan)‏

Authentication architecture review when using OSRI in firebird

Choose (at configuration level) any database as security database, including target database itself

Authentication plugins

Mapping OS objects to database objects (groups, users, etc.)‏

OSRI (Open System Relational Interface)‏ Engine13 Yvalve Network listener User program (isql, php, etc.)‏ Engine8_12 Network redirector Providers Clients In FB3 we plan to have OSRI alive again. How does it affect auth?

IB, FB1, FB2 – user authentication is in engine Yvalve Network listener Engine “ rear entrance” is used to avoid recursion politically correct - InterBase 4, 5, 6 TLS – Firebird 1, 2 Authentication Engine needs a way to call itself for authentication purporses without authentication – avoiding infinite recursion

Firebird3 - user authentication in network listener Yvalve Network listener Providers Engine8_12 Engine13 Network redirector Authentication Plugins trusted zone Authenticator and plugins can easily use all our API – in-process access to it. No need in any “rare entrance”.

Choose (at configuration level) any database as security database

<database alias1>

FileName = $(root)/db/data1.fdb

Security = $(root)/db/secure.fdb

</database>

<database inside>

FileName = /raid/data.fdb

Security = self

</database>

<database *>

FileName = $(arg0)‏

Security = $(root)/security2.fdb

</database>

Choose any database as security database – another configuration file format, same effect

[alias1]

FileName = $(root)/db/data1.fdb

Security = $(root)/db/secure.fdb

[inside]

FileName = /raid/data.fdb

Security = self

[*]

FileName = $(arg0)‏

Security = $(root)/security2.fdb

Authentication plugins

Use any authentication methods

Plugin samples

Current security database

Trusted authentication from 2.1

Trusted authentication based on asymmetric keys match: public – stored on server (in database), private – stored by client

Passwords verified in LDAP, PAM, etc.

Unlimited length of password

Use CHAP to validate passwords

Mapping OS objects to database objects

Configured on per-database basis using SQL:

ALTER ROLE name ADD OS_NAME 'os_name'

ALTER USER name ADD OS_NAME 'os_name'

ALTER ROLE name DROP OS_NAME 'os_name'

ALTER USER name DROP OS_NAME 'os_name'

(syntax may be changed)‏

OS object may be mapped not more then to single user and single role

ALTER USER user1 ADD OS_NAME 'guest'

ALTER USER user2 ADD OS_NAME 'guest'

Running second command throws an error

Security plugin builds a list of OS objects, each of them is assiggned a kind of priority – lower digit means higher priority.

Priority 0 means 'use this object as current_user unconditionally'

Providers use information from this list (passed in DPB) to obtain CURRENT_USER and CURRENT_ROLE values.

Sample 1 – authentication in security database

Security database authentication (when successful) puts single object in a list:

Username (1)‏

in () priority is given

Objects list:

username (1)‏

< no maps in DB >

Firebird 3 (plan)‏ Mapping result: current_user = USERNAME current_role = NONE

Example 1 - authentication is security database

Objects list:

username (1)‏

ALTER USER SYSDBA ADD OS_NAME 'username'

Firebird 3 (plan)‏ Mapping result: current_user = SYSDBA current_role = NONE

Example 1 - authentication is security database

In this was we have an easy way to grant people “god” rights in particular database.

Example 2 – windows trusted authentication

Typically this plugin will put in the objects' list something like:

DomUser (1)‏

Domain Users (2)‏

Domain Admins (2)‏

Objects list:

DomUser (1)‏

Domain Users (2)‏

< no maps in DB >

Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = NONE

Objects list:

DomUser (1)‏

Domain Users (2)‏

ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins'

Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = RDB$ADMIN

Objects list:

DomUser (1)‏

Domain Users (2)‏

ALTER ROLE USERS ADD OS_NAME 'Domain Users'

Firebird 3 (plan)‏ Mapping result: ERROR – what role to choose?

Objects list:

DomUser (1)‏

Domain Users (2)‏

ALTER ROLE USERS ADD OS_NAME 'DomUser'

Use of higher-priority mapping (1) makes it possible to resolve conflict – i.e. users mapping is always prefered over group.

Users may be mapped to roles and groups – to users.

Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = USERS

Objects list:

DomUser (1)‏

Domain Users (2)‏

ALTER ROLE USERS ADD OS_NAME 'DomUser'

ALTER USER GUEST ADD OS_NAME 'DomUser'

This example shows how you should NOT setup mapping in your databases!

Firebird 3 (plan)‏ Mapping result: current_user = GUEST current_role = USERS

Objects list:

DomUser (1)‏

Finance (2)‏

Domain Users (2)‏

ALTER ROLE CHIEF ADD OS_NAME 'Chief'

ALTER ROLE FINANCE ADD OS_NAME 'Finance'

This is real-life example.

Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = FINANCE

Thanks for your attention! www.firebirdsql.org

Firebird Security (in English): The Past and The Future

0 comments

Notes on slide 1

1 Favorite