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

9,107 views
8,873 views

Published on

This presentation was made by Alex Peshkoff, Firebird Core developer in 2008 at Bergamo Firebird Conference. Alex is responsible for implementing security plans in Firebird, and here he gives insights on past issues with security in InterBase, caused by Borland "workarounds", and introduces brand new approach for security in Firebird 2.5 and 3.0

Published in: Technology, Business
1 Comment
3 Likes
Statistics
Notes
  • If i change server password and some overwrites security2.fdb over my , can he access my FB server ?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
9,107
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
146
Comments
1
Likes
3
Embeds 0
No embeds

No notes for slide

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

  1. 1. Security in Firebird: 2.1, 2.5, 3.0 <ul><ul><li>Alex Peshkov </li></ul></ul><ul><ul><li>(peshkoff at mail.ru) </li></ul></ul>
  2. 2. First years of InterBase <ul><li>In order to understand security problems of Firebird, we should consider historical issues </li></ul><ul><li>At that time there was another approach to database and server security </li></ul>
  3. 3. First years of InterBase <ul><li>1984 – hardware and software was not like today </li></ul><ul><li>No Internet like we see it today </li></ul><ul><li>Hardware (PDP11, VAX11) requirements to run RDBMS </li></ul><ul><li>Multiuser mode is 'many processes', not 'many threads' – relatively safe even in case of buffer overflow </li></ul>
  4. 4. First years of InterBase <ul><li>No strong requirements to RDBMS security </li></ul><ul><li>No abilities to support strong requirements even if they presented </li></ul><ul><li>-- as the result -- </li></ul><ul><li>Lot of small buffers without overflow control </li></ul><ul><li>External tables and UDFs – one can store any data as external table and call as UDF </li></ul><ul><li>'root' runuser </li></ul>RDBMS is anyway safe!
  5. 5. Approach to security in Borland <ul><li>1992-1993: </li></ul><ul><li>Windows 3.X port </li></ul><ul><ul><li>Need to have own users list – database isc4.gdb </li></ul></ul><ul><ul><li>Access to it from server itself for authentication purposes (use of login 'politically' and password 'correct' for it)‏ </li></ul></ul><ul><ul><li>Local access protocol using Windows events (PostEvent(), etc.)‏ </li></ul></ul>
  6. 6. <ul><li>Windows NT (95) port </li></ul><ul><ul><li>Use of multi-thread access model instead of mutli-process </li></ul></ul><ul><ul><li>No buffers' size review (!) </li></ul></ul><ul><ul><li>No integration between own users list and host OS accounts </li></ul></ul><ul><ul><li>Local protocol is still using Windows Events </li></ul></ul><ul><ul><li>Runs as LocalSystem account </li></ul></ul>Borland security solutions for InterBase
  7. 7. Firebird security development <ul><li>Year 2002: 1.0 </li></ul><ul><li>Fixed serious vulnerability was eliminated </li></ul><ul><ul><li>“ politically correct” left the building </li></ul></ul><ul><li>Assessment of the most dangerous places in firebird code base </li></ul>
  8. 8. Firebird security development <ul><li>Year 2004: 1.5 </li></ul><ul><li>Fixed vulnerabilities: </li></ul><ul><ul><li>'root' (LocalSystem) server execution (in Windows – prevents use of local access protocol)‏ </li></ul></ul><ul><ul><li>Arbitrary code execution using standard SQL language tools (External Table + UDF)‏ </li></ul></ul><ul><ul><li>Access to any database as a 'raw' file </li></ul></ul><ul><ul><li>Some buffers overflows </li></ul></ul>
  9. 9. Firebird security development <ul><li>Year 2006: 2.0 </li></ul><ul><li>Fixed vulnerabilities: </li></ul><ul><ul><li>More buffers overflows fixed </li></ul></ul><ul><ul><li>Ability to read passwords' hashes from security database using any valid login </li></ul></ul><ul><ul><li>Started code review in order to completely avoid buffer overflows in strings (file names, etc.)‏ </li></ul></ul><ul><li>New feature: </li></ul><ul><ul><li>User can change own password (only superuser could change any password before)‏ </li></ul></ul>
  10. 10. Firebird 2.1- what's new <ul><li>Fixed vulnerability: </li></ul><ul><ul><li>Finished buffers overflow hunting – no new bugreports during last year. </li></ul></ul><ul><li>New feature: </li></ul><ul><ul><li>Use Windows trusted authentication to login to Firebird server </li></ul></ul>
  11. 11. Firebird 2.1: windows trusted authentication <ul><li>Authentication using own security database </li></ul>Client Server Attach Accept (or reject)‏
  12. 12. Firebird 2.1: windows trusted authentication <ul><li>Using windows trusted authentication </li></ul>Client Server ...... <ul><li>May require passing data between client and server many times. </li></ul><ul><li>Use native authentication API </li></ul>Attach trusted Request to adjust security contex Adjusted security context Accept (or reject)‏
  13. 13. 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=..
  14. 14. 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
  15. 15. Trusted authentication (client)‏ isc_dpb_trusted ......... ......... ......... Environment variables fbclient library Client library automatically adds trusted auth request to DPB
  16. 16. Trusted Authentication (client)‏ ......... ......... isc_dpb_user_name isc_dpb_password ......... Environment variables fbclient library Login is picked up from environmnet (backward compatibility)‏ ISC_USER=..
  17. 17. 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=..
  18. 18. 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.
  19. 19. 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
  20. 20. Firebird 2.5 - what's new <ul><li>Fixed vulnerabilities </li></ul><ul><ul><li>Attack on server using large packets with garbage </li></ul></ul><ul><li>New features </li></ul><ul><ul><li>User management in SQL (CREATE / ALTER / DROP USER)‏ </li></ul></ul><ul><ul><li>System role RDB$ADMIN </li></ul></ul><ul><ul><li>Configure mapping of domain administrators to RDB$ADMIN role using SQL </li></ul></ul><ul><ul><li>New GRANTED BY clause in GRANT and REVOKE operators </li></ul></ul>
  21. 21. Firebird 2.5 - what's new <ul><li>User management in SQL </li></ul><ul><li>CREATE USER name PASSWORD 'pw' FIRSTNAME 'first' MIDDLENAME 'middle' LASTNAME 'last' </li></ul><ul><li>ALTER USER name PASSWORD 'pw' FIRSTNAME 'first' MIDDLENAME 'middle' LASTNAME 'last' </li></ul><ul><li>DROP USER name </li></ul>
  22. 22. Firebird 2.5 - what's new <ul><li>User management in SQL </li></ul><ul><li>In firebird 2.5 this commands always work with common security database security2.fdb </li></ul><ul><li>Alter User <Current_user> is available for all users, the rest – only to SYSDBA </li></ul>
  23. 23. Firebird 2.5 - what's new <ul><li>System role RDB$ADMIN </li></ul><ul><li>GRANT “RDB$ADMIN” TO GUEST1 </li></ul><ul><ul><li>When attaching to current database with role RDB$ADMIN user GUEST1 will have all rights of database administrator (SYSDBA)‏ </li></ul></ul><ul><li>REVOKE “RDB$ADMIN” FROM GUEST1 </li></ul>
  24. 24. Firebird 2.5 - what's new <ul><li>Configure mapping of domain administrators to RDB$ADMIN role using SQL </li></ul><ul><li>ALTER ROLE RDB$ADMIN SET / DROP AUTO ADMIN MAPPING </li></ul><ul><ul><li>This is restricted form of a command, planned to control mapping of host OS objects to database objects in firebird 3 </li></ul></ul>
  25. 25. Firebird 2.5 - what's new <ul><li>New GRANTED BY clause in GRANT and REVOKE operators </li></ul><ul><ul><li>Makes it possible for SYSDBA to revoke rights, granted by other users </li></ul></ul>
  26. 26. Firebird 2.5 - what's new <ul><li>sysdba: </li></ul><ul><li>CREATE ROLE role1; </li></ul><ul><li>GRANT role1 TO user1 WITH ADMIN OPTION; </li></ul><ul><li>user1: </li></ul><ul><li>GRANT role1 TO PUBLIC; </li></ul><ul><li>sysdba: </li></ul><ul><li>REVOKE role1 FROM PUBLIC GRANTED BY user1; </li></ul>
  27. 27. Firebird 3 (plan)‏ <ul><li>Authentication architecture review when using OSRI in firebird </li></ul><ul><li>Choose (at configuration level) any database as security database, including target database itself </li></ul><ul><li>Authentication plugins </li></ul><ul><li>Mapping OS objects to database objects (groups, users, etc.)‏ </li></ul>
  28. 28. 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?
  29. 29. 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
  30. 30. 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”.
  31. 31. Firebird 3 (plan)‏ <ul><li>Choose (at configuration level) any database as security database </li></ul><ul><li><database alias1> </li></ul><ul><li>FileName = $(root)/db/data1.fdb </li></ul><ul><li>Security = $(root)/db/secure.fdb </li></ul><ul><li></database> </li></ul><ul><li><database inside> </li></ul><ul><li>FileName = /raid/data.fdb </li></ul><ul><li>Security = self </li></ul><ul><li></database> </li></ul><ul><li><database *> </li></ul><ul><li>FileName = $(arg0)‏ </li></ul><ul><li>Security = $(root)/security2.fdb </li></ul><ul><li></database> </li></ul>
  32. 32. Firebird 3 (plan)‏ <ul><li>Choose any database as security database – another configuration file format, same effect </li></ul><ul><li>[alias1] </li></ul><ul><li>FileName = $(root)/db/data1.fdb </li></ul><ul><li>Security = $(root)/db/secure.fdb </li></ul><ul><li>[inside] </li></ul><ul><li>FileName = /raid/data.fdb </li></ul><ul><li>Security = self </li></ul><ul><li>[*] </li></ul><ul><li>FileName = $(arg0)‏ </li></ul><ul><li>Security = $(root)/security2.fdb </li></ul>
  33. 33. Firebird 3 (plan)‏ <ul><li>Authentication plugins </li></ul><ul><ul><li>Use any authentication methods </li></ul></ul><ul><li>Plugin samples </li></ul><ul><ul><li>Current security database </li></ul></ul><ul><ul><li>Trusted authentication from 2.1 </li></ul></ul><ul><ul><li>Trusted authentication based on asymmetric keys match: public – stored on server (in database), private – stored by client </li></ul></ul><ul><ul><li>Passwords verified in LDAP, PAM, etc. </li></ul></ul><ul><ul><li>Unlimited length of password </li></ul></ul><ul><ul><li>Use CHAP to validate passwords </li></ul></ul>
  34. 34. Firebird 3 (plan)‏ <ul><li>Mapping OS objects to database objects </li></ul><ul><li>Configured on per-database basis using SQL: </li></ul><ul><ul><li>ALTER ROLE name ADD OS_NAME 'os_name' </li></ul></ul><ul><ul><li>ALTER USER name ADD OS_NAME 'os_name' </li></ul></ul><ul><ul><li>ALTER ROLE name DROP OS_NAME 'os_name' </li></ul></ul><ul><ul><li>ALTER USER name DROP OS_NAME 'os_name' </li></ul></ul><ul><ul><ul><li>(syntax may be changed)‏ </li></ul></ul></ul>
  35. 35. Firebird 3 (plan)‏ <ul><li>Mapping OS objects to database objects </li></ul><ul><li>OS object may be mapped not more then to single user and single role </li></ul><ul><ul><li>ALTER USER user1 ADD OS_NAME 'guest' </li></ul></ul><ul><ul><li>ALTER USER user2 ADD OS_NAME 'guest' </li></ul></ul><ul><ul><ul><li>Running second command throws an error </li></ul></ul></ul>
  36. 36. Firebird 3 (plan)‏ <ul><li>Mapping OS objects to database objects </li></ul><ul><li>Security plugin builds a list of OS objects, each of them is assiggned a kind of priority – lower digit means higher priority. </li></ul><ul><li>Priority 0 means 'use this object as current_user unconditionally' </li></ul><ul><li>Providers use information from this list (passed in DPB) to obtain CURRENT_USER and CURRENT_ROLE values. </li></ul>
  37. 37. Firebird 3 (plan)‏ <ul><li>Mapping OS objects to database objects </li></ul><ul><li>Sample 1 – authentication in security database </li></ul><ul><li>Security database authentication (when successful) puts single object in a list: </li></ul><ul><ul><li>Username (1)‏ </li></ul></ul><ul><ul><ul><li>in () priority is given </li></ul></ul></ul>
  38. 38. <ul><li>Objects list: </li></ul><ul><li>username (1)‏ </li></ul><ul><li>< no maps in DB > </li></ul>Firebird 3 (plan)‏ Mapping result: current_user = USERNAME current_role = NONE <ul><li>Example 1 - authentication is security database </li></ul>
  39. 39. <ul><li>Objects list: </li></ul><ul><li>username (1)‏ </li></ul><ul><li>ALTER USER SYSDBA ADD OS_NAME 'username' </li></ul>Firebird 3 (plan)‏ Mapping result: current_user = SYSDBA current_role = NONE <ul><li>Example 1 - authentication is security database </li></ul>In this was we have an easy way to grant people “god” rights in particular database.
  40. 40. Firebird 3 (plan)‏ <ul><li>Mapping OS objects to database objects </li></ul><ul><li>Example 2 – windows trusted authentication </li></ul><ul><li>Typically this plugin will put in the objects' list something like: </li></ul><ul><ul><li>DomUser (1)‏ </li></ul></ul><ul><ul><li>Domain Users (2)‏ </li></ul></ul><ul><ul><li>Domain Admins (2)‏ </li></ul></ul>
  41. 41. <ul><li>Objects list: </li></ul><ul><li>DomUser (1)‏ </li></ul><ul><li>Domain Admins (2)‏ </li></ul><ul><li>Domain Users (2)‏ </li></ul><ul><li>< no maps in DB > </li></ul>Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = NONE <ul><li>Example 2 – windows trusted authentication </li></ul>
  42. 42. <ul><li>Objects list: </li></ul><ul><li>DomUser (1)‏ </li></ul><ul><li>Domain Admins (2)‏ </li></ul><ul><li>Domain Users (2)‏ </li></ul><ul><li>ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' </li></ul>Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = RDB$ADMIN <ul><li>Example 2 – windows trusted authentication </li></ul>
  43. 43. <ul><li>Objects list: </li></ul><ul><li>DomUser (1)‏ </li></ul><ul><li>Domain Admins (2)‏ </li></ul><ul><li>Domain Users (2)‏ </li></ul><ul><li>ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' </li></ul><ul><li>ALTER ROLE USERS ADD OS_NAME 'Domain Users' </li></ul>Firebird 3 (plan)‏ Mapping result: ERROR – what role to choose? <ul><li>Example 2 – windows trusted authentication </li></ul>
  44. 44. <ul><li>Objects list: </li></ul><ul><li>DomUser (1)‏ </li></ul><ul><li>Domain Admins (2)‏ </li></ul><ul><li>Domain Users (2)‏ </li></ul><ul><li>ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' </li></ul><ul><li>ALTER ROLE USERS ADD OS_NAME 'Domain Users' </li></ul><ul><li>ALTER ROLE USERS ADD OS_NAME 'DomUser' </li></ul><ul><li>Use of higher-priority mapping (1) makes it possible to resolve conflict – i.e. users mapping is always prefered over group. </li></ul><ul><li>Users may be mapped to roles and groups – to users. </li></ul>Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = USERS <ul><li>Example 2 – windows trusted authentication </li></ul>
  45. 45. <ul><li>Objects list: </li></ul><ul><li>DomUser (1)‏ </li></ul><ul><li>Domain Admins (2)‏ </li></ul><ul><li>Domain Users (2)‏ </li></ul><ul><li>ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' </li></ul><ul><li>ALTER ROLE USERS ADD OS_NAME 'Domain Users' </li></ul><ul><li>ALTER ROLE USERS ADD OS_NAME 'DomUser' </li></ul><ul><li>ALTER USER GUEST ADD OS_NAME 'DomUser' </li></ul><ul><li>This example shows how you should NOT setup mapping in your databases! </li></ul>Firebird 3 (plan)‏ Mapping result: current_user = GUEST current_role = USERS <ul><li>Example 2 – windows trusted authentication </li></ul>
  46. 46. <ul><li>Objects list: </li></ul><ul><li>DomUser (1)‏ </li></ul><ul><li>Finance (2)‏ </li></ul><ul><li>Domain Users (2)‏ </li></ul><ul><li>ALTER ROLE “RDB$ADMIN” ADD OS_NAME 'Domain Admins' </li></ul><ul><li>ALTER ROLE CHIEF ADD OS_NAME 'Chief' </li></ul><ul><li>ALTER ROLE FINANCE ADD OS_NAME 'Finance' </li></ul><ul><li>This is real-life example. </li></ul>Firebird 3 (plan)‏ Mapping result: current_user = DomUser current_role = FINANCE <ul><li>Example 2 – windows trusted authentication </li></ul>
  47. 47. Thanks for your attention! www.firebirdsql.org

×