Any plans to address CVE-2023-22899

[danshome]

In the following document (https://breakingthe3ma.app/files/Threema-PST22.pdf), there is the following comment:

“In one of our attacks, we leveraged a vulnerability in a library, Zip4j, used by Threema to create backup zip files. We disclosed our findings to the author of Zip4j on 08.10.2022, proposing a 60-day disclosure period. At the time of writing, the author has yet to acknowledge our email."

Can you please comment on CVE-2023-22899 now that this vulnerability has been made public?

[todb]

The last commit (and issue closed) to this repo was September 12, 2022 (as of this writing). I don't think this software is abandonware.

At this point, it would be helpful of @kennypatterson would share details of the reported MAC vulnerability so that maybe someone else could craft up a fix in a PR.

I am quite curious about its implications in other projects that depend on this project.

[albertus82]

The paper states that:

This library possesses a bug where the MAC is not checked when decrypting the zip file, if certain conditions are met.

So the "issue" could be here:

zip4j/src/main/java/net/lingala/zip4j/io/inputstream/AesCipherInputStream.java

Lines 126 to 135 in 733cb24

	private void verifyContent(byte[] storedMac) throws IOException {
	if (getLocalFileHeader().isDataDescriptorExists()
	&& CompressionMethod.DEFLATE.equals(Zip4jUtil.getCompressionMethod(getLocalFileHeader()))) {
	// Skip content verification in case of Deflate compression and if data descriptor exists.
	// In this case, we do not know the exact size of compressed data before hand and it is possible that we read
	// and pass more than required data into inflater, thereby corrupting the aes mac bytes.
	// See usage of PushBackInputStream in the project for how this push back of data is done
	// Unfortunately, in this case we cannot perform a content verification and have to skip
	return;
	}

CVE finally rated this as:

Base Score: 5.9 MEDIUM

[srikanth-lingala]

I am looking into this issue

[zspitzer]

@srikanth-lingala could you issue a new release with this fix?

[tech-consortium]

@srikanth-lingala When will you be publishing a new release?

[todb-r7]

It's an open source project, so it doesn't actually depend on @srikanth-lingala to do all the work themselves. A little collaboration might help, here. I'm not really much of a Java guy, but there are millions who are.

At any rate, it looks like commit 597b31a is intended to address this, but without a test case (ideally, provided by @kennypatterson or anyone else with details of the vulnerability), it's hard to prove that it actually fixes the issue.

[srikanth-lingala]

Sorry guys. I caught a nasty virus which took me down over the last days. Still recovering, but I should be able to continue with this fix now.

[todb-r7]

CW: CVE pedantry

CVE finally rated this as:

Base Score: 5.9 MEDIUM

Technically, the National Vulnerability Database rated it as 5.9, as part of the CVMap program. The CVE Project does not itself provide ratings.

Individual CVE Numbering Authorities (CNAs) may provide their own estimates of impact/risk/threatiness, and may express those as CVSS scores in their CVE entry definitions. The original definition does not.

[srikanth-lingala]

Issue fixed in v2.11.3 released today