Bug 20559

Assigning to all packagers collectively, since there is no registered maintainer for this package.

CC: (none) => marja11
Assignee: bugsquad => pkg-bugs

CVE-2016-9675 (openjpeg: A heap-based buffer overflow flaw was found in the patch for CVE-2013-6045. A crafted j2k image could cause the application to crash, or potentially execute arbitrary code.) does not affect openjpeg-1.5.2, only openjpeg-1.5.1 with a patch for CVE-2013-6045

CC: (none) => nicolas.salguero

this package is OK on cauldron then ?

CC: (none) => mageia

(In reply to Nicolas Lécureuil from comment #3)
> this package is OK on cauldron then ?

Only regarding CVE-2016-9675.  It is affected by the other CVEs.

Suggested advisory:
========================

The updated packages fix security vulnerabilities:

Multiple integer overflows in the opj_tcd_init_tile function in tcd.c in OpenJPEG, as used in PDFium in Google Chrome before 52.0.2743.116, allow remote attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact via crafted JPEG 2000 data. (CVE-2016-5139)

Multiple integer overflows in the opj_tcd_init_tile function in tcd.c in OpenJPEG, as used in PDFium in Google Chrome before 53.0.2785.89 on Windows and OS X and before 53.0.2785.92 on Linux, allow remote attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact via crafted JPEG 2000 data. (CVE-2016-5158)

Multiple integer overflows in OpenJPEG, as used in PDFium in Google Chrome before 53.0.2785.89 on Windows and OS X and before 53.0.2785.92 on Linux, allow remote attackers to cause a denial of service (heap-based buffer overflow) or possibly have unspecified other impact via crafted JPEG 2000 data that is mishandled during opj_aligned_malloc calls in dwt.c and t1.c. (CVE-2016-5159)

Integer overflow in the opj_pi_create_decode function in pi.c in OpenJPEG allows remote attackers to execute arbitrary code via a crafted JP2 file, which triggers an out-of-bounds read or write. (CVE-2016-7163)

An out-of-bounds read vulnerability was found in OpenJPEG, in the j2k_to_image tool. Converting a specially crafted JPEG2000 file to another format could cause the application to crash or, potentially, disclose some data from the heap. (CVE-2016-9573)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5139
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5158
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5159
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7163
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9573
========================

Updated packages in core/updates_testing:
========================
openjpeg-1.5.2-5.2.mga5
lib(64)openjpeg5-1.5.2-5.2.mga5
lib(64)openjpeg-devel-1.5.2-5.2.mga5

from SRPMS:
openjpeg-1.5.2-5.2.mga5.src.rpm

Version: Cauldron => 5
Status: NEW => ASSIGNED
Whiteboard: MGA5TOO => (none)
Assignee: pkg-bugs => qa-bugs

MGA5-32 on Asus A6000VM Xfce
No installation issues.
Took two tif files to test - scans from original 35mm slides
$ image_to_j2k -i bermuda0001.tiff -o berm1.j2k

_TIFFVSetField: bermuda0001.tiff: Invalid tag "Predictor" (not supported by codec).
_TIFFVSetField: bermuda0001.tiff: Invalid tag "BadFaxLines" (not supported by codec).
[INFO] tile number 1 / 1
[INFO] - tile encoded in 7.431000 s
Generated outfile berm1.j2k
and
$ image_to_j2k -i laatstefoto.jpeg -o la.j2k   
!! Unrecognized format for infile : laatstefoto.jpeg [accept only *.pnm, *.pgm, *.ppm, *.pgx, *png, *.bmp, *.tif, *.raw or *.tga] !!

[tester5@mach6 Afbeeldingen]$ image_to_j2k -i 20031111Ieper0001.tiff -o ieper.j2k

[INFO] tile number 1 / 1
[INFO] - tile encoded in 8.166000 s
Generated outfile ieper.j2k
Both j2k files display correctly in GIMP, but not in ristretto "Could not allocate memory"
Reverting j2k back to tif
$ j2k_to_image -i berm1.j2k -o berm1.tif

[INFO] tile 1 of 1
[INFO] - tiers-1 took 5.199000 s
[INFO] - dwt took 1.174000 s
[INFO] - tile decoded in 6.680000 s
Generated Outfile berm1.tif
and
$ j2k_to_image -i ieper.j2k -o ieper.tif

[INFO] tile 1 of 1
[INFO] - tiers-1 took 5.789000 s
[INFO] - dwt took 0.995000 s
[INFO] - tile decoded in 7.145000 s
Generated Outfile ieper.tif
Both tif files display correctly in GIMP and ristretto. Both files are larger than the original tif's.
dumping j2k:
$ j2k_dump -i berm1.j2k 

[INFO] tile 1 of 1
[INFO] - tiers-1 took 5.193000 s
[INFO] - dwt took 1.210000 s
[INFO] - tile decoded in 6.708000 s
image {
  x0=0, y0=0, x1=3008, y1=2037
  numcomps=4
  comp 0 {
    dx=1, dy=1
    prec=8
    sgnd=0
  }
  comp 1 {
    dx=1, dy=1
    prec=8
    sgnd=0
  }
and a lot more
Apart from the ristretto problem (might be ristretto's?) this is OK for me.

Whiteboard: (none) => MGA5-32-OK
CC: (none) => herman.viaene

Mageia 5 x86_64 testing ok.
$ image_to_j2k -i /usr/share/printconf/tests/netpbm.test-image.tiff -o test.j2k

[INFO] tile number 1 / 1
[INFO] - tile encoded in 0.021000 s
Generated outfile test.j2k

$ j2k_dump -i test.j2k|head -n 5

[INFO] tile 1 of 1
[INFO] - tiers-1 took 0.012000 s
[INFO] - dwt took 0.004000 s
[INFO] - tile decoded in 0.017000 s
image {

Advisory committed to svn. Validating the update.

Keywords: (none) => validated_update
Whiteboard: MGA5-32-OK => MGA5-32-OK advisory MGA6-64-OK
CC: (none) => davidwhodgins, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0122.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED