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 <broo...@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.
