Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CVE (Critical + High) in bookworm image

1,232 views
Skip to first unread message

thomas

unread,
Nov 22, 2023, 12:30:06 PM11/22/23
to
Hi,

   I am installing  nodejs on top of a debian (bookworm-slim) image for some task. While the intended functionality works fine, the security scan (JFrog Xray) fails with a critical and high issue. I see some fix in sid but since it is development mode (I believe) is there any way we could get a fix in bookworm release or is there any other suggestion.

CVE-2023-45853

 JFrog Severity -High

Components - debian:bookworm:zlib1g:1:1.2.13.dfsg-1

Version 1:1.2.13.dfsg-1

 CVSS Score - 9.8 (v3)

 Summary

A heap buffer overflow in zlib may lead to remote code execution when parsing a malicious archive.

 ==

 CVE-2023-31484

 JFrog Severity - High

Components - debian:bookworm:perl-base:5.36.0-7

Version - 5.36.0-7

CVSS Score -8.1 (v3)

 Summary

Missing TLS check in CPAN.pm allows man-in-the-middle attacks when downloading packages and may lead to code execution.


Thanks,

Thomas

Greg Wooledge

unread,
Nov 22, 2023, 1:00:06 PM11/22/23
to
On Wed, Nov 22, 2023 at 10:39:56PM +0530, thomas wrote:
> is there any way we could get
> a fix in bookworm release or is there any other suggestion.

Whenever the security team releases a fix.

> CVE-2023-45853

https://security-tracker.debian.org/tracker/CVE-2023-45853

"MiniZip in zlib through 1.3 has an integer overflow and resultant
heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long
filename, comment, or extra field. NOTE: MiniZip is not a supported
part of the zlib product."

> JFrog Severity -High

I don't know how that severity level was determined. A buffer overflow
in an unsupported part of the library doesn't sound "High" severity to
me, but hey, what do I know.

> Summary
>
> A heap buffer overflow in zlib may lead to remote code execution when
> parsing a malicious archive.

Here's what I don't immediately understand: what actually triggers
the bug? Does it require some explicit request to access the MiniZip
functionality, or does it just automatically get called if the input
archive is compressed with it?

In other words, if you've got a malicious input file, will something
like "zcat mailicious.minizip" trigger it, or do you have to pass
a "--minizip" flag or something?

If it's the former, then maybe the "High" severity is justified.

> CVE-2023-31484
> Missing TLS check in CPAN.pm allows man-in-the-middle attacks when
> downloading packages and may lead to code execution.

That sounds pretty avoidable. Just don't do that. Do you actually use
CPAN to download and compile perl modules on this system? If not, then
this bug can't possibly affect you.

In order to trigger this, not only would you have to be using CPAN in
that way on your system, but the attacker would *also* have to compromise
either the CPAN file servers, or some part of your TCP/IP connection to
them.

David Wright

unread,
Nov 22, 2023, 2:40:06 PM11/22/23
to
On Wed 22 Nov 2023 at 12:52:17 (-0500), Greg Wooledge wrote:
> On Wed, Nov 22, 2023 at 10:39:56PM +0530, thomas wrote:
> > is there any way we could get
> > a fix in bookworm release or is there any other suggestion.
>
> Whenever the security team releases a fix.
>
> > CVE-2023-45853
>
> https://security-tracker.debian.org/tracker/CVE-2023-45853
>
> "MiniZip in zlib through 1.3 has an integer overflow and resultant
> heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long
> filename, comment, or extra field. NOTE: MiniZip is not a supported
> part of the zlib product."

AFAICT zipOpenNewFileInZip4_64 is only contained in
/usr/lib/x86_64-linux-gnu/libminizip.so.1.0.0 which is from package
libminizip1_1~b1_amd64.deb.

In Debian, it would appear that minizip was split off from zlib1g
a decade ago.

zlib (1:1.2.8.dfsg-2) unstable; urgency=low

