| Summary: | <sys-apps/iucode_tool-2.1.1: heap buffer overflow on -tr loader | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | base-system, robbat2 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2017/01/13/12 | ||
| Whiteboard: | B3 [noglsa cve] | ||
| Package list: | Runtime testing required: | --- | |
*** Bug 607218 has been marked as a duplicate of this bug. *** 2.1.1 stable on amd64/x86 No ACE/RCE, downgraded to B3. GLSA Vote: No @ Maintainer(s): Please cleanup and drop <sys-apps/iucode_tool-2.1.1! Cleanup PR: https://github.com/gentoo/gentoo/pull/4855 Repository is now clean, all done. |
From ${URL} : CVE-2017-0357: iucode-tool: heap buffer overflow on -tr loader Project URL: https://gitlab.com/iucode-tool/iucode-tool Tracker for this Issue: https://gitlab.com/iucode-tool/iucode-tool/issues/3 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 caution. -- Henrique Holschuh From: Henrique de Moraes Holschuh <hmh@....eng.br> Date: Sat, 7 Jan 2017 17:12:04 -0200 Subject: CVE-2017-0357: iucode_tool: fix heap buffer overflow on -tr loader When the last microcode region ends at exactly the end of a data file *being loaded using the -tr loader*, intel_ucode_scan_for_microcode() would read data past the end of the memory buffer. It is likely possible for an attacker to use this bug to trigger heap corruption using specially crafted data file(s), possibly also requiring a specially crafted command line. The heap corruption might be exploitable depending on libc details, and could lead to code execution. This issue was fixed in iucode_tool v2.1.1. This issue is present in iucode_tool v1.4, up to an including v2.1. --- intel_microcode.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/intel_microcode.c b/intel_microcode.c index 7ce575b..c094c66 100644 --- a/intel_microcode.c +++ b/intel_microcode.c @@ -532,6 +532,10 @@ int intel_ucode_scan_for_microcode(const void **bs, const void **be, bl += total_size; al -= total_size; + /* xx_intel_ucode_check_uc() before v2.1.1 special-cases al == 0 */ + if (!al) + break; + r = xx_intel_ucode_check_uc(p, al, 0); } while (r == INTEL_UCODE_NOERROR); @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.