On Wed, Apr 17, 2019 at 10:08:51PM -0000, dann frazier wrote:
> > 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?

Here's the CVEs that we triaged against edk2:

CVE-2014-4859
CVE-2014-4860
CVE-2018-12178
CVE-2018-12179
CVE-2018-12180
CVE-2018-12181
CVE-2018-12182
CVE-2018-12183
CVE-2018-3613
CVE-2018-3630
CVE-2019-0160
CVE-2019-0161

And the corresponding list of URLs for these issues in our database:

https://people.canonical.com/~ubuntu-security/cve/CVE-2014-4859
https://people.canonical.com/~ubuntu-security/cve/CVE-2014-4860
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-12178
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-12179
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-12180
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-12181
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-12182
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-12183
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-3613
https://people.canonical.com/~ubuntu-security/cve/CVE-2018-3630
https://people.canonical.com/~ubuntu-security/cve/CVE-2019-0160
https://people.canonical.com/~ubuntu-security/cve/CVE-2019-0161

Here's the CVEs that we may have mis-triaged:

CVE-2017-14872 # Tianocore EDK2 sources
CVE-2017-14893 # Tianocore EDK2 sources
CVE-2017-15824 # Android EDK2 bootloader
CVE-2017-18158 # Android EDK2 flashing
CVE-2017-18159 # Android EDK2 StrHwPlatform handling
CVE-2018-5887 # Android edk2 usb
CVE-2018-5888 # Android edk2 Qcom boot
CVE-2018-5889 # Android edk2 Qcom boot

And corresponding links to Debian's CVE database (often much more useful
than ours when we don't have the issue in our database).

https://security-tracker.debian.org/tracker/CVE-2017-14872
https://security-tracker.debian.org/tracker/CVE-2017-14893
https://security-tracker.debian.org/tracker/CVE-2017-15824
https://security-tracker.debian.org/tracker/CVE-2017-18158
https://security-tracker.debian.org/tracker/CVE-2017-18159
https://security-tracker.debian.org/tracker/CVE-2018-5887
https://security-tracker.debian.org/tracker/CVE-2018-5888
https://security-tracker.debian.org/tracker/CVE-2018-5889

> > 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.

Thanks! This would be wonderful.

> > - It's difficult to tell if subprocesses are spawned
> 
> You can certainly run EFI apps in it, so in a sense....

The concern is mostly around applications that just use system(3) or
similar string-based mechanisms to execute new processes. The clear
majority of applications that use system(3) introduce security flaws or
reliability problems. execve(2) and similar array-based mechanisms are the
safe approach to executing new processes.

I don't know if EFI offers a similar API that is so easily misused. I
expect it's a vastly different environment to the point that this isn't
really an issue.

My "difficult to tell" is that in the typical unix-ish sources vendored
into the codebase are *loads* of process execution tools, and tracking
them all through to potential calls in EFI-space would be quite an
undertaking, with likely very little benefit. So I skipped it.

> > - 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

Would this allow one guest to corrupt the runtime of other running guests?
future guests? or just itself?

> > 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.

Does the hypervisor owner consider edk2 to be part of the guest, and
thus distrust it completely?

Does the guest owner consider edk2 to be part of the host, and thus
trust it completely?

> > 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.....

It's more a team-level obligation; it's not as formal as a team bug
subscriber, but we've got to have a way to determine which issues are
important to our users, and which issues aren't worth the risk of
introducing regressions.

> > 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?

This should also be a team-level obligation. The risk of any individual
getting sick of computers and becoming a turnip farmer is just too high. :)

> 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.

This would be wonderful indeed -- if it could help provide SRU confidence
and security update confidence, notice failures in dependencies, etc.,
that would pay dividends well beyond just testing when we ask for it.

Thanks