* Drop zlib-bin package as minizip has now been packaged separately,
delay due to lack of notice regarding upload (closes: #753070).

-- Mark Brown <bro...@debian.org> Sat, 16 Aug 2014 15:12:11 +0100

Looking at what pulls libminizip1 in, they look like multiplatform
games and graphics programs. I know that, were I to install it,
frescobaldi would pull it in.

> Here's what I don't immediately understand: what actually triggers
> the bug? Does it require some explicit request to access the MiniZip
> functionality, or does it just automatically get called if the input
> archive is compressed with it?
>
> In other words, if you've got a malicious input file, will something
> like "zcat mailicious.minizip" trigger it, or do you have to pass
> a "--minizip" flag or something?

I would guess that an unintentional usage might be if you caused the
unzipping of an archive that looked as if it had been compressed with
PKZIP, or tried to add files to such a file.

Cheers,
David.

Greg Wooledge

unread,
Nov 22, 2023, 3:30:06 PM11/22/23
to
On Wed, Nov 22, 2023 at 01:34:49PM -0600, David Wright wrote:
> AFAICT zipOpenNewFileInZip4_64 is only contained in
> /usr/lib/x86_64-linux-gnu/libminizip.so.1.0.0 which is from package
> libminizip1_1~b1_amd64.deb.
>
> In Debian, it would appear that minizip was split off from zlib1g
> a decade ago.
>
> zlib (1:1.2.8.dfsg-2) unstable; urgency=low
>
> * Drop zlib-bin package as minizip has now been packaged separately,
> delay due to lack of notice regarding upload (closes: #753070).
>
> -- Mark Brown <bro...@debian.org> Sat, 16 Aug 2014 15:12:11 +0100

unicorn:~$ apt-cache show zlib1g
[...]
Source: zlib
[...]
Homepage: http://zlib.net/

unicorn:~$ apt-cache show libminizip1
[...]
Source: minizip (1.1-8)
[...]
Homepage: http://www.winimage.com/zLibDll/minizip.html


Looks like Debian's minizip (including libminizip1) was sourced from a
separate location, rather than being split apart from zlib.

On the other hand, I cannot find zipOpen in
/lib/x86_64-linux-gnu/libz.so.1.2.13 either (I used nm -D ... | less),
so perhaps the minizip portion of zlib is not included during the build.
If that's true, then the package should be marked as "not vulnerable".

David Wright

unread,
Nov 22, 2023, 10:30:06 PM11/22/23
to
On Wed 22 Nov 2023 at 15:27:06 (-0500), Greg Wooledge wrote:
> On Wed, Nov 22, 2023 at 01:34:49PM -0600, David Wright wrote:
> > AFAICT zipOpenNewFileInZip4_64 is only contained in
> > /usr/lib/x86_64-linux-gnu/libminizip.so.1.0.0 which is from package
> > libminizip1_1~b1_amd64.deb.
> >
> > In Debian, it would appear that minizip was split off from zlib1g
> > a decade ago.
> >
> > zlib (1:1.2.8.dfsg-2) unstable; urgency=low
> >
> > * Drop zlib-bin package as minizip has now been packaged separately,
> > delay due to lack of notice regarding upload (closes: #753070).
> >
> > -- Mark Brown <bro...@debian.org> Sat, 16 Aug 2014 15:12:11 +0100
>
> unicorn:~$ apt-cache show zlib1g
> [...]
> Source: zlib
> [...]
> Homepage: http://zlib.net/
>
> unicorn:~$ apt-cache show libminizip1
> [...]
> Source: minizip (1.1-8)
> [...]
> Homepage: http://www.winimage.com/zLibDll/minizip.html
>
>
> Looks like Debian's minizip (including libminizip1) was sourced from a
> separate location, rather than being split apart from zlib.

I think that link gives a misleading impression. Before minizip,
the functionality was in zlib-bin, and the library was (using as
an example zlib-bin-1.2.3.4-minizip, from 2009):

$ strings /tmp/zlib-bin-1.2.3.4-minizip | grep -i zlib
MiniZip 1.01b, demo of zLib + Zip package written by Gilles Vollant
more info at http://www.winimage.com/zLibDll/unzip.html
zip 1.01 Copyright 1998-2004 Gilles Vollant - http://www.winimage.com/zLibDll
$

I think it's all the same old code; this is the latest canonical
source of zlib (1495873 Aug 18 05:08 zlib.tar.gz, which I unpacked
in /tmp) with the same link:

$ head -n 5 /tmp/zlib-1.3/contrib/minizip/zip.c
/* zip.c -- IO on .zip files using zlib
Version 1.1, February 14h, 2010
part of the MiniZip project - ( http://www.winimage.com/zLibDll/minizip.html )

Copyright (C) 1998-2010 Gilles Vollant (minizip) ( http://www.winimage.com/zLibDll/minizip.html )
$

> On the other hand, I cannot find zipOpen in
> /lib/x86_64-linux-gnu/libz.so.1.2.13 either (I used nm -D ... | less),
> so perhaps the minizip portion of zlib is not included during the build.
> If that's true, then the package should be marked as "not vulnerable".

… and libminizip1 should be the one marked:

$ grep -r zipOpenNewFileInZip4_64 /tmp/zlib-1.3/
/tmp/zlib-1.3/contrib/minizip/zip.c:extern int ZEXPORT zipOpenNewFileInZip4_64(zipFile file, const char* filename, const zip_fileinfo* zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.c: return zipOpenNewFileInZip4_64(file, filename, zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.c: return zipOpenNewFileInZip4_64(file, filename, zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.c: return zipOpenNewFileInZip4_64(file, filename, zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.c: return zipOpenNewFileInZip4_64(file, filename, zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.c: return zipOpenNewFileInZip4_64(file, filename, zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.c: return zipOpenNewFileInZip4_64(file, filename, zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.c: return zipOpenNewFileInZip4_64(file, filename, zipfi,
/tmp/zlib-1.3/contrib/minizip/zip.h:extern int ZEXPORT zipOpenNewFileInZip4_64(zipFile file,
/tmp/zlib-1.3/contrib/vstudio/vc10/zlibvc.def: zipOpenNewFileInZip4_64 @135
/tmp/zlib-1.3/contrib/vstudio/vc14/zlibvc.def: zipOpenNewFileInZip4_64 @135
/tmp/zlib-1.3/contrib/vstudio/vc11/zlibvc.def: zipOpenNewFileInZip4_64 @135
/tmp/zlib-1.3/contrib/vstudio/vc9/zlibvc.def: zipOpenNewFileInZip4_64 @135
/tmp/zlib-1.3/contrib/vstudio/vc12/zlibvc.def: zipOpenNewFileInZip4_64 @135
$

Cheers,
David.
0 new messages