CVE-2017-3197: GIGABYTE UEFI security problems

What’s this? No more info, but it almost looks like someone at MITRE ran CHIPSEC against a GIGABYTE box and found some failures, so assigned a CVE. Too bad MITRE doesn’t have boxes from ALL OEMs. Maybe this is something more than simple CHIPSEC failures, but the CVE omits details…

GIGABYTE BRIX UEFI firmware for the GB-BSi7H-6500 (version F6) and GB-BXi7-5775 (version F2) platforms does not securely implement BIOSWE, BLE, SMM_BWP, and PRx features. As a result, the BIOS is not protected from arbitrary write access and may permit modifications to the SPI flash.

 

https://nvd.nist.gov/vuln/detail/CVE-2017-3197

Gigabyte update for Intel AMT vulnerability

https://www.gigabyte.com/Press/News/1562

 

GIGABYTE Updating BIOS for Q270 and Q170 Series Motherboards in Response to Intel Updates

2017/07/12

Taipei, Taiwan, July 12th, 2017 – GIGABYTE TECHNOLOGY Co. Ltd., a leading manufacturer of motherboards and graphics cards, announces that it is in the process to update BIOS for Q270, Q170, and X170-WS ECC Series Motherboards. Based on latest Intel ME firmware updates, GIGABYTE will update BIOS for Q270 and models of previous chipsets accordingly to ensure the models meet latest security standards. GIGABYTE updated the BIOS for X170, X150, B150 and B250 models that are already available on GBT website. On the other hand, GIGABYTE is also updating Q87, Q85, B85, and other impacted models. The updates will be available shortly on the GBT website. For updates to these Motherboards please visit their respective product pages or speak with your technical support team for assistance. GIGABYTE strives to make sure users receive the best-in-class performance while maintaining the upmost security for all products.

http://techreport.com/news/32237/gigabyte-begins-rolling-out-bios-updates-to-close-intel-amt-hole

https://www.eteknix.com/gigabyte-bios-fix-intel-mangeability/

AMI and Gigabyte UEFI vulnerability

I wish more user-mode security researchers would study how OEM/IBV/OSV implementations of UEFI firmware update, from the OS-present appplication, looking for problems. For example: https://firmwaresecurity.com/2016/06/05/asus-liveupdate-of-uefi-sent-authenticated/

Gigabyte UEFI firmware advisory

It must be big if CERT notices a UEFI issue! 🙂

https://www.cylance.com/en_us/blog/uefi-ransomware-full-disclosure-at-black-hat-asia.html

 

new resource: Broken UEFI Implementations wiki

Watch this site to grow over time (and contribute to it, if you can help):
http://wiki.osdev.org/Broken_UEFI_implementations
http://wiki.osdev.org/index.php?title=Broken_UEFI_implementations&action=history

Apple, Lenovo, GIGABYTE: note that there’s some stuff about your products in the initial database.

As mentioned earlier:
https://firmwaresecurity.com/2015/08/05/debian-calls-for-uefi-packaging-help/
https://firmwaresecurity.com/2015/08/13/intel-update-on-debian-and-uefi/

Steve McIntyre of the Debian project is working with other open source OS developers to maintain a list of broken UEFI implementations, to help OS vendors:

I’ve been talking to a number of other UEFI developers lately, and we’ve agreed to start a cross-distro resource to help here – a list of known-broken UEFI implementations so that we can share our experiences. The place for this in in the OSDev wiki at http://wiki.osdev.org/Broken_UEFI_implementations. We’re going to be adding new information here as we find it. If you’ve got a particular UEFI horror story on your own broken system, then please either add details there or let me know and I’ll try to do it for you.

See Steve’s blog post for more information:
http://blog.einval.com/2015/08/02