# The Postgres JDBC driver does not perform hostname validation by default ## Vulnerability * Product : PostgreSQL * Component : client / JDBC Driver (Tested version: org.postgresql:postgresql:jar:42.2.4) * Common Weakness : 297 (Improper Validation of Certificate with Host Mismatch) The PostgreSQL JDBC driver (org.postgresql:postgresql) does not perform hostname validation by default. => This means that SSL certificates of other hosts are blindly accepted as long as they are trusted. To exploit this vulnerability an attacker has to perform a man-in-the-middle (MITM) attack between a Java application using the JDBC driver and the PostgreSQL server it's connecting to. => TLS normally protects users and systems against MITM attacks, it cannot if certificates from other trusted hosts are accepted by the client. This is especially dangerous if users connect to their database via public networks (e.g. Internet). References: https://www.postgresql.org/about/news/1883/
Acknowledgments: Name: the PostgreSQL project
Upstream down-rated the severity of this issue on making it public. The default configuration in fact would validate host names, but it was possible to provide an SSLFactory that would not. In 42.2.5, the documentation and API has been improved for clarity to avoid this mistake.
External References: https://www.postgresql.org/about/news/1883/
Tower does not use any java stuff or any JDBC driver at all.
CloudForms does not use java (it isn't even installed in the appliance), hence it is not affected.
Created postgresql-jdbc tracking bugs for this issue: Affects: fedora-all [bug 1664337]
Upstream patch: https://github.com/pgjdbc/pgjdbc/commit/cdeeaca47dc3bc6f727c79a582c9e4123099526e
Mitigation: Applications using postgresql-jdbc should have their SSL configuration reviewed to ensure that host name verification is not disabled and only trusted CAs are accepted. This vulnerability only impacts usage of postgresql-jdbc with a non-default SSL Factory, provided by the `sslfactory` parameter. If this parameter is not given, the default LibPQFactory is used, which is not vulnerable.