| Summary: | <app-antivirus/clamav-0.98: Multiple vulnerabilities (CVE-2013-{2020,2021}) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | antivirus, net-mail+disabled |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2013/04/27/3 | ||
| Whiteboard: | B2 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 470090, 487414 | ||
| Bug Blocks: | |||
The first two are fixed in 0.97.8. Last one is still locked, no CVE assigned yet. Shall we wait for it to be unlocked and confirm that it's fixed in 0.97.8, or go ahead and stable? CVE-2013-2021 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2021): pdf.c in ClamAV 0.97.1 through 0.97.7 allows remote attackers to cause a denial of service (out-of-bounds-read) via a crafted length value in an encrypted PDF file. CVE-2013-2020 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2020): Integer underflow in the cli_scanpe function in pe.c in ClamAV before 0.97.8 allows remote attackers to cause a denial of service (crash) via a skewed offset larger than the size of the PE section in a UPX packed executable, which triggers an out-of-bounds read. app-antivirus/clamav-0.98 was stabilized. Adding this to existing GLSA draft This issue was resolved and addressed in GLSA 201405-08 at http://security.gentoo.org/glsa/glsa-201405-08.xml by GLSA coordinator Sergey Popov (pinkbyte). |
From ${URL} : The bugs should be public now: https://bugzilla.clamav.net/show_bug.cgi?id=7055 heap corruption, potentially exploitable. https://bugzilla.clamav.net/show_bug.cgi?id=7053 overflow due to PDF key length computation. Potentially exploitable. https://bugzilla.clamav.net/show_bug.cgi?id=7054 NULL pointer dereference in sis parsing. When building clamav I recommend disabling legacy or unneeded features (e.g. sis). I guess that's common sense though. @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not