Bug 704512 (CVE-2011-1782)

Summary: CVE-2011-1782 Gimp: Incomplete fix for CVE-2010-4543 PSP plug-in heap overflow issue
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: nphilipp, security-response-team, tpelka
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-19 21:48:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 537809, 537810, 537811, 703803, 703804, 706939, 833903    
Bug Blocks:    

Description Jan Lieskovsky 2011-05-13 14:01:00 UTC 
Originally Common Vulnerabilities and Exposures assigned an identifier
of CVE-2010-4543 to the following vulnerability:

Heap-based buffer overflow in the read_channel_data function in file-psp.c
in the Paint Shop Pro (PSP) plugin in GIMP 2.6.11 allows remote attackers to
cause a denial of service (application crash) or possibly execute arbitrary
code via a PSP_COMP_RLE (aka RLE compression) image file that begins a long
run count at the end of the image. NOTE: some of these details are obtained
from third party information.

Upstream bug report:
[1] https://bugzilla.gnome.org/show_bug.cgi?id=639203

Original patch proposal from Vincent Untz:
[2] https://bugzilla.gnome.org/show_bug.cgi?id=639203#c12

And final patch applied by Gimp upstream was:
[3] http://git.gnome.org/browse/gimp/commit/?id=48ec15890e1751dede061f6d1f469b6508c13439

Later it was recognized by Nils Philippsen this patch to be incomplete
due the following reasoning:

I've looked at this a bit further and found that even Vincent Untz's patch
didn't take into account that the code that did runlength decoding actually
advances by bytespp through the buffer into which it writes, so the runcount
needs to be clamped to "(endq - q) / bytespp"(*) in order that subsequent loops
don't advance past the end of the buffer.

(*): This division is actually safe as bytespp is set by the plugin to one of
several known values, therefore can't be 0.
Comment 3 Jan Lieskovsky 2011-05-13 14:07:55 UTC 
Proposed patch from Nils Philippsen to address this problem:

diff --git a/plug-ins/common/file-psp.c b/plug-ins/common/file-psp.c
index 7e620fb..9ae5395 100644
--- a/plug-ins/common/file-psp.c
+++ b/plug-ins/common/file-psp.c
@@ -1200,7 +1200,7 @@ read_channel_data (FILE       *f,
             fread (buf, runcount, 1, f);

           /* prevent buffer overflow for bogus data */
-          runcount = MIN (runcount, endq - q);
+          runcount = MIN (runcount, (endq - q) / bytespp);

           if (bytespp == 1)
             {
Comment 6 Jan Lieskovsky 2011-05-13 14:38:04 UTC 
The CVE identifier of CVE-2011-1782 has been assigned to this issue.
Comment 8 Jan Lieskovsky 2011-05-23 14:42:29 UTC 
Created gimp tracking bugs for this issue

Affects: fedora-all [bug 706939]