Impact
Connections stored in ExtConnPool are not verified for presence and suitability of CryptCallback interface used when they were created vs actually available currently. Additional problem with vulnerability is that use of inappropriate CryptCallback interface may cause segfault in server process.
To be impacted by this vulnerability one should use ExtConnPool (i.e. set to non-zero parameter ExtConnPoolSize in firebird.conf). Encrypted database, accessed by execute statement on external, may be accessed later by attachment missing a key to that database. In a case when execute statement are chained segfault may happen. What is worse that segfault may take place even for unencrypted databases.
Patches
Currently one can use the following or later snapshots:
- 6.0.0.609
- 5.0.2.1610
- 4.0.6.3183
or point releases:
- 5.0.2
- 4.0.6
Present in them fix for #8429 also fixes this GHSA.
Workarounds
Set
ExtConnPoolSize=0
in firebird.conf. This is default value - i.e. if you never tuned it you are not impacted.
Impact
Connections stored in ExtConnPool are not verified for presence and suitability of CryptCallback interface used when they were created vs actually available currently. Additional problem with vulnerability is that use of inappropriate CryptCallback interface may cause segfault in server process.
To be impacted by this vulnerability one should use ExtConnPool (i.e. set to non-zero parameter ExtConnPoolSize in firebird.conf). Encrypted database, accessed by execute statement on external, may be accessed later by attachment missing a key to that database. In a case when execute statement are chained segfault may happen. What is worse that segfault may take place even for unencrypted databases.
Patches
Currently one can use the following or later snapshots:
or point releases:
Present in them fix for #8429 also fixes this GHSA.
Workarounds
Set
ExtConnPoolSize=0
in firebird.conf. This is default value - i.e. if you never tuned it you are not impacted.