[ad_1]

MSI

More than 290 MSI motherboards are said to be affected by insecure default UEFI Secure Boot settings that allow any operating system image to run, whether or not it has a faulty or missing signature.

This discovery comes from a Polish security researcher named Dawid Potocki, who claims he hasn’t received a response despite his efforts to contact MSI and inform them of the issue.

According to Potocki, the issue affects many Intel and AMD-based MSI motherboards that use a recent firmware version, even affecting brand new MSI motherboard models.

UEFI Secure Boot

Secure Boot is a security feature built into the firmware of UEFI motherboards that ensures that only trusted (signed) software can run during the boot process.

“When the PC boots, the firmware verifies the signature of every bootable software, including UEFI firmware drivers (also known as option ROMs), EFI applications, and the operating system,” Microsoft explains in a statement. article about Secure Boot.

“If the signatures are valid, the PC boots and the firmware gives control to the operating system.”

To validate the security of boot loaders, operating system kernels, and other critical system components, Secure Boot verifies the PKI (public key infrastructure) that authenticates software and determines its validity at each boot.

If the software is unsigned or if its signature has changed, perhaps because it has been modified, the boot process will be stopped by Secure Boot to protect the data stored on the computer.

This security system is designed to prevent UEFI bootkits/rootkits (1, 2, 3) to launch on the computer and warn users that their operating system has been tampered with after the vendor ships the system.

Default MSI settings cause insecure boots

Potocki claims that MSI’s firmware update version ‘7C02v3C’, released on January 18, 2022, changed a default secure boot setting on MSI motherboards so that the system boots even if it detects security violations. security.

“I decided to configure Secure Boot on my new desktop using sbctl. Unfortunately, I found that my firmware accepted all OS images I gave it, whether trusted or no”, explains the researcher in his writing.

“As I later found out on 12/16/2022, it wasn’t just faulty firmware; MSI had changed its secure boot defaults to allow booting in the event of a security breach. (!!).”

This change by MSI was to mistakenly set the “Image Execution Policy” setting in the firmware to “Always Execute” by default, allowing any image to boot the device normally.

Insecure default setting on latest MSI firmware
Insecure default setting on latest MSI firmware
Source: dawidpotocki.com

As you can see from the image above, even though Secure Boot is enabled, its “Image Execution Policy” setting is set to “Always Run”, which allows the system to boot even if security breach.

This effectively breaks the Secure Boot feature, as untrusted images can still be used to boot the device.

Potocki explains that users should set the execution policy to “Deny Execute” for “Removable Media” and “Fixed Media”, which should only allow signed software to start.

Changing the insecure option
Changing the insecure option (dawidpotocki.com)

The researcher claims that MSI never documented the change, so he had to trace the introduction of the insecure default using IFR (UEFI Internal Form Representation) to extract information about configuration options.

Potocki then used this information to determine which MSI motherboards were affected by the problem. A full list of over 290 motherboards affected by this insecure setting is available on GitHub.

If you are using an MSI motherboard from this list, go to BIOS settings and check that “Image Execution Policy” is set to a safe option.

If you haven’t updated your motherboard firmware since January 2022, introducing a bad defect shouldn’t be a reason to put it off any longer, as software updates contain important security fixes. .

BleepingComputer has contacted MSI to request a comment on the above and if they plan to change the default setting via a new update, but we are still awaiting a response.

[ad_2]

Source link