zlib before 1.2.12 allows memory corruption (CVE-2018-25032)

Volker Simonis volker.simonis at gmail.com
Wed Apr 27 07:59:35 UTC 2022


Hi Bernd, Vitaly,

Amazon Corretto [1] also includes the fixes for CVE-2018-25032. This
is our statement:

"Based upon our analysis, OpenJDK/Corretto is not affected by
CVE-2018-25032, because the zlib "memLevel" parameter is not settable
and is fixed at 8, and the usage of the Z_FIXED strategy is prevented.
With these settings there is no way to invoke the issue described in
the CVE and we only include this fix out of an abundance of caution."

You're right that the vulnerability can also be exploited without the
Z_FIXED strategy, but in that case only with memLevel set to "1" (see
[2] for more details).

Given all the currently available information, I don't think there's a
reason to worry because of CVE-2018-25032 in the context of Java.

Best regards,
Volker

[1] https://github.com/corretto/corretto-8/blob/release-8.332.08.1/CHANGELOG.md
[2] https://www.openwall.com/lists/oss-security/2022/03/28/1

On Wed, Apr 27, 2022 at 1:21 AM Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>
> Hello Vitaly,
>
> (Personal answer not affiliated with OpenJDK members)
>
> I had also asked about this before, but there was no answer (which is however not surprising, since it is the policy of OpenJDK and Oracle to not comment on unfixed security issues).
>
> My hope was, that by reporting it before the April update, the (trivial?) zlib update would be merged, but it is still the old version according to the source files. So it depends on build parameters and exploitability of the weakness if you are still in danger (I guess:).
>
> BTW while I can understand to not publish unfixed problems, it does really not do the java users a favor to not comment on generally known/published problems, especially not for 2 quarters.
>
> There is however a ray of light on the horizon, I see CVE-2018-25032 fixed in the Azul April Release  Notes and asume they provide the update out of band. (Probably only for Windows binaries, haven’t analysed them yet)
>
> They state:
> > Our analysis shows that Azul Zulu and OpenJDK are not affected by CVE-2018-25032.
> > In OpenJDK, the Zlib "memLevel" parameter is always set to 8 and can not be changed by a
> > Java code, and the Z_FIXED strategy is permanently disabled. The CVE does not apply to Azul
> > Zulu and OpenJDK with these settings. However, Azul decided to include the corresponding
> > patch to the Zlib library in Azul products just in case someone chooses to use Zlib from Azul
> > Zulu outside of Java applications.
>
> (I am not sure of the analysis is complete I think the z_fixed was not a strict requirement, but I could be wrong.)
>
> Hopefully the vulnerability group will share their finding in a few month.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: security-dev <security-dev-retn at openjdk.java.net> im Auftrag von Vitaly Provodin <vitaly.provodin at jetbrains.com>
> Gesendet: Thursday, April 21, 2022 2:06:57 AM
> An: security-dev at openjdk.java.net <security-dev at openjdk.java.net>; build-dev at openjdk.java.net <build-dev at openjdk.java.net>
> Cc: Vitaly Provodin <vitaly.provodin at jetbrains.com>
> Betreff: zlib before 1.2.12 allows memory corruption (CVE-2018-25032)
>
> Hi all,
>
> Recently we (at JetBrains) were faced with the vulnerability issue CVE-2018-25032 (zlib before 1.2.12 allows memory corruption…)
> It is known that Linux, macOS builds uses system’s zlib but Windows - bundled one (by default).
> On Linux and macOS users can work around the issue by installing proper zlib on their systems.
> Are there any ideas for Windows? - the way building (under Cygwin!) with system zlib looks unworkable in case if Cygwin is not installed on user's machines.
>
> It looks like after implementing https://bugs.openjdk.java.net/browse/JDK-8249963 (which also discussed here https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067868.html) the resolution of such issues can be shifted to users but what can be done now?
>
> Thanks,
> Vitaly


More information about the security-dev mailing list