Bug 1840347 (CVE-2020-13113) - CVE-2020-13113 libexif: use of uninitialized memory in EXIF Makernote handling can lead to crashes and use-after-free
Summary: CVE-2020-13113 libexif: use of uninitialized memory in EXIF Makernote handlin...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-13113
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1840348 1841251 1841252
Blocks: 1840352
TreeView+ depends on / blocked
 
Reported: 2020-05-26 18:49 UTC by Guilherme de Almeida Suckevicz
Modified: 2020-11-04 03:43 UTC (History)
11 users (show)

Fixed In Version: libexif 0.6.22
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-29 22:01:26 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:4040 0 None None None 2020-09-29 20:50:46 UTC
Red Hat Product Errata RHSA-2020:4766 0 None None None 2020-11-04 03:43:18 UTC

Description Guilherme de Almeida Suckevicz 2020-05-26 18:49:47 UTC
An issue was discovered in libexif before 0.6.22. Use of uninitialized memory in EXIF Makernote handling could lead to crashes and potential use-after-free conditions.

Reference and upstream commit:
https://github.com/libexif/libexif/commit/ec412aa4583ad71ecabb967d3c77162760169d1f

Comment 1 Guilherme de Almeida Suckevicz 2020-05-26 18:50:10 UTC
Created libexif tracking bugs for this issue:

Affects: fedora-all [bug 1840348]

Comment 2 Todd Cullum 2020-05-28 17:22:08 UTC
Technical Summary:

The libexif library parses an EXIF tag called a MakerNote. According to the EXIF standard[1], a MakerNote tag can hold manufacturer-specific data from camera manufacturers such as Nikon, Olympus, Canon, Panasonic, etc... the vulnerable libexif component parses these MakerNote tags into "entry" structures which can contain multiple "components." There is some code duplication in libexif, related parsing MakerNotes, so the same flaw is seen in 4 separate files: libexif/canon/exif-mnote-data-canon.c, libexif/fuji/exif-mnote-data-fuji.c, libexif/olympus/exif-mnote-data-olympus.c , and  libexif/pentax/exif-mnote-data-pentax.c.

Using the code in exif-mnote-data-canon.c as an example,

MakerNote Entry memory was allocated with n->entries = exif_mem_alloc(ne->mem, sizeof (MnoteCanonEntry) * c) but the entries were not initialized to 0. This could cause the dereference of an uninitialized wild pointer when the entry's data member is accessed later in the program, for example, by the exif_mnote_data_canon_clear() routine, which attempts to free the entries. This could also lead to a use-after-free. The current upstream patch uses memset to zero-initialize entries memory after allocation.

Exploitation of the flaw would require an attacker to provide crafted input within EXIF data and submit it to be parsed by libexif. In cases where libexif parses untrusted files, an attacker may be unauthenticated or have low privileges.

Comment 4 errata-xmlrpc 2020-09-29 20:50:43 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2020:4040 https://access.redhat.com/errata/RHSA-2020:4040

Comment 5 Product Security DevOps Team 2020-09-29 22:01:26 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-13113

Comment 6 errata-xmlrpc 2020-11-04 03:43:18 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2020:4766 https://access.redhat.com/errata/RHSA-2020:4766


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