Raphael Geissert discovered multiple heap-based buffer overflows in OpenJPEG. If a specially-crafted image were opened by an application linked against OpenJPEG, it could cause the application to crash or, potentially, execute arbitrary code with the privileges of the user running the application.
Created attachment 831461 [details] proposed patch 1
Created attachment 831462 [details] proposed patch 2
Created attachment 831463 [details] proposed patch 3
Created attachment 831464 [details] proposed patch 4
Created attachment 831465 [details] proposed patch 5
Acknowledgements: Red Hat would like to thank Raphael Geissert for reporting these issues during a review for EDF.
Created openjpeg tracking bugs for this issue: Affects: fedora-all [bug 1038409]
Created mingw-openjpeg tracking bugs for this issue: Affects: fedora-all [bug 1038410]
Created openjpeg tracking bugs for this issue: Affects: epel-5 [bug 1038411]
mingw-openjpeg-1.5.1-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
mingw-openjpeg-1.5.1-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2013:1850 https://rhn.redhat.com/errata/RHSA-2013-1850.html
Looks like proposed patches 3,4 are already applied upstream as part of https://code.google.com/p/openjpeg/issues/detail?id=166 and applied in fedora packaging in openjpeg-1.5-r2033.patch (though the upstream commit version of patch4 does the checking unconditionally, rather than in an else branch)
(and patch 5 too)
openjpeg-1.5.1-13.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
openjpeg-1.5.1-13.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Investigating bug 1317826 uncovered a crash that seems to be introduced by patch 2 in comment #2 above. Commentary in the patch reads: /* Later-on it is assumed that all components are of at least comp0size blocks */ But if the test passes, we fall through to: ...malloc((comp0size+3) * sizeof(int)) which allocates the smaller buffer size (comp0size) rather than the current component's computed size (should be "compcsize"). This causes a crash (visible using ASAN) with issue725.jp2 from https://github.com/uclouvain/openjpeg-data/tree/master/input/nonregression/ Note that upstream has addressed this flaw in openjpeg-1.5.2 with a different patch (hunk starting /* testcase 1336.pdf.asan.74.376 */): https://github.com/uclouvain/openjpeg/commit/69cd4f92 which is used in Fedora/openjpeg-1.5.1: http://pkgs.fedoraproject.org/cgit/rpms/openjpeg.git/tree/openjpeg-1.5.1-CVE-2013-6045.patch This should replace openjpeg-CVE-2014-6045.patch in RHEL.
New bug 1382202 created to track this.