Testing x86_64 mga2

Downloaded random.tif from http://code.google.com/p/openjpeg/issues/detail?id=5

which is linked as the upstream ticket from the redhat bug https://bugzilla.redhat.com/show_bug.cgi?id=812317

Before
------
$ image_to_j2k -i random.tif -o random.j2k

[INFO] tile number 1 / 1
[INFO] - tile encoded in 0.857870 s
*** glibc detected *** image_to_j2k: free(): invalid next size (normal): 0x00000000018193a0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x73476)[0x7fb99e6cf476]
/usr/lib64/libopenjpeg.so.1(tcd_free_encode+0x125)[0x7fb99f390e85]
/usr/lib64/libopenjpeg.so.1(j2k_encode+0x1090)[0x7fb99f384ba0]
image_to_j2k(main+0x6a0)[0x403710]
etc.

After
-----
$ image_to_j2k -i random.tif -o random.j2k

[INFO] tile number 1 / 1
[INFO] - tile encoded in 0.858870 s
*** glibc detected *** image_to_j2k: free(): invalid next size (normal): 0x0000000001fdc3a0 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x73476)[0x7f9bd422d476]
/usr/lib64/libopenjpeg.so.1(tcd_free_encode+0x125)[0x7f9bd4eeee85]
/usr/lib64/libopenjpeg.so.1(j2k_encode+0x1090)[0x7f9bd4ee2ba0]
image_to_j2k(main+0x6a0)[0x403710]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7f9bd41db32d]
image_to_j2k[0x403b2d]


So it seems either the CVE is not closed by this update or the crash is unrelated.

Thanks Claire.  I now have the brown paper bag pulled down fully over my head.

I patched the wrong line of code :o(

The patch in the Mageia 1 package is correct.

Mageia 2 and Cauldron packages rebuilding now.

Thanks David.

Wassi found it (user7), I can't take the credit.

Corrected packages uploaded for Mageia 2 and Cauldron.  Updated advisory.

Advisory:
========================

Updated openjpeg packages fix security vulnerability:

An out-of heap-based buffer bounds read and write flaw, leading to
invalid free, was found in the way a tile coder / decoder (TCD)
implementation of OpenJPEG, an open-source JPEG 2000 codec written in
C language, performed releasing of previously allocated memory for the
TCD encoder handle by processing certain Gray16 TIFF images. A remote
attacker could provide a specially-crafted TIFF image file, which once
converted into the JPEG 2000 file format with an application linked
against OpenJPEG (such as 'image_to_j2k'), would lead to that
application crash, or, potentially arbitrary code execution with the
privileges of the user running the application (CVE-2009-5030).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-5030
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/083105.html
========================

Updated packages in core/updates_testing:
========================
libopenjpeg2-1.3-7.1.mga1
libopenjpeg-devel-1.3-7.1.mga1
openjpeg-1.5.0-1.2.mga2
libopenjpeg1-1.5.0-1.2.mga2
libopenjpeg-devel-1.5.0-1.2.mga2

from SRPMS:
openjpeg-1.3-7.1.mga1.src.rpm
openjpeg-1.5.0-1.2.mga2.src.rpm

Confirmed fixed mga2 64

$ image_to_j2k -i random.tif -o random.j2k

[INFO] tile number 1 / 1
[INFO] - tile encoded in 0.862869 s
Generated outfile random.j2k

Hardware: i586 => All
Whiteboard: MGA1TOO => MGA1TOO mga2-64-OK

Testing MGA2, i586.

Testing procedure mostly mirrors Comment 1. The downloaded file was renamed to "attachment.tif" though, as something ate the file extension (the file as I downloaded it was called "attachment". openjpeg will refuse to work on a file without file extension.

Before update:
$ image_to_j2k -i attachment.tif -o testimage.j2k

[INFO] tile number 1 / 1
[INFO] - tile encoded in 1.053840 s
Speicherzugriffsfehler (=segmentation fault)

After update:
$ image_to_j2k -i attachment.tif -o testimage.j2k

[INFO] tile number 1 / 1
[INFO] - tile encoded in 1.063838 s
Generated outfile testimage.j2k

The resulting file can be opened with GIMP, but crashes Krita and can not be opened with neither Gwenview nor Okular (no crashes though). This is not a regression though.

Please note that these results are for openjpeg-1.5.0-1.2.mga2.src.rpm, as openjpeg-1.5.0-1.1.mga2.src.rpm didn't work for me (same result as in Comment 1).

Testing mga1 64

Mageia 1 doesn't have the openjpeg package so the image_to_j2k command can't be used.

Just testing lib64openjpeg2 seems to work ok by opening the random.j2k created on mageia 2 in krita on mageia 1.

$ strace -o strace.out krita random.j2k
$ grep openjpeg strace.out 
open("/usr/lib64/libopenjpeg.so.2", O_RDONLY) = 17

No regression noticed.

Testing mga1 i586.  Only testing for regressions. None found.

Could someone from the sysadmin team push the srpm
openjpeg-1.5.0-1.2.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core updates, and the srpm
openjpeg-1.3-7.1.mga1.src.rpm
from Mageia 1 Core Updates Testing to Core Updates.

Advisory: Updated openjpeg packages fix security vulnerability:

An out-of heap-based buffer bounds read and write flaw, leading to
invalid free, was found in the way a tile coder / decoder (TCD)
implementation of OpenJPEG, an open-source JPEG 2000 codec written in
C language, performed releasing of previously allocated memory for the
TCD encoder handle by processing certain Gray16 TIFF images. A remote
attacker could provide a specially-crafted TIFF image file, which once
converted into the JPEG 2000 file format with an application linked
against OpenJPEG (such as 'image_to_j2k'), would lead to that
application crash, or, potentially arbitrary code execution with the
privileges of the user running the application (CVE-2009-5030).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-5030
http://lists.fedoraproject.org/pipermail/package-announce/2012-June/083105.html

https://bugs.mageia.org/show_bug.cgi?id=6624

Keywords: (none) => validated_update
CC: (none) => davidwhodgins, sysadmin-bugs
Whiteboard: MGA1TOO mga2-64-OK MGA2-32-OK mga1-64-OK => MGA1TOO mga2-64-OK MGA2-32-OK mga1-64-OK mga1-32-OK

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0152

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED