Seth Arnold reported [1] a number of stack-based buffer overflows in openjpeg: Several incorrect uses of strncpy() with data that may not have a NUL terminating byte within the indicated space, e.g.: * http://code.google.com/p/openjpeg/source/browse/trunk/src/bin/jp3d/opj_jp3d_compress.c#260 * http://code.google.com/p/openjpeg/source/browse/trunk/src/bin/jp3d/opj_jp3d_compress.c#279 Several incorect uses of strcpy() with data that may be longer than expected, e.g.: * http://code.google.com/p/openjpeg/source/browse/trunk/src/bin/jp3d/convert.c#188 * http://code.google.com/p/openjpeg/source/browse/trunk/src/bin/jp3d/convert.c#192 Several incorrect uses of strcat() before accounting for the lengths, e.g.: * http://code.google.com/p/openjpeg/source/browse/trunk/src/lib/openjp3d/event.c#118 * http://code.google.com/p/openjpeg/source/browse/trunk/src/lib/openjp3d/event.c#132 An incorrect use of sprintf() which can overflow a stack-based buffer: * http://code.google.com/p/openjpeg/source/browse/trunk/src/lib/openjp3d/event.c#158 He notes this is not an exhaustive list, but serves as examples. Upstream has, to this point, not responded so there are currently no patches. [1] http://www.openwall.com/lists/oss-security/2013/09/12/2
Acknowledgements: Red Hat would like to thank Seth Arnold for reporting this issue.
This flaw exists in the JP3D image handling code of openjpeg. [Part 10 of JPEG20003 (JP3D), which is concerned with volumetric imaging, aims to provide the same functionality and efficiency for 3D data sets as for its 2D counterparts.] The above code is not present in the version of openjpeg shipped with Red Hat Enterprise Linux 6. Statement: Not vulnerable. This issue does not affect the version of openjpeg as shipped with Red Hat Enterprise Linux 6.
This issue does not affect the version of openjpeg as shipped with Fedora 19 and Fedora 20.
RHEL 7 still carries openjpeg 1.5.1, so this makes this security advisory also valid for that distribution. Could you please make a change in the advisory to reflect that? Thanks!
(In reply to Ender from comment #4) > RHEL 7 still carries openjpeg 1.5.1, so this makes this security advisory > also valid for that distribution. Could you please make a change in the > advisory to reflect that? > > Thanks! We don't ship the affected code, e.g. in openjpeg-1.5.1-10.el7.src.rpm the affected files/code aren't included.