Inquiry Regarding LogoFAIL Vulnerability Impact on Dasharo and Dasharo Configuration Utility

[pietrushnic]

Dasharo version

Any

Dasharo variant

Any

Question text

In CVE-2023-40238 and highlighted in various industry publications. This vulnerability affects image parsing libraries in system firmware and poses a significant security risk, capable of bypassing Secure Boot, Intel Boot Guard, and other critical security measures.

In this context, I would like to address the following questions to our team and the broader community:

1. Have we conducted an assessment to determine if Dasharo and the Dasharo Configuration Utility are impacted by the LogoFAIL vulnerability? If yes, where are the deliverables of that assessment? If not, then when do we plan to do that?
2. If we are affected, what steps are we currently taking or planning to take to mitigate this vulnerability in our products?
3. What guidance or updates can we provide to our users to ensure they are protected against potential exploits stemming from this vulnerability?

[sycam0r-e]

The LogoFAIL firmware attack and some background are nicely explained in this Arstechnica article.

The article notes that the LogoFAIL vulnerabilities are tracked via the following CVEs (an incomplete list though):

• CVE-2023-5058
• CVE-2023-39538
• CVE-2023-39539
• CVE-2023-40238

---

It also hints towards a possible way to check for infection:

One clue of compromise, however, can be provided by examining the image file that’s parsed during bootup. If the cryptographic hash of that file differs from the hash of the file that device manufacturers typically make available for free, the device can be further analyzed to check for signs that it has been exploited.

That would neccessitate that:

• every machine provider (e.g. @wessel-novacustom) publishes their standard boot image files, and
• Dasharo puts out a little guide on where the image file that's parsed during bootup lives on the machine Then, users could verify the cryptographic hashes.

---

The article also enumerates some other firmware vulnerabilities. I wonder wether Dasharo is affected by those?

[renehoj]

I'm assuming that not load an image would permanently solve the issue, would it be possible to add an option to completely disable the use of boot art?

A nice to have feature could be some form of ASCII boot art, if the image is disabled.

[mkopec]

Note that the vulnerabilities affect IBV-specific image parsers, we only use EDK2's BMP parser which has presumably been reviewed by more eyes (and wasn't mentioned in the original vulnerability announcement)

We store the logo in an unverified CBFS region and load it into CBMEM along with the size of the file. Someone could place a crafted logo there to potentially exploit the CBMEM allocator, I don't know how secure that code is. Still, doing so would require HW access (as long as SMM BWP is enabled)

[pietrushnic]

Note that the vulnerabilities affect IBV-specific image parsers, we only use EDK2's BMP parser which has presumably been reviewed by more eyes (and wasn't mentioned in the original vulnerability announcement)

That's good to know, but it would be great if we could test it. We are not on UEFI security lists, so maybe something is going on there. It is worth checking the history of the EDK II, especially because we use the old version, as well as issues in the Tianocore bug tracker to verify if there is nothing going on.

Although this list does contain just one issue.

[pietrushnic]

[pietrushnic]

Let's confirm that we use parser that does not contain vulnerability.

[mkopec]

The parser has been untouched since the commit indicated in the tweet, for 2 years: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c

We use the TranslateBmpToGopBlt func from that library exactly here so I can say we use the parser library that does not include the vulnerability.

We also have some custom code for loading the logo from coreboot and I do not know how secure that code is: https://github.com/Dasharo/edk2/blob/dasharo/UefiPayloadPkg/Library/CbParseLib/CbParseLib.c#L662

[pietrushnic]

@miczyg1 can you confirm that @mkopec thinking is correct? If yes we can inform our customers about that fact @macpijan @BeataZdunczyk cc

[macpijan]

for 2 years: https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c

We use a bit older revision of this code, but I am not sure if this particular commit contains some security fix.

@pietrushnic All of the mentioned vulnerabilities in this thread relate to some proprietary parsers provided by different IBVs. I could not find any related to the edk2 BmpSupportLib, which we are using. So as of today, there is no known vulnerability in this area for Dasharo.

[pietrushnic]

@macpijan If a bit older version contains this input sanitization in the same form as the current version, we should be reasonably safe, according to what Alex wrote. The best is to have an exploit or scan with Binarly. They also provide some free scanning for LVFS.

[pietrushnic]

I can't see rules for that vulnerability here, but maybe we should consider the use of fwhunt community scanner.

[macpijan]

I can't see rules for that vulnerability here, but maybe we should consider the use of fwhunt community scanner.

The community scanner is a tool using rules from the first link. If there is no rule for the given vulnerability, it will not prove it is not there I am afraid.

[pietrushnic]

The community scanner is a tool using rules from the first link. If there is no rule for the given vulnerability, it will not prove it is not there I am afraid.

I would not expect that, but we could use what is already three to mitigate whatever we may have. Later, there may be an update on the rules, or we will discuss them with Binary and obtain one. Also I guess if one would understand what is going on behind the scene we could write rules ourselves.

[miczyg1]

@miczyg1 can you confirm that @mkopec thinking is correct? If yes we can inform our customers about that fact @macpijan @BeataZdunczyk cc

I have been suspecting that from the beginning (even before the issue was raised here). See Dasharo General 4th Dec

[macpijan]

would not expect that

This is what README and the tool parameters say.

Later, there may be an update on the rules, or we will discuss them with Binary and obtain one

Sure, no one is denying there can be update. This is a bit off-topic already here, but I gave a quick run on this tool.

On the whole binary:

docker run --rm -it -v ./msi_ms7d25_v1.1.3_ddr5.rom:/tmp/image:ro -v ./../FwHunt/:/tmp/rules:ro \ 
  fwhunt_scan scan-firmware /tmp/image --rules_dir /tmp/rules
Scanner result IntelAlderLakeLeak (variant: default) No threat detected
Scanner result BRLY-MsiLeakBootGuardKeys (variant: default) No threat detected
Scanner result MsiLeakFwCapsuleKeys (variant: default) No threat detected
Scanner result OemUnlockKeyLeak (variant: default) No threat detected
[I] Specify volume_guids in IntelAlderLakeLeak or use scan command
[I] Specify volume_guids in BRLY-MsiLeakBootGuardKeys or use scan command
[I] Specify volume_guids in MsiLeakFwCapsuleKeys or use scan command
[I] Specify volume_guids in OemUnlockKeyLeak or use scan command
[I] Specify volume_guids in ESPecter or use scan command
No modules were found for scanning

On the edk2 payload:

docker run --rm -it -v ./UEFIPAYLOAD.fd:/tmp/image:ro -v ./../FwHunt/:/tmp/rules:ro \
  fwhunt_scan scan-firmware /tmp/image --rules_dir /tmp/rules
Scanner result IntelAlderLakeLeak (variant: default) No threat detected
Scanner result BRLY-MsiLeakBootGuardKeys (variant: default) No threat detected
Scanner result MsiLeakFwCapsuleKeys (variant: default) No threat detected
Scanner result OemUnlockKeyLeak (variant: default) No threat detected
[I] Specify volume_guids in IntelAlderLakeLeak or use scan command
[I] Specify volume_guids in BRLY-MsiLeakBootGuardKeys or use scan command
[I] Specify volume_guids in MsiLeakFwCapsuleKeys or use scan command
[I] Specify volume_guids in OemUnlockKeyLeak or use scan command
[I] Specify volume_guids in ESPecter or use scan command
Scanner result BRLY-2021-010 (variant: variant1) No threat detected (NvmExpressDxe)
Scanner result BRLY-2021-010 (variant: variant2) No threat detected (NvmExpressDxe)
Scanner result BRLY-2021-017 (variant: default) No threat detected (NvmExpressDxe)
Scanner result BRLY-2021-030 (variant: default) No threat detected (NvmExpressDxe)

[macpijan]

Yet another way to look at it:

1. Binarly claims here that https://github.com/tianocore/edk2/blob/cee7ba349c0c1ce489001a338a4e28555728b573/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c is not affected, so presumably they have analyzed it thoroughly.
2. We are using one commit older: https://github.com/tianocore/edk2/commit/9d510e61fceee7b92955ef9a3c20343752d8ce3f
3. The commit from point 1. introduces 100k additions and deletions, so it is not that easy to verify what exactly it changes. The commit message says it changes only the code style, and it looks like it does. If we trust this to be the case, then the same analysis from point 1 should apply to our commit as well.

So this is yet another perspective on the fact that Dasharo is not affected (other than the fact that there is no CVE against edk2 in that area, there are only CVEs against proprietary parsers).

To sum it up, Dasharo firmware products are not vulnerable to LogoFail type of attacks known publicly as of today,

[pietrushnic]

The commit from point 1. introduces 100k additions and deletions, so it is not that easy to verify what exactly it changes. The commit message says it changes only the code style, and it looks like it does. If we trust this to be the case, then the same analysis from point 1 should apply to our commit as well.

Congratulations to those who did a sanity check of that repository. Github search dies in my browser.

git is easy:

git show 9d510e61fceee7b92955ef9a3c20343752d8ce3f MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c

commit 9d510e61fceee7b92955ef9a3c20343752d8ce3f
Author: Michael D Kinney <michael.d.kinney@intel.com>
Date:   Wed Apr 3 16:05:13 2019 -0700

    MdeModulePkg: Replace BSD License with BSD+Patent License

    https://bugzilla.tianocore.org/show_bug.cgi?id=1373

    Replace BSD 2-Clause License with BSD+Patent License.  This change is
    based on the following emails:

      https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
      https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html

    RFCs with detailed process for the license change:

      V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
      V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
      V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html

    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
    Reviewed-by: Hao Wu <hao.a.wu@intel.com>
    Reviewed-by: Jian J Wang <jian.j.wang@intel.com>

diff --git a/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c b/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
index 6196262d143b..3ac31f6723d0 100644
--- a/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
+++ b/MdeModulePkg/Library/BaseBmpSupportLib/BmpSupportLib.c
@@ -14,24 +14,7 @@
   Copyright (c) 2018, Intel Corporation. All rights reserved.<BR>

   All rights reserved.
-  Redistribution and use in source and binary forms, with or without
-  modification, are permitted provided that the following conditions are met:
-  1. Redistributions of source code must retain the above copyright notice,
-  this list of conditions and the following disclaimer.
-  2. Redistributions in binary form must reproduce the above copyright notice,
-  this list of conditions and the following disclaimer in the documentation
-  and/or other materials provided with the distribution.
-
-  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
-  ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
-  WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
-  IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
-  INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
-  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
-  LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
-  OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
-  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+  SPDX-License-Identifier: BSD-2-Clause-Patent^M

 **/