oss-sec mailing list archives

shim RCE


From: Sebastian Krahmer <krahmer () suse de>
Date: Mon, 13 Oct 2014 14:49:51 +0200

Hi

As per policy-request, here is the oss-posting of what has
formerly been negotiated on distros@. Initial CRD was Oct 6th
but has been shellshokshifted to today upon request.

--

We reviewed some parts of the shim trusted bootloader.
Shim is responsible for verifying of - and chaining into - a
next level bootloader. Shim itself is signed by MS so it can
be loaded by UEFI secure boot aware boards.
These vulnerabilities could be exploited to bypass
"secure boot" with leverage up to OS level.

We found three issues that should be fixed:

1. OOB read access when parsing DHCPv6 packets (remote DoS).
   The severity is low. (CVE-2014-3675)
2. Heap overflow when parsing IPv6 addresses provided by tftp:// DHCPv6
   boot option (RCE).
   The severity is low to medium, as secure boot via PXE6 should
   rarely be seen ITW. Furthermore UEFI firmware seems to fail
   to properly verify provided PXE images at the first place. (CVE-2014-3676)

For both issues above there is a patch proposal:

http://suse.com/~krahmer/priv/shim1.diff

3. Memory corruption when processing user provided MOK lists.
   Its unclear whether this could lead to a code execution in
   the secure boot path. (CVE-2014-3677)

For this issue there is also a patch proposal:

http://suse.com/~krahmer/priv/shim2.diff

All three issues should receive a CVE each. We ask for a CRD
of Oct 6th. 2014.

When updating, vendors should also take care to include
git commit 45ab8962ae7c8e860a45d195cfe8a3f4d8aec4c7 since this
already fixes another overflow (different from 2.) when parsing
DHCPv6 packets.

We did _not_ conduct a full code review of shim. In particular
PE header parsing and relocating of PE EFI images is left untouched.

Upstream maintainers have been informed already, as well as MS
to initiate the signing process of a patched shim.

It's unfortunate for Open Source vendors to rely on a third party
being a milestone in an update process since its adds hereto
a lot of complexity in the coordination and updating process.


Sebastian

-- 

~ perl self.pl
~ $_='print"\$_=\47$_\47;eval"';eval
~ krahmer () suse de - SuSE Security Team


Current thread: