Fix for CVE-2016-8332 and CVE-2016-7163

Bug #1630702 reported by Wise Melon
268
This bug affects 3 people
Affects Status Importance Assigned to Milestone
openjpeg2 (Ubuntu)
Fix Released
Medium
Unassigned
Xenial
Fix Released
Medium
Unassigned
Yakkety
Fix Released
Medium
Unassigned

Bug Description

* Impact
- CVE-2016-8332:
Out-of-bound heap write possible resulting in heap corruption and arbitrary code execution

- CVE-2016-7163:
Integer overflow possible resulting in arbitrary code execution via a crafted JP2 file, triggering out-of-bound read or write

* Test case
- CVE-2016-8332:
Information on exploit: http://www.talosintelligence.com/reports/TALOS-2016-0193/

- CVE-2016-7163:
I haven't been able to find information on the exploit for this except for the information given here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-7163

* Regression potential
These patches have not been tested as I currently do not have the resources to do so.

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

Original report:

A security vulnerability was recently disclosed in OpenJPEG and assigned the CVE number of CVE-2016-8332.

The vulnerability is described here (http://www.zdnet.com/article/openjpeg-zero-day-flaw-leads-to-remote-code-execution/):

"
Cisco Talos researchers have uncovered a severe zero-day flaw in the OpenJPEG JPEG 2000 codec which could lead to remote code execution on compromised systems.

On Friday, researchers from Cisco revealed the existence of the zero-day flaw in the JPEG 2000 image file format parser implemented in OpenJPEG library. The out-of-bounds vulnerability, assigned as CVE-2016-8332, could allow an out-of-bound heap write to occur resulting in heap corruption and arbitrary code execution.

OpenJPEG is an open-source JPEG 2000 codec. Written in C, the software was created to promote JPEG 2000, an image compression standard which is in popular use and is often used for tasks including embedding images within PDF documents through software including Poppler, MuPDF and Pdfium.

The bug, assigned a CVSS score of 7.5, was caused by errors in parsing mcc records in the jpeg2000 file, resulting in "an erroneous read and write of adjacent heap area memory." If manipulated, these errors can lead to heap metadata process memory corruption.

In a security advisory, the team said the security vulnerability can be exploited by attackers if victims open specifically crafted, malicious JPEG 2000 images. For example, if this content was within a phishing email or hosted on legitimate services such as Google Drive or Dropbox, once downloaded to their system, the path is created for attackers to execute code remotely.

The vulnerability was discovered by Aleksander Nikolic from the Cisco Talos security team in OpenJpeg openjp2 version 2.1.1.

Cisco Talos disclosed the vulnerability to affected vendors on 26 July, granting them time to prepare patches to fix the problem before public release.
"

I am filing this report as a fix for the issue doesn't seem to have yet been backported in and given the importance of the issue and the ease in exploiting it, it would be good if this is done soon.

This is the fix on GitHub: https://github.com/uclouvain/openjpeg/pull/820/files

information type: Public → Public Security
tags: added: precise trusty xenial
tags: added: yakkety
summary: - Backport in patch to fix CVE-2016-8332
+ CVE-2016-8332 allows an out-of-bound heap write to occur resulting in
+ heap corruption and arbitrary code execution
description: updated
Revision history for this message
Seth Arnold (seth-arnold) wrote : Re: CVE-2016-8332 allows an out-of-bound heap write to occur resulting in heap corruption and arbitrary code execution

Nikita, if you have time and care for OpenJPEG, please consider reviewing the crashing inputs I reported to the OpenJPEG team:

https://bugs.launchpad.net/ubuntu/+source/openjpeg2/+bug/711061/+attachment/4586223/+files/openjpeg-crashers.tar.gz
https://bugs.launchpad.net/ubuntu/+source/openjpeg2/+bug/711061/+attachment/4723094/+files/crashes-openjpeg-2.1.1.tar.gz

There's a few hundred crashing files there that need inspection and fixing.

Thanks

Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :

Seth, I will take a look at those soon after I have created a debdiff for this (that is if nobody else has done so by the time I do it, which hopefully will be some time tomorrow).

Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :

I assume that I should create a debdiff for this anyway. What do you think? And do I need to make one for each release or do you think that someone else can deal with altering my debdiff to be able to be in any release they want it to be in (if there is somebody to do that that is)?

Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :

I can create said debdiffs if there is nobody else better to do them. I'm just not incredibly experienced with this sort of thing (though I have successfully made debdiffs in the past and had them accepted) and in the past I was able to provide a debdiff which would then be altered by the person in the report I was giving it to so that it would be able to be applied to all currently supported releases rather than just the one I had made it for. Is there a person like that this time or do I need to create a separate one for each Ubuntu release?

Also, the patch I found is for the new 2.x.x series, will it be fine if I apply it to the 1.5.2-3.1 version we currently have here? I haven't looked far enough into the code yet to see if it would be a problem and if any other changes are necessary to make it work for the old version, but maybe I'm not the best person for that job as I am not familiar with the code for OpenJPEG.

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Our openjpeg and openjpeg2 packages have far more than this one flaw
unaccounted for:

http://people.canonical.com/~ubuntu-security/cve/pkg/openjpeg.html
http://people.canonical.com/~ubuntu-security/cve/pkg/openjpeg2.html

(I suspect that most issues that apply to one also apply to the other;
there is probably more overlap between the two packages.)

Fixing just one open issue is probably not worth the time; fixing most
of them would be. Finding fixes for all of them may not be feasible.

Since we rely upon our community users to test updates, we really do
need whoever supplies patches to have built and tested them all first. If
you're in for only one release, that's still useful, and perhaps someone
else would be willing to tackle the others later.

Probably the 2.x.x patch can be made to apply to the 1.5.2 version
we have packaged; the codebases looked very similar to me last time I
reviewed both.

Thanks

Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

Changed in openjpeg (Ubuntu):
status: New → Incomplete
Changed in openjpeg2 (Ubuntu):
status: New → Incomplete
Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote : Re: CVE-2016-8332 allows an out-of-bound heap write to occur resulting in heap corruption and arbitrary code execution

Seth, I can make the debdiffs for all the releases if I can find patches which I can apply. However I'm not sure that I really know enough to actually test if the vulnerability is still exploitable with the patched version. So I don't think that I would be able to test them. Would it still be worth me trying to make the debdiffs and uploading them?

Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hi Nikita, it's always nice when you can test directly if a known bad input has been handled correctly, but not all security fixes come with sample inputs to see the issue. So when you can find them, that's always welcome, but not necessary.

But it is necessary to make sure that programs that use openjpeg can still use it correctly after the update -- e.g., a selection of tools that use openjpeg should still be able to read their inputs or create their outputs after the updated packages have been installed.

If you yourself don't use openjpeg based tools perhaps someone else who does could help with the testing.

Thanks

Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :

Right, I don't really have any way of testing whether the patches have been applied correctly so I will just make the debdiffs and upload them.

But I will have to do this at the weekend because I do not have any time to do this now. I will be away from my computer until then.

Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :

I have just started working on applying the patches and making a debdiff for openjpeg, however I have got a slight problem, none of the files I am trying to patch seem similar enough in the 1.5.2 version to actually be patched, I just can't find the right places to insert and remove the code so I am really unable to do anything about the CVEs for this version.

I am now going to have a go with openjpeg2 and see if the version you have is similar enough to the upstream code.

Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :

This was my conclusion after looking through the CVEs in the list for openjpeg2:

CVE-2014-7945: Half done but unconfirmable (some files are so different I am unable to find the relevant lines in them).
CVE-2014-7947: Can’t find patch.
CVE-2015-8871: Seems a patched.
CVE-2016-1923: Can’t find patch.
CVE-2016-1924: Seems already patched.
CVE-2016-3181: Closed upstream as duplicate of CVE-2016-3182 bug report (I am confused about what to do for this).
CVE-2016-3182: Seems already patched.
CVE-2016-3183: Some changes are already present in accordance to the upstream patch, however in the majority of cases the file is so different to the upstream one that I am unable to figure what to put where. I am also concerned that as they are so different that perhaps the changes would not be compatible with it.
CVE-2016-4796: Seems already patched.
CVE-2016-4797: Seems already patched.
CVE-2016-7445: Unable to view patch.
CVE-2016-7163: Successfully patched.
CVE-2016-8332: Successfully patched.

I will now attach the debdiffs for Yakkety and Xenial with those two patches patched. I have never done a debdiff for CVE related fixes before so I hope that I have done everything correctly. I assume that you will let me know if I have not so that I can fix any issues.

summary: - CVE-2016-8332 allows an out-of-bound heap write to occur resulting in
- heap corruption and arbitrary code execution
+ Fix for CVE-2016-8332 and CVE-2016-7163
description: updated
Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :
Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :
Changed in openjpeg2 (Ubuntu):
status: Incomplete → Confirmed
no longer affects: openjpeg (Ubuntu)
tags: removed: precise trusty
Mathew Hodson (mhodson)
Changed in openjpeg2 (Ubuntu):
importance: Undecided → Medium
tags: added: patch
Changed in openjpeg2 (Ubuntu):
assignee: nobody → Nikita Yerenkov-Scott (yerenkov-scott)
Changed in openjpeg2 (Ubuntu Xenial):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Marc Deslauriers (mdeslaur) wrote :

ACK on the debdiffs, thanks!

Packages are currently building and will be released today.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openjpeg2 - 2.1.1-1ubuntu0.1

---------------
openjpeg2 (2.1.1-1ubuntu0.1) yakkety-security; urgency=medium

  * SECURITY UPDATE: Out-of-bound heap write possible resulting
    in heap corruption and arbitrary code execution (lp: #1630702)
    - debian/patches/CVE-2016-8332.patch: fix incrementing of
      "l_tcp->m_nb_mcc_records" in opj_j2k_read_mcc
      in src/lib/openjp2/j2k.c.
    - CVE-2016-8332
  * SECURITY UPDATE: Integer overflow possible resulting in
    arbitrary code execution via a crafted JP2 file,
    triggering out-of-bound read or write (lp: #1630702)
    - debian/patches/CVE-2016-7163.patch: fix an integer
      overflow issue in function opj_pi_create_decode of
      pi.c in src/lib/openjp2/pi.c.
    - CVE-2016-7163

 -- Nikita Yerenkov-Scott <email address hidden> Sat, 08 Oct 2016 16:10:43 +0100

Changed in openjpeg2 (Ubuntu Yakkety):
status: Confirmed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openjpeg2 - 2.1.0-2.1ubuntu0.1

---------------
openjpeg2 (2.1.0-2.1ubuntu0.1) xenial-security; urgency=medium

  * SECURITY UPDATE: Out-of-bound heap write possible resulting
    in heap corruption and arbitrary code execution (lp: #1630702)
    - debian/patches/CVE-2016-8332.patch: fix incrementing of
      "l_tcp->m_nb_mcc_records" in opj_j2k_read_mcc
      in src/lib/openjp2/j2k.c.
    - CVE-2016-8332
  * SECURITY UPDATE: Integer overflow possible resulting in
    arbitrary code execution via a crafted JP2 file,
    triggering out-of-bound read or write (lp: #1630702)
    - debian/patches/CVE-2016-7163.patch: fix an integer
      overflow issue in function opj_pi_create_decode of
      pi.c in src/lib/openjp2/pi.c.
    - CVE-2016-7163

 -- Nikita Yerenkov-Scott <email address hidden> Sat, 08 Oct 2016 16:10:43 +0100

Changed in openjpeg2 (Ubuntu Xenial):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers