On Fri, Apr 12, 2019 at 9:54 PM Seth Arnold <email address hidden> wrote:
>
> I reviewed edk2 version 0~20181115.85588389-2ubuntu1 as checked into
> disco. This review barely scratches the surface of the package.
>
> It appears there's roughly 20 CVEs for sources in this package. We've
> accidentally mis-filed eight of them.

Can you point me to them?

> This package provides a boot environment; I must admit that I don't
> understand it well.

Happy to answer questions or demo it for you - just let me know.

> - Build-Depends: debhelper, uuid-dev, iasl, gcc-multilib [i386], nasm,
>   python, gcc-aarch64-linux-gnu, gcc-arm-linux-gnueabihf, genisoimage,
>   qemu-utils, qemu-system-x86, python3
>
> - Embeds OpenSSL cryptographic library
> - Probably doesn't daemonize

Correct

> - Probably doesn't listen on the network
>   - However, it includes many network client services, likely to use
>     during PXE booting or similar
> - No pre/post inst/rm
> - No init scripts
> - No systemd unit files
> - No dbus services
> - No binaries in PATH
> - No sudo fragments
> - No udev rules
> - Probably no test suite

No built-in one, but see below...

> - No cron jobs
> - Build logs use -Werror -- the logs give misleading impression.
>
> - It's difficult to tell if subprocesses are spawned

You can certainly run EFI apps in it, so in a sense....

> - Memory management varies; cppcheck finds many faults, but they may not
>   be in code that matters
> - Extensive file IO, it's difficult to tell how much would happen in the
>   context of a host vs a guest

While I consider it more of a QEMU vector than edk2 itself, it is
possible for this firmware, or EFI apps it runs, to access devices on
the host if QEMU allows it. For example, we have seen bugs[1][2] where
shim in a guest corrupts the guest's firmware image on the host. But
that's only possible because QEMU was given write access to that
image.

[1] https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1811901
[2] https://bugs.launchpad.net/ubuntu/+source/shim-signed/+bug/1811722

> - Extensive logging, spot checks showed no unsafe logging
> - Extensive cryptography, entirely unchecked
> - I didn't discover privileged vs unprivileged portions of code
> - Some privileged operations in the code but many appear to be available
>   as platform services
> - One instance of an unsafe write to /tmp/col in Oniguruma regular
>   expression engine. It is probably ifdef'd out.
> - No WebKit
> - No PolicyKit
> - Many cppcheck results reporting real bugs.
>
> This codebase is huge. I'm still not clear on what most of it is used for,
> or what threat model is assumed.

One security-relevant thing to note is that edk2 will be responsible
for the firmware-aspect of SecureBoot for QEMU guests booted in
SecureBoot mode.

> Code quality looked mixed: cppcheck reported a lot more results than I'd
> like to see, but the code I studied via the uaudit greps was high quality.
>
> In order to properly support edk2, the security team will need help from
> other teams. So, the security team is providing a provisional ACK for
> promoting edk2 to main once the following conditions are met:
>
> First, Dann has volunteered to strip out the Pythons, Lua, pccts, and
> perhaps other smaller pieces as testing indicates that they can be
> removed. We'd like these stripped before moving the package to main.

Yep - on my todo list for 19.10 devel.

> Second, someone needs to commit to working with the security team to
> properly triage edk2 issues as they arise.

I volunteer for this, but of course, I alone would be a SPOF.....

> Third, someone needs to commit to testing packages that the security team
> prepares for our stable releases, for whatever lifetime is appropriate.
> (If, in six years, edk2 is included in 20.04 LTS's ESM offering due to
> customer interest, this team will need to commit to helping test 20.04's
> EDK2 until 2030, or whenever 20.04 LTS's ESM support offering comes to
> a close, as well as all future LTS releases that include edk2 in main.)

I can't personally commit to, well, anything for 10 years :) I wonder
if the server or foundations teams would be willing to "host" this
responsibility, with me owning it on their behalf for now?

Also, could the testing issue be solved w/ an automated test suite?
I've been wanting to find the time to implement one anyway. I'm not
sure yet if this could be done well w/ autopkgtest - ideally we'd be
able to test e.g. Windows guests, and I haven't looked into how
feasible that would be in the autopkgtest framework.

  -dann


> Please comment in this bug to sign up for these obligations.
>
> Thanks
>
>
> ** Changed in: edk2 (Ubuntu)
>      Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1570617
>
> Title:
>   [MIR] edk2
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1570617/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=edk2; component=universe; status=Confirmed; importance=Undecided; assignee=None;
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability: no
> Launchpad-Bug-Commenters: dannf emilyr janitor leif-lindholm paelzer seth-arnold tyhicks vorlon
> Launchpad-Bug-Reporter: dann frazier (dannf)
> Launchpad-Bug-Modifier: Seth Arnold (seth-arnold)
> Launchpad-Message-Rationale: Subscriber
> Launchpad-Message-For: dannf