PostgreSQL Gets a Fix for a Passwordless Authentication Flaw
Newly released versions of the PostgreSQL object-relational database system fix three security vulnerabilities and over 50 other bugs. Two of the flaws could allow attackers to access accounts and information.
The updates were released for all supported branches and are 9.6.4, 9.5.8, 9.4.13, 9.3.18, and 9.2.22. However, it’s worth noting that the 9.2.x branch will reach end-of-support in September, so it’s best for users of that version to start upgrading their PostgreSQL deployments to a newer release.
The PostgreSQL developers added additional restrictions for password-based authentication to prevent potentially insecure database deployments. That’s because one of the flaws, tracked as CVE-2017-7546 in the Common Vulnerabilities and Exposures (CVE) catalog, stems from a possible misinterpretation of libpq library’s behavior by database server administrators.
The libpq library provides a programming interface that is used by many client programs to query backend PostgreSQL servers. The library refuses to authenticate users if a blank password is provided and will not even forward such requests to the server.
This behavior could be interpreted by database admins to mean that setting an empty password for an account disables password-based authentication for that user, the PostgreSQL developers said in the release notes.
That’s not the case and some authentication methods, including the widely used md5, do work with empty strings as passwords when passed to a server by a non-libpq based client. That’s why in the new release the server behavior has been changed to reject blank passwords from being submitted with any of the supported authentication methods and even block attempts to set empty passwords for accounts in the first place.
The new updates also address a second authentication-related security issue tracked as CVE-2017-7547, which is related to an older vulnerability that hasn’t been properly fixed. The flaw is related to the pg_user_mappings feature and could lead to sensitive information disclosure.
“Before this fix, a user had access to see the options in pg_user_mappings even if the user did not have the USAGE permission on the associated foreign server,” the PostgreSQL developers said. “This meant that a user could see details such as a password that might have been set by the server administrator rather than the user.”
The problem is that the patch for this issue only prevents the problem for appearing for newly created clusters. Addressing the problem on existing databases requires manually running a series of commands and restarting the servers.
A third vulnerability, CVE-2017-7548, that was patched in these updates stems from a missing permission check for the lo_put() function that could allow any user to change data in a large object. The function was changed and will now check for UPDATE privileges on the targeted object.
Feature image via Pexels.