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

First years of InterBase 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

First years of InterBase 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

Firebird security development 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

Firebird security development 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

Firebird 2.5 - what's new 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

Firebird 2.5 - what's new 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

Firebird 2.5 - what's new 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

Firebird 2.5 - what's new 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

Firebird 2.5 - what's new New GRANTED BY clause in GRANT and REVOKE operators Makes it possible for SYSDBA to revoke rights, granted by other users

Firebird 2.5 - what's new 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”.

Firebird 3 (plan)‏ 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>

Firebird 3 (plan)‏ 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

Firebird 3 (plan)‏ 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

Firebird 3 (plan)‏ 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)‏

Firebird 3 (plan)‏ Mapping OS objects to database objects 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

Firebird 3 (plan)‏ Mapping OS objects to database objects 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.

Firebird 3 (plan)‏ Mapping OS objects to database objects 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.

Firebird 3 (plan)‏ Mapping OS objects to database objects Example 2 – windows trusted authentication Typically this plugin will put in the objects' list something like: Dom\User (1)‏ Domain Users (2)‏ Domain Admins (2)‏

Objects list: Dom\User (1)‏ Domain Admins (2)‏ Domain Users (2)‏ < no maps in DB > Firebird 3 (plan)‏ Mapping result: current_user = Dom\User current_role = NONE Example 2 – windows trusted authentication

Objects list: Dom\User (1)‏ Domain Admins (2)‏ Domain Users (2)‏ ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' Firebird 3 (plan)‏ Mapping result: current_user = Dom\User current_role = RDB$ADMIN Example 2 – windows trusted authentication

Objects list: Dom\User (1)‏ Domain Admins (2)‏ Domain Users (2)‏ ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' ALTER ROLE USERS ADD OS_NAME 'Domain Users' Firebird 3 (plan)‏ Mapping result: ERROR – what role to choose? Example 2 – windows trusted authentication

Objects list: Dom\User (1)‏ Domain Admins (2)‏ Domain Users (2)‏ ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' ALTER ROLE USERS ADD OS_NAME 'Domain Users' ALTER ROLE USERS ADD OS_NAME 'Dom\User' 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 = Dom\User current_role = USERS Example 2 – windows trusted authentication

Objects list: Dom\User (1)‏ Domain Admins (2)‏ Domain Users (2)‏ ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' ALTER ROLE USERS ADD OS_NAME 'Domain Users' ALTER ROLE USERS ADD OS_NAME 'Dom\User' ALTER USER GUEST ADD OS_NAME 'Dom\User' This example shows how you should NOT setup mapping in your databases! Firebird 3 (plan)‏ Mapping result: current_user = GUEST current_role = USERS Example 2 – windows trusted authentication

Objects list: Dom\User (1)‏ Finance (2)‏ Domain Users (2)‏ ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' 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 = Dom\User current_role = FINANCE Example 2 – windows trusted authentication

Thanks for your attention! www.firebirdsql.org

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

More Related Content

What's hot (20)

Similar to Firebird Security (in English): The Past and The Future (20)

More from Alexey Kovyazin (20)

Recently uploaded (20)

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