Collection of Recent Reported Bugs for zip4j (2.9.0) #377
Comments
|
Any updates on the issues mentioned? |
|
@ZanderHuang No. I will fix all these in the release after the upcoming one. I am about to release the next version of zip4j. |
|
Hi @srikanth-lingala, I'm the collaborator of @ZanderHuang. Are you willing to help us to request one CVE ID through GitHub Security Advisories for these bugs, which can cause Denial of Service. You can follow this tutorial to manage your bug fixings and alert any downstream dependencies of the issue so they can patch immediately if using the broken release. Thanks for your help! |
|
Why does this github issue have the CVE-2022-24615 (https://nvd.nist.gov/vuln/detail/CVE-2022-24615) assigned to it? these are bugs right, not security issues? |
|
any update for new release? |
|
I had no time to work on zip4j for the last couple of months for personal reasons. I will try to fix them in the next days and will get a release out. @snoopysecurity I don't understand why the reporter of these issues has decided to raise a CVE for those issues either. They are all bugs, but according to the CVE descriptions, these can apparently be used in a denial of service attack. IMO, a CVE for those bugs is not appropriate. And also, on a more selfish note, having a CVE where it is not applicable hurts the reputation of a library, and discourages the developers like me who put in years of effort behind such projects. Don't get me wrong, as an open source enthusiast, I am all for the security of open source projects, but only where appropriate. So, thanks for raising a good point. @ZanderHuang Can you explain why those issues are marked as CVE? |
|
Hi @srikanth-lingala. We totally support your decision for removing the CVE number of these bugs. We've seen CVEs for recording bugs of Java libraries (e.g., CVE-2021-27906(apache/pdfbox), CVE-2022-21366(OpenJDK), CVE-2021-36090(Apache Commons Compress)). These are bugs of type Uncaught Exception/Errors, which causes DoS attacks. We followed their process to handle the found bugs of zip4j. Sorry for the caused inconvenience. |
|
Since I will fix these issues soon anyway, thats fine for me to leave it as it is. |
|
Ah cool i see @Han0nly, that's makes sense, I always assumed these sort of fuzzer findings are not security issues in memory safe languages such as Java, JS, Python etc but I might be wrong, it could be a issue looking at the refs. Worth providing PoCs and looking at bit into the how impactful it is if this is used as a library on a application etc and mentioning with the maintainer about the CVE before applying. Also linking into to the CWE etc might help as well. E.g. CWE-129 could be ArrayIndexOutOfBoundsException etc. Having CVEs for findings should be fine but without enough proof and maintainer ack, it mostly becomes noise for maintainers and users of the project hence I asked. |
|
Hi @srikanth-lingala - What is the rough time estimated to publish the version with the fixes for raised CVE. |
|
@shdb1 I am trying my best to get these issues resolved in the extremely limited free time that I have currently. I will try to get a release out by end of this month (~ 10 days left to go), but I cannot guarantee that though. |
|
Thanks @srikanth-lingala |
|
All issues are now fixed. I will include them in the next release which should be out in a couple of days. |
|
@srikanth-lingala Thank you so much. |
|
@srikanth-lingala Thanks for the fixes. Can you link to the fixing commits for the issues that have CVEs? It would be very helpful to have that 1:1 mapping. |
|
@attritionorg I commit with the issue number in the fix, so github automatically links the issue to the commit. Just open any issue and you will find a commit linked to it that fixed that issue. If there is no commit in the fix, this means that that issue was fixed as part of a different issue already, in which case I usually mention the commit/issue that fixed it. |
|
This issue doesn't link to one and I don't see a commit that references it in the title, is why I asked. |
|
commits are on the child issues... this one here is just a group of the other issues, like an epic. |
|
All issues fixed in v2.10.0 released today |
|
Do you know when they will be in maven central repository!? |
|
@andrecs-br It is already on maven central: https://repo.maven.apache.org/maven2/net/lingala/zip4j/zip4j/2.10.0/ |
|
Awesome! Thank you! |
|
Thanks @srikanth-lingala for releasing version . |
Recently we (Zhang Cen , Huang Wenjie and Zhang Xiaohan) found and submitted several bugs of latest zip4j (2.9.0).
For your convenience, here lists the bug summary for all reported bugs (will keep it updated).
Note that each issue is a unique bug (we sorted and refined them from thousands of crashes)
Any discussion about the bugs are welcome.
net.lingala.zip4j.headers.HeaderReader.readAesExtraDataRecord::HeaderReader.java:675zip4j 2.9.0 #366net.lingala.zip4j.headers.HeaderReader.readAesExtraDataRecord::HeaderReader.java:677zip4j 2.9.0 #367net.lingala.zip4j.util.RawIO.readLongLittleEndian::RawIO.java:59zip4j 2.9.0 #368net.lingala.zip4j.util.RawIO.readShortLittleEndian::RawIO.java:110zip4j 2.9.0 #369net.lingala.zip4j.model.enums.AesVersion.getFromVersionNumber::AesVersion.java:42zip4j 2.9.0 #370net.lingala.zip4j.io.inputstream.ZipEntryInputStream.readUntilBufferIsFull::ZipEntryInputStream.java:78zip4j 2.9.0 #371net.lingala.zip4j.util.Zip4jUtil.readUntilBufferIsFull::Zip4jUtil.java:187zip4j 2.9.0 #372net.lingala.zip4j.io.inputstream.AesCipherInputStream.getSalt::AesCipherInputStream.java:161zip4j 2.9.0 #373net.lingala.zip4j.io.inputstream.ZipInputStream.getEncryptionHeaderSize::ZipInputStream.java:336zip4j 2.9.0 #374net.lingala.zip4j.io.inputstream.ZipInputStream.isEntryDirectory::ZipInputStream.java:314zip4j 2.9.0 #375net.lingala.zip4j.util.Zip4jUtil.getCompressionMethod::Zip4jUtil.java:121zip4j 2.9.0 #376The text was updated successfully, but these errors were encountered: