Bug 17536 - openjpeg2 new security issues CVE-2016-192[34], CVE-2016-318[1-3], CVE-2016-479[67], CVE-2016-5157, and CVE-2016-7163
Summary: openjpeg2 new security issues CVE-2016-192[34], CVE-2016-318[1-3], CVE-2016-4...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/694625/
Whiteboard: MGA5-64-OK MGA5-32-OK advisory
Keywords: validated_update
Depends on: 19010
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-19 18:42 CET by David Walser
Modified: 2016-12-08 20:14 CET (History)
8 users (show)

See Also:
Source RPM: openjpeg2-2.1.0-3.2.mga5.src.rpm
CVE:
Status comment:


Attachments
Post-update diagnostics for PoC jp2 images (1.77 KB, text/plain)
2016-07-22 10:12 CEST, Len Lawrence
Details

Description David Walser 2016-01-19 18:42:10 CET
Two CVEs have been assigned for security issues reported in openjpeg2:
http://openwall.com/lists/oss-security/2016/01/18/7

openjpeg 1.5.2 does not contain the affected functions.

Reproducible: 

Steps to Reproduce:
David Walser 2016-01-19 18:42:17 CET

Whiteboard: (none) => MGA5TOO

Comment 1 Samuel Verschelde 2016-02-23 14:26:07 CET
Assigning to packagers collectively with the registered maintainer in CC. If working on it, please assign the bug report to yourself.

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

Comment 2 David Walser 2016-03-16 23:04:31 CET
CVEs have been assigned for three more issues in openjpeg2:
http://openwall.com/lists/oss-security/2016/03/16/15
http://openwall.com/lists/oss-security/2016/03/16/16
http://openwall.com/lists/oss-security/2016/03/16/17

Summary: openjpeg2 new security issues CVE-2016-1923 and CVE-2016-1924 => openjpeg2 new security issues CVE-2016-192[34] and CVE-2016-318[1-3]

Comment 3 David Walser 2016-05-12 16:17:45 CEST
CVE request for three more issues (one may be a duplicate of CVE-2016-1924):
http://openwall.com/lists/oss-security/2016/05/12/1
Comment 4 David Walser 2016-05-13 18:19:55 CEST
(In reply to David Walser from comment #3)
> CVE request for three more issues (one may be a duplicate of CVE-2016-1924):
> http://openwall.com/lists/oss-security/2016/05/12/1

CVE-2016-4796 and CVE-2016-4797 assigned:
http://openwall.com/lists/oss-security/2016/05/13/2

Summary: openjpeg2 new security issues CVE-2016-192[34] and CVE-2016-318[1-3] => openjpeg2 new security issues CVE-2016-192[34], CVE-2016-318[1-3], and CVE-2016-479[67]

Comment 5 David Walser 2016-07-15 22:59:09 CEST
Fedora has issued an advisory for CVE-2016-318[1-3], and CVE-2016-479[67] on July 14:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/HPMDEUIMHTLKMHELDL4F4HZ7X4Y34JEB/

URL: (none) => http://lwn.net/Vulnerabilities/694625/

Comment 6 David Walser 2016-07-20 15:12:19 CEST
Updated packages uploaded for Mageia 5 and Cauldron.

Advisory to come later.

Updated packages in core/updates_testing:
========================
openjpeg2-2.1.1-1.mga5
libopenjp2_7-2.1.1-1.mga5
libopenjpeg2-devel-2.1.1-1.mga5

from openjpeg2-2.1.1-1.mga5.src.rpm

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

Comment 7 David Walser 2016-07-20 15:14:16 CEST
ChangeLog for 2.1.1:
https://github.com/uclouvain/openjpeg/blob/master/CHANGELOG.md

QA team, please test the reproducers for CVE-2016-192[34]:
http://seclists.org/oss-sec/2016/q1/128

I saw the fix for CVE-2016-1924 was included in 2.1.1, so that should be fixed.  CVE-2016-1923 affects opj_j2k_update_image_data(), which had two security fixes in 2.1.1, but I'm not sure if either corresponds to this CVE.
Comment 8 Len Lawrence 2016-07-21 19:57:40 CEST
Tried to install the packages before update on x86_64:
openjpeg2 installed cleanly
lib64openjp2_7 was already installed
$ sudo urpmi lib64openjpeg2-devel
installing lib64openjpeg2-devel-2.1.0-3.2.mga5.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     #############################################
Installation failed:	file /usr/include/openjpeg.h from install of lib64openjpeg2-devel-2.1.0-3.2.mga5.x86_64 conflicts with file from package lib64openjpeg-devel-1:1.5.2-5.mga5.x86_64
Removing the last named took 8 other packages with it, all devel packages including poppler and ffmpeg.
The lib64openjpeg2-devel package installed fine after that.

Obtained the PoC package from the link in comment 7 but it not immediately obvious how to connect the .jp2 files with openjpeg2.
$ file poc.jp2
poc.jp2: JPEG 2000 Part 1 (JP2)

CC: (none) => tarazed25

Comment 9 Len Lawrence 2016-07-21 20:36:34 CEST
$ urpmq --whatrequires lib64openjp2_7 | sort | uniq
imagemagick
lib64openjp2_7
lib64openjpeg2-devel
mupdf
openjpeg2

$ identify poc.jp2
poc.jp2 JP2 7x8 7x8+0+0 8-bit YUV 551B 0.000u 0:00.000
$ display poc.jp2
WARNING in tgt_create tree->numnodes == 0, no tree created.
WARNING: No incltree created.
WARNING in tgt_create tree->numnodes == 0, no tree created.
WARNING: No imsbtree created.
........
Ctrl-C to exit from this.

The accompanying info.txt file shows the expected response when run through the address sanitizer, altogether different.

Discovered three utilities for handling the openjpeg2 codec:
opj_compres
opj_decompress
opj_dump

$ opj_dump -i poc.jp2
This generates a description of the whole operation and finds no errors for either the part 1 or part 2 images.

The story is the same after the updates so there must be something I am missing here.  Maybe not using the correct tool?
Comment 10 David Walser 2016-07-21 20:39:57 CEST
imagemagick sounds reasonable.  The PoC's for Comment 2 showed them using opj_decompress from the openjpeg2 package.
Comment 11 Len Lawrence 2016-07-22 10:12:03 CEST
Created attachment 8221 [details]
Post-update diagnostics for PoC jp2 images

opj_decompress used on the stage 1 and stage 2 poc.jp2 images
Comment 12 Len Lawrence 2016-07-22 10:34:52 CEST
Stage 1 and Stage 2 refer to CVEs 1923 and 1924.
Current tests do not show the same text as the info.txt files.
$ tree openjpeg
openjpeg
âââ 1
â   âââ info.txt
â   âââ poc.jp2
â   âââ poc.pgm
âââ 2
â   âââ info.txt
â   âââ poc.jp2
âââ openjpeg2.report
Going back to comment 2, it would be good to have the specially crafted images used on the three CVEs but there does not seem to be any link to them.
Comment 13 David Walser 2016-07-22 12:47:40 CEST
Pascal said this may have broken building ghostscript and mupdf, so we'll need to look into that too:
https://ml.mageia.org/l/arc/dev/2016-07/msg00486.html
David Walser 2016-07-22 21:29:33 CEST

Depends on: (none) => 19010

Comment 14 David Walser 2016-07-22 21:31:23 CEST
(In reply to David Walser from comment #13)
> Pascal said this may have broken building ghostscript and mupdf, so we'll
> need to look into that too:
> https://ml.mageia.org/l/arc/dev/2016-07/msg00486.html

Fixed by Rémi.  Fixed mupdf included in the security update in Bug 19010.  I'll add the fixed ghostscript to this bug.

Updated packages in core/updates_testing:
========================
openjpeg2-2.1.1-1.mga5
libopenjp2_7-2.1.1-1.mga5
libopenjpeg2-devel-2.1.1-1.mga5
ghostscript-9.14-3.2.mga5
ghostscript-dvipdf-9.14-3.2.mga5
ghostscript-common-9.14-3.2.mga5
ghostscript-X-9.14-3.2.mga5
ghostscript-module-X-9.14-3.2.mga5
libgs9-9.14-3.2.mga5
libgs-devel-9.14-3.2.mga5
libijs1-0.35-107.2.mga5
libijs-devel-0.35-107.2.mga5
ghostscript-doc-9.14-3.2.mga5

from SRPMS:
openjpeg2-2.1.1-1.mga5.src.rpm
ghostscript-9.14-3.2.mga5.src.rpm
Comment 15 David Walser 2016-07-24 00:48:06 CEST
Len, as far as those two PoC's, I guess you need to use AddressSanitizer to get the same output they did.  Just opj_decompress by itself gives me the same results you got.  I would like an AS test to see if those two are fixed (for purposes of the advisory).

Another possible test for this package would be opening a PDF file with an openjpeg2 image in it with mupdf.  Speaking of which, mupdf has a pending update in updates_testing.
Comment 16 Len Lawrence 2016-07-24 20:12:03 CEST
AS: Mageia has libasan1 but that is a runtime library.
$ urpmq --whatrequires libasan1
libasan-devel
libasan1
Comment 17 Len Lawrence 2016-07-24 20:44:10 CEST
Created a PDF with gscan2pdf.  There was a problem with the .jp2 extension so the file had to be renamed (actually made a copy):
$ cp piuva.jp2 piuvajp2.jpg
ImageMagick failed to convert to pdf.  An empty pdf file was created.
gscan2pdf worked fine.
Installed mupdf.  The executable is called mupdf-x11.  That displayed the document perfectly.

Do you think this is enough David?
Comment 18 Len Lawrence 2016-07-24 20:53:09 CEST
Some confirmations; 
$ file piuvajp2.jpg
piuvajp2.jpg: JPEG 2000 Part 1 (JP2)
$ identify piuvajp2.jpg
piuvajp2.jpg JP2 320x340 320x340+0+0 8-bit sRGB 156KB 0.000u 0:00.000
Output from gscan2pdf was testjp2.pdf which opened in xpdf as well and could be displayed by ImageMagick.
Alexander Sirris 2016-08-11 21:35:50 CEST

CC: (none) => alexandersirris

Alexander Sirris 2016-08-11 21:39:21 CEST

Status: NEW => ASSIGNED

Comment 19 Dave Hodgins 2016-09-07 03:44:18 CEST
Still need an advisory for this update

CC: (none) => davidwhodgins

Comment 20 David Walser 2016-09-07 03:48:20 CEST
Advisory is still pending confirmation from QA as to whether CVE-2016-192[34] are fixed by this update (see Comment 7).
Comment 21 Len Lawrence 2016-09-07 17:16:35 CEST
x86_64

Downloaded the PoC anew and unzipped it.

Could not find anything like asan on the system.  Looks like ASAN is a wrapper for whatever command is run, like strace.

Before update, in directories 1 and 2, without the address sanitizer:

1]$ opj_decompress -i poc.jp2 -o poc.pgm

[INFO] Start to read j2k main header (141).

WARNING in tgt_create tree->numnodes == 0, no tree created.
WARNING: No imsbtree created.
[INFO] Header of tile 0 / 14 has been read.
[INFO] Tile 1/15 has been decoded.
[INFO] Image data has been updated with tile 1.
......
[INFO] Stream reached its end !
WARNING -> [PGM file] Only the first component
           is written to the file
[INFO] Generated Outfile poc.pgm

poc.pgm displayed OK using ImageMagick.

2]$ opj_decompress -i poc.jp2 -o poc.pgm
.....................
WARNING in tgt_create tree->numnodes == 0, no tree created.
WARNING: No imsbtree created.
[INFO] Header of tile 0 / 0 has been read.
[ERROR] Stream too short, expected SOT
[ERROR] Failed to decode tile 1/1
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> opj_decompress: failed to decode image!

Updated all the packages.
Repeated the tests.
1] Lots of warnings again but the PGM image file was created.
2] Tail of messages looked the same as before:
[INFO] Header of tile 1 / 1 has been read.
[ERROR] Invalid precinct
[ERROR] Failed to decode.
[ERROR] Failed to decode tile 1/1
[ERROR] Failed to decode the codestream in the JP2 file
ERROR -> opj_decompress: failed to decode image!

No output image, so it looks like the input image cannot be tested properly without this
address sanitizer which is supposed to detect a SEGV fault and then abort.

I shall move on to PDF conversion to round this off.
Comment 22 Len Lawrence 2016-09-07 17:39:04 CEST
All these tests are what I did before but have moved to another machine because I don't know if I am still dealing with the same update.  It was so long ago.

Used gscan2pdf to embed a jp2 image in a PDF document and viewed the result using mupdf-x11.  Looked OK.

Concluding that for the requirement of the advisory this is still unsatisfactory.

Off to chase ASAN across the internet.
Comment 23 Len Lawrence 2016-09-07 18:13:15 CEST
I installed libasan-devel and libasan1 but could not find any kind of standalone tool to test an application.

A clang tool called ASAN is mentioned on the net but that definitely requires a rebuild.
A quote:
"Address Sanitizer (Asan from here on) was originally developed as part of the clang project, and largely by folks at Google. They took a different approach: while valgrind emulates the machine at run-time, Asan works by instrumenting the code at compile-time."
A later quote indicates that gcc comes with Asan support.

Giving up on this.
Comment 24 David Walser 2016-09-08 15:14:18 CEST
Two more issues that I might need to add patches for...

CVE-2016-5157:
http://www.openwall.com/lists/oss-security/2016/09/08/5

CVE-2016-7163:
http://www.openwall.com/lists/oss-security/2016/09/08/6

Whiteboard: (none) => feedback

Comment 25 David Walser 2016-09-08 22:38:09 CEST
To get the sources locally...

First install the mgarepo and bm packages.

To download the sources from *before* this update, do:
mgarepo co -d 5 -r 907477 openjpeg2

To download the current updated sources, do (in a different directory):
mgarepo co -d 5 openjpeg2

It looks like the ASAN thing might only need -fsanitize=address added to the CFLAGS.

The way you would do that, is edit the file SPECS/openjpeg2.spec, and add a new line after %build (and before %cmake) that says:
export CFLAGS="%{optflags} -fsanitize=address"

If any of the code is in C++, you may need to do another line with the same but with CXXFLAGS instead.

If this requires changing the compiler to clang, I think this will do it:
export CC=clang

(obviously you'd have to install clang for that).

Then to build it, first do:
bm -ls

Then (as root): urpmi SRPMS/openjpeg2*.rpm

Then (as your regular user again):
bm -l

which will build the package and it will tell you where the built packages are placed when it's done (will be in RPMS/i586 or RPMS/x86_64), which you can install (probably with rpm -Uvh --force).

Also, you can look at the build log (SPECS/log.openjpeg2) to make sure you see it using your fsanitize compiler flag as it's building.

Once you are done with all of this, as root you can do "urpme --auto-orphans" to remove those build requirements you installed earlier.

Note that you also might be able to test without installing the RPMS you built, but it would require setting LD_LIBRARY_PATH to include whatever directory under BUILD contains the library(^Hies) you just built.
Comment 26 Len Lawrence 2016-09-09 01:40:18 CEST
Thanks David.  As I said, dev skills...
Shall try to get onto this sometime tomorrow.
Comment 27 Len Lawrence 2016-09-09 11:40:06 CEST
A bit of a problem with authentication:

[lcl@vega before]$ mgarepo co -d 5 -r 907477 openjpeg2
Warning: Permanently added 'svn.mageia.org,212.85.158.153' (RSA) to the list of known hosts.
Permission denied (publickey,password,keyboard-interactive).
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://svn.mageia.org/svn/packages/updates/5/openjpeg2/current'
svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly

It seems ssh-agent or ForwardAgent are not setup or your username is wrong. See https://wiki.mageia.org/en/Packagers_ssh for more information.
[lcl@vega before]$ sudo mgarepo co -d 5 -r 907477 openjpeg2
Warning: Permanently added 'svn.mageia.org,212.85.158.153' (RSA) to the list of known hosts.
Permission denied (publickey,password,keyboard-interactive).
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://svn.mageia.org/svn/packages/updates/5/openjpeg2/current'
svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly

It seems ssh-agent or ForwardAgent are not setup or your username is wrong. See https://wiki.mageia.org/en/Packagers_ssh for more information.

Looks like I would have to become a packager for this to succeed which is a whole different kettle of fish.  The wiki implies that I would need proper credentials including a published public ssh key.  :((
Comment 28 David Walser 2016-09-09 13:57:00 CEST
No Len, it shouldn't be using svn+ssh, that's only for packagers.

See /etc/mgarepo.conf.

## uncomment it in case you don't have a account in the Mageia build system:
#mirror = svn://svn.mageia.org/svn/packages/

Uncomment that second line and it should use svn:// which is anonymous.

(Or you can copy /etc/mgarepo.conf to ~/.mgarepo/config and edit that one)
Comment 29 David Walser 2016-09-09 20:43:29 CEST
CVE-2016-5157 and CVE-2016-7163 patches added.

Updated packages in core/updates_testing:
========================
openjpeg2-2.1.1-1.1.mga5
libopenjp2_7-2.1.1-1.1.mga5
libopenjpeg2-devel-2.1.1-1.1.mga5

from openjpeg2-2.1.1-1.1.mga5.src.rpm

Summary: openjpeg2 new security issues CVE-2016-192[34], CVE-2016-318[1-3], and CVE-2016-479[67] => openjpeg2 new security issues CVE-2016-192[34], CVE-2016-318[1-3], CVE-2016-479[67], CVE-2016-5157, and CVE-2016-7163
Whiteboard: feedback => (none)

Comment 30 Len Lawrence 2016-09-10 01:09:58 CEST
That all seemed to go well until the final build which failed;

from the log: /bin/ld: cannot find -lasan 
which seems to indicate that it is looking for libasan as opposed to libasan1.
$ urpmq -f libasan1
libasan1-4.9.2-4.mga5.x86_64|libasan1-4.9.2-4.1.mga5.x86_64
$ sudo urpmi libasan1
Package libasan1-4.9.2-4.1.mga5.x86_64 is already installed

$ cat log.openjpeg2 | grep fsanitize
+ export 'CFLAGS=-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -fsanitize=address'
+ CFLAGS='-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -fsanitize=address'
+ CFLAGS='-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -fsanitize=address'
  -fsanitize=address -o
  -fsanitize=address -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1

I even tinkered with the SPEC file by adding libasan1 to BUILDREQUIRES, to no avail.  (I don't actually know what BUILDREQUIRES does)

$ cd /usr/lib64$ ls *asan*
libasan_preinit.o  libasan.so.1@  libasan.so.1.0.0*

So the library is correctly named.  Why doesn't ld find it?

openjpeg2/BUILD/openjpeg-2.1.0/build/CMakeFiles/CMakeOutput.log:

The system is: Linux - 4.4.16-desktop-1.mga5 - x86_64
Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded.
Compiler: /bin/cc 
Build flags: -O2;-g;-pipe;-Wformat;-Werror=format-security;-Wp,-D_FORTIFY_SOURCE=2;-fstack-protector;--param=ssp-buffer-size=4;-fPIC;-fsanitize=address
Id flags: -c

The output was:
0


Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.o"

The C compiler identification is GNU, found in "/home/lcl/dev/before/openjpeg2/BUILD/openjpeg-2.1.0/build/CMakeFiles/3.0.2/CompilerIdC/CMakeCCompilerId.o"
Comment 31 David Walser 2016-09-10 01:12:01 CEST
Nice job Len, we're getting there!  :D

the -lasan means that it's looking for /usr/lib(64)/libasan.so which is in the lib(64)asan-devel package.
Comment 32 Len Lawrence 2016-09-10 02:20:46 CEST
OK. That builds it.  But, running opj_decompress against poc.jp2 (1 & 2) does not appear to trigger asan; same output as before, summarized here:

[INFO] Start to read j2k main header (141).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
[INFO] Header of tile 0 / 0 has been read.
[ERROR] Stream too short, expected SOT
[ERROR] Failed to decode tile 1/1
[ERROR] Failed to decode the codestream in the JP2 file

Expected output =
$ cat info.txt
==1630==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb48010d8 at pc 0x8184862 bp 0xbfff8e58 sp 0xbfff8e50
READ of size 4 at 0xb48010d8 thread T0
==1630==WARNING: Trying to symbolize code, but external symbolizer is not initialized!
    #0 0x8184861 (/home/r/fuzz3/openjpeg-master/bin/opj_decompress+0x8184861)

...........
==1630==ABORTING
[Inferior 1 (process 1630) exited with code 01]

I have examined the sources and they all appear to be C files.  According to Wikipedia compiled files just need to be run - the examples were clang fragments.  I am wondering if clang would work - don't know anything about it.
Another article has this:
In order to use AddressSanitizer you will need to compile and link your program using clang with the -fsanitize=address switch. To get a reasonable performance add -O1 or higher. To get nicer stack traces in error messages add -fno-omit-frame-pointer.

I am just going to experiment with the clang option - nothing to lose.
Comment 33 Len Lawrence 2016-09-10 02:29:57 CEST
Hmm.  That passed the bm -ls stage but the build process spewed out a lot of undefined references, e.g.

undefined reference to `__asan_report_load_n'
Comment 34 Len Lawrence 2016-09-10 03:19:22 CEST
A short test program compiled and ran with ASAN output.

$ clang -fsanitize=address -g use-after-free.c
$ ./a.out
=================================================================
==27151==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb5 at pc 0x0000004b7aa8 bp 0x7ffd25e11190 sp 0x7ffd25e11188
........

The man page for clang implies that the include files path defaults to the system includes but I cannot find anything related to ASAN in /usr/include or anywhere else.
$ locate include | grep asan | grep -v kernel
$
Comment 35 Len Lawrence 2016-09-10 09:32:05 CEST
$ gcc --version
gcc (GCC) 4.9.2

gcc > 4.8 "comes with ASAN support".  Presumably packagers are aware of this?

$ gcc --version -v

generated a lot of information about the gcc build/configuration but nothing connected with asan or sanitizer.

Currently exploring the  --help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...]
options.

Nothing in "target".
Comment 36 Len Lawrence 2016-09-10 09:45:19 CEST
$ gcc --help=common
......
-fsanitize=                 Select what to sanitize

So the switch should definitely be recognized.

$ gcc -fsanitize=address use-after-free.c -lasan
$ ./a.out
=================================================================
==32512==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb5 at pc 0x400846 bp 0x7ffd23978a30 sp 0x7ffd23978a28
READ of size 1 at 0x60700000dfb5 thread T0
    #0 0x400845 in main (/home/lcl/dev/before/openjpeg2/a.out+0x400845)
    #1 0x7f730316f04f in __libc_start_main (/lib64/libc.so.6+0x2004f)
    #2 0x400708 (/home/lcl/dev/before/openjpeg2/a.out+0x400708)

0x60700000dfb5 is located 5 bytes inside of 80-byte region [0x60700000dfb0,0x60700000e000)
freed by thread T0 here:
........

No doubt that it works.
Comment 37 Len Lawrence 2016-09-11 01:17:39 CEST
Read somewhere that gcc 4.8 suffered from a bug which sometimes could result in the address sanitizer not being linked properly so in case this was still an issue I tried LDFLAGS+="-fsanitize=address" and rebuilt the package locally.  It still did not work on the PoC.

Running out of ideas here.
Comment 38 David Walser 2016-09-11 01:36:50 CEST
We're so close too!

Maybe: export LDFLAGS="%{ldflags} -lasan"
Comment 39 Len Lawrence 2016-09-11 02:29:14 CEST
Seemed like a good plan, but no progress.  Used your LDFLAGS on revision 1051399 but the PoC still gives the same old messages.

Log file records:
+ CFLAGS='-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -fsanitize=address'


+ LDFLAGS=' -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -lasan -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags'


+ /usr/bin/cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DCMAKE_INSTALL_LIBEXECDIR:PATH=/usr/libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/etc -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DCMAKE_BUILD_TYPE=release -DLIB_SUFFIX=64 -DCMAKE_SKIP_RPATH:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF '-DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed  -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags' -DOPENJPEG_INSTALL_BIN_DIR:PATH=/usr/bin -DOPENJPEG_INSTALL_DATA_DIR:PATH=/usr/share -DOPENJPEG_INSTALL_LIB_DIR:PATH=lib64 -DBUILD_DOC=ON

Any idea what openjpeg2-debuginfo is used for or what it provides?
'urpmq -i openjpeg2-debuginfo' returns nothing.  Will look for the source rpm.
Comment 40 Len Lawrence 2016-09-11 11:36:50 CEST
strace shows that the utility succeeds in opening libasan but does not seem to use it anywhere.

$ strace opj_decompress -i poc.jp2 -o poc2.pgm >& trace
$ grep -i asan trace
open("/usr/lib64/tls/x86_64/libasan.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libasan.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/x86_64/libasan.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libasan.so.1", O_RDONLY|O_CLOEXEC) = 3

A similar probe on the ouput from the use-after-free script shows more:
$ strace ./uaf >& uaf.trace
$ grep -i asan uaf.trace
open("/usr/lib64/tls/x86_64/libasan.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/tls/libasan.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/x86_64/libasan.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libasan.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/libasan.so.1", O_RDONLY|O_CLOEXEC) = 3
write(2, "    #0 0x7f86b48bc5a7 in __inter"..., 78    #0 0x7f86b48bc5a7 in __interceptor_free (/usr/lib64/libasan.so.1+0x545a7)
write(2, "    #0 0x7f86b48bc7bf in malloc "..., 66    #0 0x7f86b48bc7bf in malloc (/usr/lib64/libasan.so.1+0x547bf)
write(2, "  ASan internal:           fe\n", 30  ASan internal:           fe

which I think demonstrates how ASan takes over the malloc function.
Comment 41 David Walser 2016-09-12 22:08:48 CEST
LWN reference for CVE-2016-1924 and CVE-2016-7163:
http://lwn.net/Vulnerabilities/700384/

Debian has issued an advisory for this on September 11:
https://www.debian.org/security/2016/dsa-3665
Comment 42 David Walser 2016-09-13 18:58:21 CEST
Hi Len, I was looking at this:
https://github.com/google/sanitizers/wiki/AddressSanitizer

and saw two things in the FAQ that might be relevant for us:
"A3: The fortify source compiler feature can mask errors that ASan is able to detect. On some systems (Ubuntu, Gentoo) fortify source is enabled by default, you can make sure it's disabled by passing -U_FORTIFY_SOURCE in your compiler flags.

Q: When I link my shared library with -fsanitize=address, it fails due to some undefined ASan symbols (e.g. asan_init_v4)?

A: Most probably you link with -Wl,-z,defs or -Wl,--no-undefined. These flags don't work with ASan unless you also use -shared-libasan (which is the default mode for GCC, but not for Clang)."

So, you'll need to add that -U_FORTIFY_SOURCE to the CFLAGS definition you added to the SPEC.

Also with the bit about *linking* with -fsanitize=address (which it also mentions earlier in the page), I guess that needs to be added to the LDFLAGS too.
Comment 43 David Walser 2016-09-13 22:10:51 CEST
Indeed, you can see from here the fsanitize does need to be in LDFLAGS:
http://www.openwall.com/lists/oss-security/2016/09/13/9
Comment 44 Len Lawrence 2016-09-14 17:24:06 CEST
Thanks David for doing the research; not making any headway yet.

SPEC file extract:
%build
export CC=clang
export CFLAGS="%{optflags} -fsanitize=address -fno-omit-frame-pointer -U_FORTIFY_SOURCE"
export LDFLAGS="%{ldflags} -lasan -fsanitize=address -shared-libasan"
%cmake \
  -DOPENJPEG_INSTALL_BIN_DIR:PATH=%{_bindir} \
  -DOPENJPEG_INSTALL_DATA_DIR:PATH=%{_datadir} \
  -DOPENJPEG_INSTALL_LIB_DIR:PATH=%{_lib} \
  -DBUILD_DOC=ON

Result:

/bin/clang -O2 -g -pipe -Wformat -Werror=format-security
  -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC
  -fsanitize=address -fno-omit-frame-pointer -U_FORTIFY_SOURCE
  -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id
  -Wl,--enable-new-dtags -lasan -fsanitize=address -shared-libasan
  -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id
  -Wl,--enable-new-dtags
  CMakeFiles/cmTryCompileExec2922389572.dir/testCCompiler.c.o -o
  cmTryCompileExec2922389572 -rdynamic

  clang: warning: argument unused during compilation:
  '-Wp,-D_FORTIFY_SOURCE=2'

  /bin/ld: cannot find
  /usr/bin/../lib/clang/3.5.2/lib/linux/libclang_rt.asan-preinit-x86_64.a: No
  such file or directory

  /bin/ld: cannot find
  /usr/bin/../lib/clang/3.5.2/lib/linux/libclang_rt.asan-x86_64.so: No such
  file or directory

Build fails.  Note that the /lib/clang/3.5.2/lib/linux/ exists but the particular .so does not.


For GCC, the same spec file, without the -shared-libasan option, succeeeds in building but still does not enable asan in the PoC test.  No sign of the interceptor routine kicking in.
Comment 45 Len Lawrence 2016-09-16 11:08:18 CEST
Switching back to clang, ld reports that it cannot find

/lib/clang/3.5.2/lib/linux/libclang_rt.asan-preinit-x86_64.{a,so}

$ locate libclang_rt.asan
/usr/lib/clang/3.5.2/lib/linux/libclang_rt.asan-x86_64.a
/usr/lib/clang/3.5.2/lib/linux/libclang_rt.asan_cxx-x86_64.a

On the web there are Debian/Ubuntu reports that this is a known bug for clang, as late as clang 3.7.0, so it looks like clang is not an option at this stage.

Back to strace on the gcc build to see if anything looks out of order.
Comment 46 Len Lawrence 2016-09-16 11:19:40 CEST
@David
At the latest QA meeting it looked like wilcal was hinting that this kind of research is not really the business of QA and I cannot help feeling some sympathy for that view.  Personally, I would like to pursue this because ASAN looks like a useful tool and if other distributions are using it Mageia needs to get a handle on it.  If we take this out of QA that still leaves you with a problem re the advisory doesn't it?
Comment 47 David Walser 2016-09-16 14:28:52 CEST
That's not how I interpreted what wilcal said, but it just sounded to me like he has no understanding of what we are trying to do here.  We should ask on the dev list if anyone can help us figure out how to close the deal on getting this to work.
Comment 48 Len Lawrence 2016-09-17 18:35:57 CEST
Yes, it is a bit specialized.  Maybe open a bug on ASAN integration or would that be too slow?
Comment 49 Herman Viaene 2016-09-21 14:29:37 CEST
Can I add to the confusion? And ccheck I understand what happened.
Len has the issue that he cannot reproduce the output as in http://seclists.org/oss-sec/2016/q1/128 with our current 2.1.0 version, right?
I've been doing a test using imagemagick display and convert  for the update version, and got this same errors "tgt_create tree->numnodes == 0, no tree created."
But with opj_decompress I noticed something different: after the tree node messages I see:
[INFO] Header of tile 1 / 15 has been read.
[INFO] Tile 1/15 has been decoded.
[INFO] Image data has been updated with tile 1.

[INFO] Stream reached its end !
/home/iurt/rpmbuild/BUILD/openjpeg-2.1.1/src/bin/common/color.c:922:color_esycc_to_rgb
	CAN NOT CONVERT

and that /home/iurt of course does not exist on my laptop, and it rings a bell: in the past this has occurred before that this path got hard coded into the prog, and it had to be rebuilt.

CC: (none) => herman.viaene

Comment 50 Len Lawrence 2016-09-21 19:13:34 CEST
> Len has the issue that he cannot reproduce the output as in http://seclists.org/oss-sec/2016/q1/128 with our current 2.1.0 version, right?

Yes.  And thanks for adding another pair of eyes to this one.  
With the 1/poc.jp2 the tail of the output is different from yours and an output image is generated and can be displayed (ImageMagick).  I have a vague feeling that I saw your output at one time, possibly for the update, but I have reverted for the time being to the pre-update stage to try to get a handle on ASAN. 

It is probable that the patch has worked but we would like to see the address sanitizer output so that these tests can be definitely lined up with the correct CVEs; at least that is my understanding.
Comment 51 Len Lawrence 2016-09-22 08:59:54 CEST
Something significant here maybe - but what?

$ strings /usr/bin/opj_decompress | grep asan | wc -l
25
$ strings /usr/bin/opj_decompress | grep sanitizer | wc -l
0
$ strings /usr/bin/opj_decompress | grep iurt | wc -l
0

Here, uaf is the a.out from the use-after-free demonstration program.
$ strings uaf | grep sanitizer
../../../../libsanitizer/sanitizer_common
../../../../libsanitizer/asan
sanitizer_stacktrace.h
sanitizer_internal_defs.h
sanitizer_libc.h
sanitizer_common.h
_ZN11__sanitizer10StackTrace6UnwindEmmmmmb
../../../../libsanitizer/asan/asan_preinit.cc
_ZN11__sanitizer10StackTrace10PrintStackEPKmmPFbPKvPciE
_ZN11__sanitizer10StackTrace15LocatePcInTraceEm
_ZN11__sanitizer10StackTrace24GetPreviousInstructionPcEm
__sanitizer
_ZN11__sanitizer10StackTrace8CopyFromEPKmm
/home/iurt/rpmbuild/BUILD/gcc-4.9.2/obj-x86_64-mageia-linux-gnu/x86_64-mageia-linux-gnu/libsanitizer/asan
_ZN11__sanitizer10StackTrace15FastUnwindStackEmmmmm
_ZN11__sanitizer10StackTrace17WillUseFastUnwindEb
_ZN11__sanitizer10StackTrace12GetCurrentPcEv
_ZN11__sanitizer10StackTrace14PopStackFramesEm
_ZN11__sanitizer10StackTrace15SlowUnwindStackEmm

But maybe not:
$ file /usr/bin/opj_decompress 
/usr/bin/opj_decompress: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=a3d853d9370298ec0decf3564a8e612797258c01, stripped
$ file uaf
uaf: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=16a5e2bfe52627bcc85850a930e09e04e216fd6e, not stripped

Not sure what "stripped" means.
Comment 52 David Walser 2016-09-22 13:29:22 CEST
Len, you gave me an idea.  I wonder if some of our optimization flags are interfering with ASAN.  Maybe where you did the export CXXFLAGS="%{optflags} ..." part, drop the %{optflags}.
Comment 53 David Walser 2016-09-22 14:54:06 CEST
Also, I just asked blino about it, and he said to use these flags specifically:
static-libstdc++ -static-libasan -O -g -fsanitize=address -fno-omit-frame-pointer
Comment 54 Len Lawrence 2016-09-22 19:45:38 CEST
Right.  Removed the optimizations.  I have been using gcc and CCFLAGS most of the time.  

Edited config contains:

export CC=gcc
export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
export LDFLAGS="%{ldflags} -static-libstdc++ -lasan -static-libasan -fsanitize=address -fno-omit-frame-pointer"

The terminal output from the build contains this section:

cpio: /home/iurt/rpmbuild/BUILD/gcc-4.9.2/obj-x86_64-mageia-linux-gnu/x86_64-mageia-linux-gnu/libgcc: Cannot stat: No such file or directory
cpio: /home/iurt/rpmbuild/BUILD/gcc-4.9.2/obj-x86_64-mageia-linux-gnu/x86_64-mageia-linux-gnu/libsanitizer/asan: Cannot stat: No such file or directory
cpio: /home/iurt/rpmbuild/BUILD/gcc-4.9.2/obj-x86_64-mageia-linux-gnu/x86_64-mageia-linux-gnu/libsanitizer/interception: Cannot stat: No such file or directory
cpio: /home/iurt/rpmbuild/BUILD/gcc-4.9.2/obj-x86_64-mageia-linux-gnu/x86_64-mageia-linux-gnu/libsanitizer/libbacktrace: Cannot stat: No such file or directory
cpio: /home/iurt/rpmbuild/BUILD/gcc-4.9.2/obj-x86_64-mageia-linux-gnu/x86_64-mageia-linux-gnu/libsanitizer/lsan: Cannot stat: No such file or directory
cpio: /home/iurt/rpmbuild/BUILD/gcc-4.9.2/obj-x86_64-mageia-linux-gnu/x86_64-mageia-linux-gnu/libsanitizer/sanitizer_common: Cannot stat: No such file or directory
cpio: /home/iurt/rpmbuild/BUILD/glibc-2.20/csu: Cannot stat: No such file or directory
cpio: /home/iurt/rpmbuild/BUILD/glibc-2.20/stdlib: Cannot stat: No such file or directory

I don't know what to make of that.
Comment 55 David Walser 2016-09-22 22:16:36 CEST
Probably need to install glibc-static-devel, and maybe libasan-devel.
Comment 56 Len Lawrence 2016-09-23 08:24:52 CEST
They appear to be installed already.
Comment 57 Len Lawrence 2016-09-23 11:23:13 CEST
I wondered if libasan_preinit was being loaded so added /lib64/libasan_preinit.o to LDFLAGS but that caused the build script to fail on an already defined symbol.  This just confirms that gcc is paying attention to the sanitizer requests, presumably via /usr/lib(64)/libsanitizer.spec:

# This spec file is read by gcc when linking.  It is used to specify the
# standard libraries we need in order to link with various sanitizer libs.

*link_libasan: -lpthread -ldl -lm
.....
Comment 58 Lewis Smith 2016-09-25 10:29:36 CEST
Should we 'grey' this? "add 'feedback' to the Whiteboard" (lower case). This would not hinder the learned discourse between Len & David.

CC: (none) => lewyssmith

Comment 59 Len Lawrence 2016-09-25 11:09:03 CEST
No objections from me.  It has slipped onto the back-burner anyway.
Comment 60 David Walser 2016-09-25 17:22:22 CEST
Feedback means that there's potentially something wrong with the update, or that feedback is needed from the packager.  That is not the case here.  We are still testing it and trying to complete that.
Comment 61 David Walser 2016-09-30 21:37:53 CEST
Patch added to fix CVE-2016-7445:
http://lwn.net/Vulnerabilities/702317/
https://lists.opensuse.org/opensuse-updates/2016-09/msg00109.html

Updated packages in core/updates_testing:
========================
openjpeg2-2.1.1-1.2.mga5
libopenjp2_7-2.1.1-1.2.mga5
libopenjpeg2-devel-2.1.1-1.2.mga5

from openjpeg2-2.1.1-1.2.mga5.src.rpm
Comment 62 David Walser 2016-10-04 12:29:39 CEST
Cisco TALOS has issued an advisory on September 29:
http://www.talosintelligence.com/reports/TALOS-2016-0193/

The issue (CVE-2016-8332) is fixed upstream in 2.1.2:
http://www.openjpeg.org/2016/09/28/OpenJPEG-2.1.2-released
https://github.com/uclouvain/openjpeg/blob/openjpeg-2.1/CHANGELOG.md

(it's the issue #810 mentioned in the CHANGELOG above).

I will update it soon.
Comment 63 David Walser 2016-10-05 00:31:30 CEST
Updated to 2.1.2 to fix CVE-2016-8332.

Updated packages in core/updates_testing:
========================
openjpeg2-2.1.2-1.mga5
libopenjp2_7-2.1.2-1.mga5
libopenjpeg2-devel-2.1.2-1.mga5

from openjpeg2-2.1.2-1.mga5.src.rpm
Comment 64 Len Lawrence 2016-10-10 00:31:13 CEST
Still at the pre-update stage.  More observations, which may be irrelevant.

The build scripts in BUILDROOT contain entries like these:

RPM_OPT_FLAGS="-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC"

export CFLAGS="-O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -fsanitize=address -U_FORTIFY_SOURCE"
e
# Note optimization level 2

  CFLAGS="${CFLAGS:--O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC}" ; export CFLAGS ; 

        -DBUILD_SHARED_LIBS:BOOL=ON \
        -DBUILD_STATIC_LIBS:BOOL=OFF \
        -DCMAKE_MODULE_LINKER_FLAGS="-Wl,--as-needed  -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags" \
# Optimization level 1, shared libraries, no static libraries

None of these scripts contain any reference to sanitizeaddress in CCFLAGS.  Does this mean that the ASAN calls are not compiled in?

The build log in SPECS contains this:
+ /usr/bin/cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DCMAKE_INSTALL_LIBEXECDIR:PATH=/usr/libexec -DCMAKE_INSTALL_SYSCONFDIR:PATH=/etc -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DCMAKE_BUILD_TYPE=release -DLIB_SUFFIX=64 -DCMAKE_SKIP_RPATH:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF '-DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed  -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags' -DOPENJPEG_INSTALL_BIN_DIR:PATH=/usr/bin -DOPENJPEG_INSTALL_DATA_DIR:PATH=/usr/share -DOPENJPEG_INSTALL_LIB_DIR:PATH=lib64 -DBUILD_DOC=ON

Don't know how important these are:
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_STATIC_LIBS
    CMAKE_INSTALL_LIBDIR
    CMAKE_INSTALL_LIBEXECDIR
    CMAKE_INSTALL_SYSCONFDIR
    INCLUDE_INSTALL_DIR
    LIB_INSTALL_DIR
    LIB_SUFFIX
    SHARE_INSTALL_PREFIX
    SYSCONF_INSTALL_DIR

At the end there is this:
Requires: devel(libasan(64bit)) devel(libm(64bit)) pkgconfig
Presumably development libraries are needed only at compilation time.
$ sudo urpmi libasan-devel
Package libasan-devel-4.9.2-4.1.mga5.x86_64 is already installed
Comment 65 Len Lawrence 2016-10-10 00:39:32 CEST
Correction:

BUILDROOT]$ grep CCFLAGS *
rpm-tmp.54jnNM:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
rpm-tmp.A6elIz:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
rpm-tmp.eQXggE:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
rpm-tmp.nMRxZq:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
rpm-tmp.VaH2iv:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
rpm-tmp.WFUQXl:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
rpm-tmp.ws5sCZ:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
rpm-tmp.zjl3jW:export CCFLAGS="-O -g -fsanitize=address -U_FORTIFY_SOURCE"
Comment 66 Len Lawrence 2016-10-19 21:05:25 CEST
Calling a halt to this investigation.  It is beyond my competence at this time to figure out why the build system does not enable support for ASAN and it might be better to treat this as a subject for discussion on the dev list.  On the understanding that the packages work I shall pass this if David agrees.  Don't know how this would affect the advisory.
Comment 67 Len Lawrence 2016-10-20 10:38:39 CEST
Just remembered; any after-updates testing was done on the packages built locally so the updates actually need to be installed and testing repeated.
Comment 68 Len Lawrence 2016-10-20 17:52:22 CEST
Installed all the updates including the ghostscript ones.

The main test programs are mupdf, ghostscript and the ImageMagick suite.

mupdf works well on a variety of PDF documents.

JPEG 2000 sample images are hard to find.  This one displayed fine (IM).
balloon.jp2 from http://opf-labs.org/format-corpus/jp2k-formats/
$ convert balloon.jp2 balloon.png
$ convert -resize 20% -quality 100 balloon.jp2 balloon.jpg
$ identify balloon.jp2
balloon.jp2 JP2 2717x3701 2717x3701+0+0 8-bit sRGB 670KB 0.000u 0:00.000
$ identify balloon.jpg
balloon.jpg JPEG 543x740 543x740+0+0 8-bit sRGB 479KB 0.000u 0:00.000
$ identify balloon.png
balloon.png PNG 2717x3701 2717x3701+0+0 8-bit sRGB 12.7MB 0.000u 0:00.000
$ cp balloon.jp2 balloon.what
$ identify balloon.what
balloon.what JP2 2717x3701 2717x3701+0+0 8-bit sRGB 670KB 0.000u 0:00.000

And display continues to work with other image formats, GIF, PNG, JPEG...
but it cannot handle the other formats derived from the JPEG 2000 standard such as j2c, jpf, mj2 and jpm.

Used gs to display a locally generated postscript file.  No problems.

Experimented with the supplied tools.
$ opj_decompress -i balloon.jp2 -o balloon.pgm
[INFO] Start to read j2k main header (2929).
[INFO] Main header has been correctly decoded.
[INFO] No decoded area parameters, set the decoded area to the whole image
.........
# This produced a greyscale image.
$ file balloon.pgm
balloon.pgm: Netpbm PGM "rawbits" image data, size = 2717 x 3701

Ran the compression utility:
$ opj_compress -r 20,10,1 -i balloon.png -o squashedballoon.jp2
$ identify squashedballoon.jp2
squashedballoon.jp2 JP2 2717x3701 2717x3701+0+0 8-bit sRGB 9.88MB 0.000u 0:00.000
$ ls -l balloon.png
-rw-r--r-- 1 lcl wireshark 12696332 Oct 20 16:17 balloon.png
$ ls -l squashedballoon.jp2
-rw-r--r-- 1 lcl wireshark 9879867 Oct 20 16:46 squashedballoon.jp2
Comment 69 Lewis Smith 2016-10-23 11:16:22 CEST
(In reply to Len Lawrence from comment #67)
> Just remembered; any after-updates testing was done on the packages built
> locally so the updates actually need to be installed and testing repeated.
(In reply to Len Lawrence from comment #68)
> Installed all the updates including the ghostscript ones.
etc etc
Great work! Any reason not to OK it for x64 (if that is what you tested)?
If it was 32-bit, I will do 64.

-------------------------------

To try to wrap this up, and collect the most recent info together:

- The full updated package list is in Comment 14, of which just the Ghostscript packages remain relevant. But NOT the first 3:
 openjpeg2
 libopenjp2_7
 libopenjpeg2-devel
which are superseded Comment 29, again Comment 61, again Comment 63 which is currently definitive for this update:
 openjpeg2-2.1.2-1.mga5
 libopenjp2_7-2.1.2-1.mga5
 libopenjpeg2-devel-2.1.2-1.mga5
from openjpeg2-2.1.2-1.mga5.src.rpm

- Advisory to come later. Comment 6

- CVEs:
CVE-2016-1923   Title. Untestable by QA, may have to be removed from advisory
CVE-2016-1924   Title. Untestable by QA, may have to be removed from advisory
CVE-2016-3181   Title
CVE-2016-3182   Title
CVE-2016-3183   Title
CVE-2016-4796   Title
CVE-2016-4797   Title
CVE-2016-5157   Title
CVE-2016-7163   Title
CVE-2016-7445   Comment 61
CVE-2016-8332   Comment 63

- Comment 68 has a valuable jpeg2000 image source reference:
 http://opf-labs.org/format-corpus/jp2k-formats/
and comprehensive testing ideas and examples, starting "The main test programs are mupdf, ghostscript and the ImageMagick suite".
Comment 70 Len Lawrence 2016-10-23 12:52:38 CEST
Lewis, I think you have covered all the points - not an easy job.

My tests have all been with x86_64.  The functionality tests could be done for i586, in virtualbox here.  Not worth pursuing PoCs on 32-bits, IMHO.
Comment 71 Len Lawrence 2016-10-23 19:54:19 CEST
Functionality tests on i586 in virtualbox

Opened a couple of multi-page PDF format ebooks with mupdf-x11 and traversed the pages by pressing the space key.

ghostscript had no trouble with a locally generated Postscript file using the commandline utility gs.  It handled the '/BorzoiRegular findfont  ....' command in the document and displayed the text in the Borzoi font perfectly.

Imported a couple of JPEG2000 images from the host and manipulated them with ImageMagick and the openjpeg2 tools.

$ opj_decompress -i balloon.jp2 -o balloon.pgm
# This output a lot of informational messages about reading and decoding the tiles.
# By default the output image is greyscale but
$ opj_decompress -force-rgb -i balloon.jp2 -o rgb_balloon.pgm
# also produces a greyscale image.  No way indicated to suppress diagnostics; maybe it
# is intended as a development tool only.
$ identify rgb_balloon.pgm 
rgb_balloon.pgm PGM 2717x3701 2717x3701+0+0 8-bit Grayscale Gray 10.06MB 0.010u 0:00.009

$ opj_compress -r 20,10,1 -i balloon.png -o squashedballoon.jp2
[INFO] tile number 1 / 1
[INFO] Generated outfile squashedballoon.jp2
encode time: 6257 ms 
$ identify squashedballoon.jp2
squashedballoon.jp2 JP2 2717x3701 2717x3701+0+0 8-bit sRGB 9.88MB 0.000u 0:00.000

This all looks good for 32-bits.

Leaving validation to Lewis.
Len Lawrence 2016-10-23 19:55:47 CEST

Whiteboard: (none) => MGA5-64-OK MGA5-32-OK

Comment 72 Lewis Smith 2016-10-24 09:33:44 CEST
(In reply to Len Lawrence from comment #71)
> Leaving validation to Lewis.
As you wish! Once more, mega-thanks for your efforts on this - far beyond the call of duty.

@Dave : you may wish to UNvalidate this update until the advisory is posted. I prefer not: people have commented about its ongoing presence.

@David : Re the two controversial CVE-2016-1923 CVE-2016-1924, over which we got well & truly bogged down, I see the important thing as being *are the patches for them in our update or not?*
- If we know they are, then the CVEs *can* be cited in our advisory.
- If we do not know, then we drop them from our advisory.
Len has done such extensive usage testing of the packages that their suitability to let out is not in question.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 73 Nicolas Lécureuil 2016-10-24 22:27:43 CEST
can someone upload the advisory please ? 
thanks

CC: (none) => mageia

Comment 74 Dave Hodgins 2016-10-25 22:49:25 CEST
Removing the validated_update keyword till there is an advisory available in
the bug report, to be uploaded to svn.

Will discuss in next qa meeting.
Dave Hodgins 2016-10-25 22:49:44 CEST

Keywords: validated_update => (none)

Comment 75 Lewis Smith 2016-10-29 22:22:24 CEST
@David : please comment. The two unknown fixed CVEs omitted as agreed on IRC.

Draft advisory
==============

Updates fix various jpeg2000 related security issues.

CVE-2016-3181: A specially crafted JPEG2000 image file can force Out-Of-Bounds Read opj_decompress -o image.pgm -i oob_opj_tcd_free_tile.jp2 precision 31 is larger than 16.

CVE-2016-3182: A specially crafted JPEG2000 image file can force Heap Corruption opj_decompress -o image.pgm -i heap_corruption.jp2 double free or corruption (!prev).

CVE-2016-3183: A specially crafted JPEG2000 image file can force Out-Of-Bounds Read: opj_decompress -o image.pgm -i oob_sycc422_to_rgb.j2k .

CVE-2016-4796: OpenJPEG Heap Buffer Overflow in function color_cmyk_to_rgb of color.c .

CVE-2016-4797: OpenJPEG division-by-zero in function opj_tcd_init_tile of tcd.c .

CVE-2016-5157: Heap-based buffer overflow in the opj_dwt_interleave_v function in dwt.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, allows remote attackers to execute arbitrary code via crafted coordinate values in JPEG 2000 data.

CVE-2016-7163: 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-7445: convert.c in OpenJPEG before 2.1.2 allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via vectors involving the variable s.

CVE-2016-8332: A buffer overflow in OpenJPEG 2.1.1 causes arbitrary code execution when parsing a crafted image. An exploitable code execution vulnerability exists in the jpeg2000 image file format parser as implemented in the OpenJpeg library. A specially crafted jpeg2000 file can cause an out of bound heap write resulting in heap corruption leading to arbitrary code execution. For a successful attack, the target user needs to open a malicious jpeg2000 file. The jpeg2000 image file format is mostly used for embedding images inside PDF documents and the OpenJpeg library is used by a number of popular PDF renderers making PDF documents a likely attack vector.

Source RPMs:
 ghostscript-9.14-3.2.mga5.src.rpm
 openjpeg2-2.1.2-1.mga5.src.rpm

References:
http://openwall.com/lists/oss-security/2016/01/18/7
http://openwall.com/lists/oss-security/2016/03/16/15
http://openwall.com/lists/oss-security/2016/03/16/16
http://openwall.com/lists/oss-security/2016/03/16/17
http://openwall.com/lists/oss-security/2016/05/12/1
http://openwall.com/lists/oss-security/2016/05/13/2
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/HPMDEUIMHTLKMHELDL4F4HZ7X4Y34JEB/
https://github.com/uclouvain/openjpeg/blob/master/CHANGELOG.md
http://seclists.org/oss-sec/2016/q1/128
http://www.openwall.com/lists/oss-security/2016/09/08/5
http://www.openwall.com/lists/oss-security/2016/09/08/6
https://www.debian.org/security/2016/dsa-3665
https://lists.opensuse.org/opensuse-updates/2016-09/msg00109.html
http://www.talosintelligence.com/reports/TALOS-2016-0193/
http://www.openjpeg.org/2016/09/28/OpenJPEG-2.1.2-released
https://github.com/uclouvain/openjpeg/blob/openjpeg-2.1/CHANGELOG.md
Comment 76 David Walser 2016-11-02 20:32:46 CET
Thanks Lewis.  Reformatted and trimmed a bit.  We can go ahead with it.

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

Updated openjpeg2 packages fix security vulnerabilities:

A specially crafted JPEG2000 image file can force Out-Of-Bounds Read in
opj_tcd_free_tile() (CVE-2016-3181).

A specially crafted JPEG2000 image file can force Heap Corruption in
opj_free() (CVE-2016-3182).

A specially crafted JPEG2000 image file can force Out-Of-Bounds Read in
sycc422_to_rgb() (CVE-2016-3183).

OpenJPEG Heap Buffer Overflow in function color_cmyk_to_rgb() in color.c
(CVE-2016-4796).

OpenJPEG division-by-zero in function opj_tcd_init_tile() in tcd.c
(CVE-2016-4797).

Heap-based buffer overflow in the opj_dwt_interleave_v function in dwt.c in
OpenJPEG allows remote attackers to execute arbitrary code via crafted
coordinate values in JPEG 2000 data (CVE-2016-5157).

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).

convert.c in OpenJPEG before 2.1.2 allows remote attackers to cause a denial
of service (NULL pointer dereference and application crash) via vectors
involving the variable s (CVE-2016-7445).

A buffer overflow in OpenJPEG 2.1.1 causes arbitrary code execution when
parsing a crafted image. An exploitable code execution vulnerability exists
in the jpeg2000 image file format parser as implemented in the OpenJpeg
library. A specially crafted jpeg2000 file can cause an out of bound heap
write resulting in heap corruption leading to arbitrary code execution
(CVE-2016-8332).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3181
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3182
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3183
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4796
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4797
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5157
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7163
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7445
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8332
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/HPMDEUIMHTLKMHELDL4F4HZ7X4Y34JEB/
https://github.com/uclouvain/openjpeg/blob/master/CHANGELOG.md
https://www.debian.org/security/2016/dsa-3665
https://lists.opensuse.org/opensuse-updates/2016-09/msg00109.html
http://www.talosintelligence.com/reports/TALOS-2016-0193/
http://www.openjpeg.org/2016/09/28/OpenJPEG-2.1.2-released
https://github.com/uclouvain/openjpeg/blob/openjpeg-2.1/CHANGELOG.md
Comment 77 Lewis Smith 2016-11-03 07:55:42 CET
Validated. Advisory uploaded.

Keywords: (none) => validated_update
Whiteboard: MGA5-64-OK MGA5-32-OK => MGA5-64-OK MGA5-32-OK advisory

Comment 78 Mageia Robot 2016-11-03 10:03:34 CET
An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2016-0362.html

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

Comment 79 David Walser 2016-11-04 16:12:19 CET
(In reply to David Walser from comment #62)
> Cisco TALOS has issued an advisory on September 29:
> http://www.talosintelligence.com/reports/TALOS-2016-0193/
> 
> The issue (CVE-2016-8332) is fixed upstream in 2.1.2:
> http://www.openjpeg.org/2016/09/28/OpenJPEG-2.1.2-released
> https://github.com/uclouvain/openjpeg/blob/openjpeg-2.1/CHANGELOG.md
> 
> (it's the issue #810 mentioned in the CHANGELOG above).

LWN reference:
http://lwn.net/Vulnerabilities/705580/
Comment 80 David Walser 2016-12-08 20:14:59 CET
LWN reference for CVE-2016-1923:
https://lwn.net/Vulnerabilities/708528/

Note You need to log in before you can comment on or make changes to this bug.