Bugzilla – Bug 1106539
VUL-0: CVE-2018-10936: postgresql-jdbc: PostgreSQL: Postgres JDBC driver does not perform hostname validation by default
Last modified: 2024-05-09 12:10:18 UTC
rh#1622225 # 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/ References: https://bugzilla.redhat.com/show_bug.cgi?id=1622225 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-10936
Upstream fix: https://github.com/pgjdbc/pgjdbc/commit/cdeeaca47dc3bc6f727c79a582c9e4123099526e
Statement from SUSE Security team: Differing from the original description, the vulnerability only affects code that passes a non-default SSLFactory. The default SSLFactory is not affected. "Default sslfactory (which is LibPQFactory) is not impacted." SUSE is not aware of an instance where this is used in this insecure in SUSE code (SUMA). Users developing using this library should verify that this is the case in their application. We will not be issuing an update which would change the API semantics.
Adding the nominal Factory maintainer to CC. Darin... can you please bump to 42.2.5 or later?
Andreas, I can only bump it with a tetra package given the build of newer versions is based on Maven. Last time I had heard this is not OK in SLE or openSUSE, so unless the decision is reversed I can't really help there.
So are you saying that the code is neither secure nor enterprise ready? Does that not imply the package should be dropped?
(In reply to Andreas Stieger from comment #10) > So are you saying that the code is neither secure nor enterprise ready? Does > that not imply the package should be dropped? I am only saying that since long time the upstream project switched to a build system, Maven, that we currently do not support well in SLES/openSUSE. Building a modern Maven-based piece of software in SUSE OSs either requires a huge effort or a compromise in how we package it. In the context of the SUSE Manager project, where most of Maven-built Java software is used, we found an acceptable compromise with the tetra tool, so we are able to keep our libraries reasonably up-to-date and respond to security incidents quickly. Unfortunately that compromise was not deemed adequate for SLES and openSUSE (at least AFAIK). The end result is that bumping the version in a case such as this requires a big development effort (at least rewriting the whole build script) and presently I can't see how we could possibly help with that. Dropping the package from SLES and keeping an updated version for SUSE Manager only is a perfectly OK long-term solution FMPOV, although I would of course hope we found an official way to build Maven-based software in general in our distros. Hope this clarifies
(In reply to Silvio Moioli from comment #11) > (In reply to Andreas Stieger from comment #10) > > So are you saying that the code is neither secure nor enterprise ready? Does > > that not imply the package should be dropped? > > I am only saying that since long time the upstream project switched to a > build system, Maven, that we currently do not support well in SLES/openSUSE. > > Building a modern Maven-based piece of software in SUSE OSs either requires > a huge effort or a compromise in how we package it. > > In the context of the SUSE Manager project, where most of Maven-built Java > software is used, we found an acceptable compromise with the tetra tool, so > we are able to keep our libraries reasonably up-to-date and respond to > security incidents quickly. > > Unfortunately that compromise was not deemed adequate for SLES and openSUSE > (at least AFAIK). The end result is that bumping the version in a case such > as this requires a big development effort (at least rewriting the whole > build script) and presently I can't see how we could possibly help with that. > > Dropping the package from SLES and keeping an updated version for SUSE > Manager only is a perfectly OK long-term solution FMPOV, although I would of > course hope we found an official way to build Maven-based software in > general in our distros. > > Hope this clarifies FWIW I'd move ahead with a tetra build to update this package to the latest release and "let the chips fall" when submitted to the project. People are using tetra for a bunch packages in security:logging and I know they desire to SR some of those package to Factory. Personally, I'd adopt the Fedora standard given the amount of effort they've invested into package Java.
Package update to 42.2.5 is in progress and I'm hoping to SR today.