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:
Whiteboard: (none) => MGA5TOO
Assigning to packagers collectively with the registered maintainer in CC. If working on it, please assign the bug report to yourself.
CC: (none) => fundawangAssignee: bugsquad => pkg-bugs
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]
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
(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]
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/
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 => 5Assignee: pkg-bugs => qa-bugsWhiteboard: MGA5TOO => (none)
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.
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
$ 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?
imagemagick sounds reasonable. The PoC's for Comment 2 showed them using opj_decompress from the openjpeg2 package.
Created attachment 8221 [details] Post-update diagnostics for PoC jp2 images opj_decompress used on the stage 1 and stage 2 poc.jp2 images
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.
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
Depends on: (none) => 19010
(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
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.
AS: Mageia has libasan1 but that is a runtime library. $ urpmq --whatrequires libasan1 libasan-devel libasan1
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?
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.
CC: (none) => alexandersirris
Status: NEW => ASSIGNED
Still need an advisory for this update
CC: (none) => davidwhodgins
Advisory is still pending confirmation from QA as to whether CVE-2016-192[34] are fixed by this update (see Comment 7).
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.
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.
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.
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
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.
Thanks David. As I said, dev skills... Shall try to get onto this sometime tomorrow.
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. :((
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)
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-7163Whiteboard: feedback => (none)
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"
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.
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.
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'
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 $
$ 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".
$ 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.
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.
We're so close too! Maybe: export LDFLAGS="%{ldflags} -lasan"
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.
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.
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
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.
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
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.
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.
@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?
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.
Yes, it is a bit specialized. Maybe open a bug on ASAN integration or would that be too slow?
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
> 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.
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.
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}.
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
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.
Probably need to install glibc-static-devel, and maybe libasan-devel.
They appear to be installed already.
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 .....
Should we 'grey' this? "add 'feedback' to the Whiteboard" (lower case). This would not hinder the learned discourse between Len & David.
CC: (none) => lewyssmith
No objections from me. It has slipped onto the back-burner anyway.
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.
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
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.
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
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
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"
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.
Just remembered; any after-updates testing was done on the packages built locally so the updates actually need to be installed and testing repeated.
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
(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".
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.
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.
Whiteboard: (none) => MGA5-64-OK MGA5-32-OK
(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_updateCC: (none) => sysadmin-bugs
can someone upload the advisory please ? thanks
CC: (none) => mageia
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.
Keywords: validated_update => (none)
@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
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
Validated. Advisory uploaded.
Keywords: (none) => validated_updateWhiteboard: MGA5-64-OK MGA5-32-OK => MGA5-64-OK MGA5-32-OK advisory
An update for this issue has been pushed to the Mageia Updates repository. http://advisories.mageia.org/MGASA-2016-0362.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
(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/
LWN reference for CVE-2016-1923: https://lwn.net/Vulnerabilities/708528/