Bug 1019946 - (CVE-2017-0357) VUL-0: CVE-2017-0357: iucode-tool: heap buffer overflow on -tr loader
VUL-0: CVE-2017-0357: iucode-tool: heap buffer overflow on -tr loader
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Other Other
: P3 - Medium : Normal (vote)
: Current
Assigned To: Martin Pluskal
E-mail List
Depends on:
  Show dependency treegraph
Reported: 2017-01-13 17:55 UTC by Mikhail Kasimov
Modified: 2017-01-14 09:00 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

iucode-tool_fix-cve-2017-0357.patch (1.24 KB, patch)
2017-01-13 17:55 UTC, Mikhail Kasimov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mikhail Kasimov 2017-01-13 17:55:29 UTC
Created attachment 710060 [details]

Ref: http://seclists.org/oss-sec/2017/q1/87
CVE-2017-0357: iucode-tool: heap buffer overflow on -tr loader

Project URL:

Tracker for this Issue:

Versions affected:
iucode_tool 1.4, up to and including 2.1

iucode_tool is a program to manipulate microcode update collections for
Intel(R) i686 and X86-64 system processors, and prepare them for use by
the Linux kernel.

This bug affects a somewhat obscure feature of iucode_tool, the
microcode recovery loader, accessed through the "-tr" command line
switch.  The microcode recovery loader is typically used to inspect or
extract microcodes directly from kernel images, initramfs images, etc.

This loader works by reading the entire datafile in memory (it imposes a
hard limit of 1GiB worth of data), then scanning that memory forwards
for microcode regions (a region is one or more microcodes adjacent to
each other), and packing any it finds at the beginning of the memory
buffer to create a single microcode region.  When it finishes, it
realloc()s the memory buffer to its new (likely smaller) size.

When a valid microcode is present at the end of the data file and there
is no extra data after it, intel_ucode_scan_for_microcode() would fail
to detect the end-of-buffer situation, and read data past the end of the
memory buffer looking for an *adjacent* valid microcode.

This is usually harmless, as typically there will not be a valid
microcode update exactly right past the end of the memory buffer.

Unfortunately, should there be a valid microcode exactly after the
memory buffer, iucode_tool will misbehave.  A SIGSEGV is the best result
one could expect.  Heap corruption can happen if further, non-adjacent
microcodes are found in memory as iucode_tool will use memmove() to
compact them into a single region, possibly overwiting the heap memory
past the end of the buffer.

The heap buffer overflow (but not the heap corruption) is trivially
triggered by using the -tr (recovery) loader on proper binary microcode
data files:

"iucode_tool -tr /lib/firmware/intel-ucode"

The heap buffer overflow can be detected by Valgrind's memcheck, or by
instrumenting iucode_tool using -fsanitize=address under gcc or clang.

Exploiting the bug:

It might be possible for an attacker to force a heap corruption with
attacker-supplied data by using a number of specially crafted data
files.  This might also require tricking the user into using a specially
crafted command line.

The number of specially crafted data files required is a minimum of two,
but it depends on how unpredictable the data written by glibc's heap
implementation is.  It could be quite large, or quite small.

If iucode_tool is linked to a libc that won't change data in the free'd
or realloc'd heap chunks the way modern glibc typically does by default,
triggering the attacker-controlled heap corruption might be trivial.
Tuning glibc's malloc() behavior might also change things.

I am no expert in exploiting glibc heap corruption.  I have assumed it
is possible to leverage it into shellcode execution in the name of

  Henrique Holschuh


TW: 2.1 (official release)
42.2: 2.1 (hardware repo)
42.1: 2.1 (hardware repo)
13.2: 2.1 (hardware repo)
Comment 1 Swamp Workflow Management 2017-01-13 23:01:23 UTC
bugbot adjusting priority
Comment 2 Martin Pluskal 2017-01-14 07:56:41 UTC
Thanks for report, updated to version 2.1.1 which fixes this issue and submitted to Factory.
Comment 3 Bernhard Wiedemann 2017-01-14 09:00:40 UTC
This is an autogenerated message for OBS integration:
This bug (1019946) was mentioned in
https://build.opensuse.org/request/show/450296 Factory / iucode-tool