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 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14872 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14893 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-15824 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-18158 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-18159 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12178 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12179 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12180 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12181 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12182 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-12183 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-3613 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-3630 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-5887 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-5888 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-5889 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-0160 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-0161 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. 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 -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
