| pgpool-II 4.6.1 Documentation | |||
|---|---|---|---|
| Prev | Up | Appendix A. Release Notes | Next |
Release Date: 2025-05-15
This release contains a security fix.
An authentication bypass vulnerability exists in the client authentication mechanism of Pgpool-II. In Pgpool-II, authentication may be bypassed even when it is supposed to be enforced. As a result, an attacker could log in as any user, potentially leading to information disclosure, data tampering, or even a complete shutdown of the database. (CVE-2025-46801)
This vulnerability affects systems where the authentication configuration matches one of the following patterns:
Pattern 1: This vulnerability occurs when all of the following conditions are met:
The password authentication method is used in pool_hba.conf
allow_clear_text_frontend_auth = off
The user's password is not set in pool_passwd
The scram-sha-256 or md5 authentication method is used in pg_hba.conf
Pattern 2: This vulnerability occurs when all of the following conditions are met:
enable_pool_hba = off
One of the following authentication methods is used in pg_hba.conf: password, pam, or ldap
Pattern 3: This vulnerability occurs when all of the following conditions are met:
Raw mode is used (backend_clustering_mode = 'raw')
The md5 authentication method is used in pool_hba.conf
allow_clear_text_frontend_auth = off
The user's password is registered in pool_passwd in plain text or AES format
One of the following authentication methods is used in pg_hba.conf: password, pam, or ldap
All versions of Pgpool-II 4.0 and 4.1 series, 4.2.0 to 4.2.21, 4.3.0 to 4.3.14, 4.4.0 to 4.4.11, 4.5.0 to 4.5.6 and 4.6.0 are affected by this vulnerability. It is strongly recommended to upgrade to Pgpool-II 4.6.1, 4.5.7, 4.4.12, 4.3.15 and 4.2.22 or later. Alternatively, you can modify your settings so that they do not match any of the vulnerable configuration patterns.
Add major version information to the configuration file. (Bo Peng)
Fix incorrect client authentication in some cases. (Tatsuo Ishii)
If enable_pool_hba = on, it's auth method is "password", no password is registered in pool_passwd, and auth method in pg_hba.conf is "scram-sha-256" or "md5", for the first time when a client connects to pgpool, authentication is performed as expected. But if a client connects to the cached connection, any password from the client is accepted.
Also if enable_pool_hba = off, in some cases a client is not asked password for the first time, or when a client connects to cached connection, even if it should be.
In addition to fixing above, following changes are made:
Remove single PostgreSQL code path to simplify the authentication code.
Remove crypt authentication support for frontend and backend. The feature had not been documented and never tested. Moreover crypt authentication was removed long time ago in PostgreSQL (8.4, 2009).
Add new regression test "040.client_auth". The test performs exhaustive client authentication tests using a test specification file formatted in CSV.
Fix long standing bind bug with query cache. (Tatsuo Ishii)
When a named statement is prepared, it is possible to bind then execute without a parse message. Problem is, table oids which are necessary to invalidate query cache at execute or COMMIT was collected only in parse messages process (Parse()). Thus if bind is executed without parse after previous execute, no table oids were collected, and pgpool failed to invalidate query cache. Fix is collecting table oids at bind time too. Add regression test to 006.memqcache.
Problem reported by and test program provided by Achilleas Mantzios.
Discussion: [pgpool-general: 9427] Clarification on query results cache visibility
Fix query cache invalidation bug. (Tatsuo Ishii)
When an execute message is received, pgpool checks its max number of rows paramter. If it's not zero, pgpool sets "partial_fetch" flag to instruct pool_handle_query_cache() to not create query cache. Problem is, commit 2a99aa5d1 missed that even INSERT/UPDATE/DELETE sets the execute message parameter to non 0 (mostly 1) and pgpool set the flag for even none SELECTs. This resulted in failing to invalidate query cache because if the flag is true, subsequent code in pool_handle_query_cache() skips cache invalidation. To fix this change Execute() to check if the query is read only SELECT before setting the flag. Also add test to 006.memqcache.
Problem reported by and a test program provided by Achilleas Mantzios.
Discussion: [pgpool-general: 9427] Clarification on query results cache visibility
Fix portability to OpenBSD. (Tatsuo Ishii)
Discussion: [pgpool-hackers: 4582] Make pgpool build on OpenBSD
The patch was created by Martijn van Duren.
Fix json_writer did not properly encode special characters. (Bo Peng)
Pgpool-II would crash when the watchdog was enabled if wd_authkey contained special characters (e.g., a backslash).
The patch was created by Martijn van Duren and slightly modified by Bo Peng.
Fix sr check and health check to reopen pool_passwd upon reload. (Tatsuo Ishii)
The streaming replication check and health check process forgot to reopen pool_passwd upon reload. If sr_check_password or health_check_password is empty string, the password is obtained from pool_passwd. Thus those process read outdated content of pool_passwd upon reload.
Enhance the description on connection_life_time (Tatsuo Ishii)
connection_life_time is a config value to determine the life time of cached connections to PostgreSQL backend. Current document lacks a description that the expiration calculation is actually done at the time when the client disconnects to the process which holds the cached connections.
Discussion: [pgpool-hackers: 4577] Doc: enhance the description on connection_life_time
Enhance the explanation on sr_check_user. (Tatsuo Ishii)
It must be a superuser or in the pg_monitor group.