Gigabytes the Dust with UEFI Vulnerabilities

At this year’s BlackHat Asia security conference, researchers from Cylance disclosed two potentially fatal flaws in the UEFI firmware of Gigabyte BRIX small computers which allow a would-be attacker unfettered low-level access to the computer.

Gigabyte has been working on a fix since the start of 2017. Gigabyte are preparing to release firmware updates as a matter of urgency to only one of the affected models — GB-BSi7H-6500 (firmware vF6), while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life. We understand that support can’t last forever, but if you sell products with such a big fault from the factory, it might be worth it to fix the problem and keep your reputation.

The two vulnerabilities that have been discovered seem like a massive oversight from Gigabyte, They didn’t enable write protection for their UEFI (CVE-2017-3197), and seem to have thrown cryptography out of the window when it comes to signing their UEFI files (CVE-2017-3198). The latter vulnerability is partly due to not verifying a checksum or using HTTPS in the firmware update process, instead using its insecure sibling HTTP. CERT has issued an official vulnerability note (VU#507496) for both flaws.

Attackers may exploit the vulnerabilities to execute unsigned code in System Management Mode (SMM), planting whatever malware they like into the low level workings of the computer. Cylance explain a possible scenario as follows:

The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system’s firmware.

With all this said, it does raise some interesting opportunities for the hacker community. We wonder if anyone will come up with a custom UEFI for the Brix since Gigabyte left the keys in the door.

46 thoughts on “Gigabytes the Dust with UEFI Vulnerabilities

      1. Correct, It’s about the vulnerability and how it may spark an interest in someone who wants to play around with it, The hardware isn’t really the issue but it may be cool to play with.

      2. Add cars, phones, “smart” TVs etc. Open Hardware should be mandated by law as there is no way to scrutinize what a device does otherwise: an owned device can be used as a weapon.

  1. Mind you this attack vector requires Ring 0 access to begin with, and at that point you are so deeply compromised that getting the attacker out requires setting the building on fire.

    1. That’s the impression I got, that if an attacker already had OS level access they could update the system ROM with code the manufacturer didn’t sign off on. So if an attacker managed to get that deep it may be harder to clean the system even with a wipe of the HD. On the other hand, the computer’s owner may want to customize the ROM, which the security updates may prevent.

      1. Wiping the hard drive will no nothing but waste your time, when it is stored as a new extension in flash “didn’t enable write protection for their UEFI”. (UEFI stands for Unified EXTENSIBLE Firmware Interface).

        1. Yeah, not setting the registers correctly is the big fail here, and it’s not the first time an OEM has failed to program protection registers like this correctly.

          For UEFI, this is why thing like chipsec and SCT are out there. We are just seeing security researchers realize that they can work on these low levels of PCs now (everything is largely based on the EDK2 project at this point, but the independent BIOS vendors still add their own ‘secret sauce’ to the mix).

          To wipe a hack like this would entail using something like a dediprog to reflash the chip, but unless the OEM made it in circuit programmable, it could mean the chip would have to be pulled to program it.

          1. @Senji: That’s one way development is done now. An OEM gets boards in an replaces the flash parts with sockets. The parts are usually some sort of SOIC 8 or SOIC 16 package so they aren’t that bad to desolder. The sockets are a bit more exotic (I don’t have any part numbers off the top of my head), but they are pretty easy to put in place of the chip. Then a developer can brick a system as many times as he/she needs to in a day.

            But look at This is pretty much the recommended flasher in the PC industry (and they are pretty cheap too for the curious hardware hacker/researcher). I don’t know if the docs are available online or if they are just on a CD shipped with eh flasher, but they detail the circuitry requirements for performing in circuit programing and they offer a chip interposer clip.

            This might be enough info to get someone started on tinkering with their board at a very low level. But if someone were to do so, I’d strongly advise they get the Intel PCH data sheet for their board to read up on descriptor mode, and to get a copy of the platform initialization spec from to help make sense of the BIOS flash image.

      2. And this isn’t new – in the old days (not even that old, actually – like late 90’s to mid 2000’s) BIOSes were not that hard to fool with modified firmware, and a lot of people baked their own firmware to add or remove certain features.

        You didn’t need to bypass some fancy security system, just figure out how the checksum worked and where it was located, and make sure your new file had the proper checksum.

    2. Perfect for getting to the board en route or before leaving the distributors, just like how our three letter friends like it. Since they will claim it’s hard to exploit and therefore have justification to not disclose.

  2. Stupid question, why even allow update of the system bios through local in-circuit software without a physical gate, like a dip switch? eg. flip the switch one way to have everything 100% the way it is today. Flip it the other way and you have a hardware write protect inhibit. Seems like a logical (and pretty well secure) solution to me at least…

      1. And to be totally fair that one little jumper on the motherboard, terrified a lot of non technical people from entertaining the merest possibility of ever considering upgrading the firmware. Having to open the cover and look for that jumper, no matter how well documented, is totally outside their comfort zone.

          1. I digress from your point in my experience.

            I give clear instructions to press the button on the front case and some people think that means play around with the cables on the back!!!

            OK, admittedly only those whom seem particularly handicapped regarding technology, like around 20% to 30% of the town I live in, again: experience based opinion here

        1. I recently got both a new phone and a new Bluetooth speaker. The phone came with a metal pin that you have to insert to eject the sim carrier, and the speaker came with a similar pin to poke a button to change the language.

          I bet that it would not be that hard to have a hole in the back that you push a paperclip into to initiate a UEFI update.

          1. Galane,
            Too obvious to the point the genius man missed it.

            Anyway, I know a couple people whom when they purchased a pre-built gaming machine (MSI I think, don’t remember it being Alienware), they (Gonna refer to one for now) clicked on that click-bait flashing-gif advert on dodgy sites that told him his computer was running too slow and it’ll speed up his computer…. needless to say the virus slowed down the PC and occasionally popped up saying to pay for the PRO version (Hence I call all those adverts SuperUltraExtreme Pro Edition software).
            Had to reinstall from the recovery CDs, though the Virus did improve the speed of one thing: Faster facepalm!

            Now all that is needed is SuperUltraExtreme Pro Edition to tell the victim to press the upgrade firmware button on their PC, because ya know “To Make The PC Feel More Firm! [TM]”

          2. And what would that do, exactly? If the attacker already has ring-0 access, they’ll never manage to pop up an urgent update message instructing users to stick a paper clip in the hole.

          3. That’s HOW they gain Ring 0 access…. The button press makes their virus a little more persistent: I.e. after a wipe and install by a competent friend!

          4. Lenovo laptops (not Thinkpads) already have that, the “one key recovery” button which is used to open the UEFI’s menu. You don’t even have to use a pin or a paperclip to press it if you have small enough fingers.

    1. I’d guess partly convenience (Users not being particularly keen on the idea of cracking open their PC to get at the switch – and if they do, not bothering to set it back again) and saving the combined cost of a DIP switch and a flash with write protection. (Although I seem to remember some Gigabyte motherboards have had a secondary boot flash)

      I’d agree, though, it’d be nice to have the facilities available.

    2. Imagine updating firmware, perhaps in a server-farm environment, where flipping dip switches is just not practical. In consumer-level devices like this one it’d, at the very least, generate support issues because it’d require consumers to open up the appliance to perform the update.

      I haven’t read all the related docs on this particular vulnerability, but this one sounds like strictly a software issue (i.e., software fault that can be fixed in software).

      FWIW, YMMV.

    3. I’m just going to address the ida of a physical switch here. Imagine you are a sysadmin at a company employing some tens of thousands of employees globally both in local offices, and telecommuting workers. You learn of a critical flaw that means firmware needs to be updated. You now have to schedule time slots to physically touch every machine that needs an update.
      Another scenario is in the datacenter. That switch means a significant chunk of time entering the datacenter, locating the server, pulling it out of service, upgrading it, then putting it back in service. We have remote management solutions today that work though without having researchers verify each mechanism, it’s hard to say if these systems are vulnerable. UEFI does specify a standard way to update that part of the firmware and I suspect security researchers have already scrutinized it as well as disclosed vulnerabilities that have been addressed in the EDK2.

      The additional problem is something called NVRAM. The old fashioned CMOS memory found in the old RTC hasn’t been used to store system configuration data for some time. Instead, some number of erase blocks are set aside to store information. So if you write protect the chip with such a switch, you’d end up with a system that would be broken to some degree (especially since SetVariable() is a service the OS can use to put data into firmware NVRAM).

      That’s not to say there isn’t a solution (the spec never says the NVRAM has to be on the same flash part as the code).
      Intel chipsets also have mechanism to lock the flash except for specified blocks. the big fail here is Gigabyte failed to set these registers. I foresee a version of GRUB that will set these registers for the affected boards. Windows would be a bit trickier, but it could still be done.

      I think the biggest issue here is that of labor quality in the business.

      1. But keep the physical inhibit disabled and the situation is exactly what it is today. More enlightened and capable users would have the option to physically lock out updates – benevolent or nefarious. I can certainly quote the above article as an opposing argument, ‘Some researcher discovered a malware attack vector that could root a virus in the system firmware – quick run to every computer and flip the switch.’ – rather than waiting on Gigabytes’ schedule.

        Any-hoo.. Hopefully system architects will learn from this as the main sliver lining.

      2. I’m just going to address the ida of a physical switch here. Imagine you are a sysadmin at a company employing some tens of thousands of employees globally both in local offices, and telecommuting workers. You learn of a critical flaw that means firmware needs to be updated. You now have to schedule time slots to physically touch every machine that needs an update.

        Yep, in that case, you have a pushbutton and shorting jumper/switch. The sysadmins fit the jumper/flick the switch when the hardware is commissioned so the firmware updates always happen without a human present.

        The home users leave the jumper off, either out of personal choice or ignorance.

        Bear in mind that the server is less cost sensitive and the users more technical, so a consumer product might choose to leave off the switch/jumper and just have a push button since it’s an infrequent operation and the extra part costs money/space.

        A server costs more money than the average home computer and are made in smaller volumes, so that switch’s contribution to the total BOM is much smaller.

        Also, given the chance of seriously bricking something if Murphy strikes, this is probably not something that should be done behind the user’s back. Better to have the software direct them to that push button in that case. It can have everything ready so it does the update when the user is ready to perform it. A server is going to be in a more controlled environment, so automatic rollout is more feasible here.

        In short, it can be done. Manufacturers choose not to, and I suspect the reason is financial rather than technical.

        1. The big technical issue of something like pulling a write protect pin is that NVRAM will stop working at all. There are chipset registers that Gigabyte *should* be programed that make most of the flash part unreadable except for the blocks that are used for NVRAM. If you read the article, that’s one thing they are showing from chipsec. And that would have been good enough to stop one attack vector. Fuzzing the SMI handlers and finding a vulnerability is a much bigger deal IMHO. That is where a physical write disable would have been needed, but as I said, it breaks the ability to store system settings.
          I’d honestly like to see some sort of secondary storage system for NVRAM rather than tying it to the main system firmware SPI flash chip. Then you could add a physical write disable to the system. But I’ve been told that’s crazy talk :P

          The constant battle with PCs is between being more like walled off embedded systems that can have good security and more open systems that allow user control. One issue with having more open user control is then needing to have the expertise to understand what is going on. For example, how many users do you figure understand that your system settings are all stored on the system firmware flash part and the legacy ‘cmos’ that was part of the RTC is not really used for much of anything on a modern PC? There is a lot more but you really need to be involved with PC design and manufacturing to learn about these dark corners.
          I am super happy researchers are starting to shine a light on some of this stuff, there are too many programmers in the PC firmware space who need to be taught modern development practices and need to be held accountable.

          1. Yeah, to me, the two-chip solution is The Way… as it avoids the possibility that you might overwrite the wrong flash sector with nasty data… it’s simply not possible because the sector you’d need to write to is physically on another die.
            But, as I say, it’s financial reasons, not technical, that they feel they need to cram it all into one chip and break the concept of a hardware write protect.

            And how often do these settings change?

            Admittedly, the only machine I have that boots EFI normally is a 2008-era MacBook. Everything else I own either uses BIOS natively (because of its age), or is using the legacy compatibility module to boot a BIOS bootloader, because that’s what I understand and for my purposes, it isn’t broken so doesn’t need fixing.

            I can understand settings changing if you install a new OS, but it’s not like people do that every week. The boot firmware (BIOS, UEFI, CoreBoot, u-boot, RedBoot, etc) just needs to know how to load up the next blob, maybe do a signature check on that blob, and execute it, providing a basic interface for the hardware.

            This should not need frequent changes, that to me is just asking for trouble.

  3. Yes. Stupid question.
    Try managing and updating thousands of computers from a central location and see what it would be like if physical interaction was needed every time you need to update or change something.

    1. Well, supplying a case switch and a S/PDIF like socket with a switch behind it instead of an IR transceiver to plug a supplied blank into to enable, clearly marked “Enable Remote BIOS UPDATE”.
      OK some stupid audiophile who would try hooking his sound gear up to the IMT switch socket and make himself vulnerable anyway…. But he won’t care as he already blown £2K on his shiny blocks of wood with a nail sticking out because the snake-oil salesman said it was, “for sweeter music”.

  4. “…while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life.”

    Ah yes, the “Stop complaining about our faulty product. Buy our latest stuff or piss off!” method of building customer goodwill.

    1. Yeah this really angered me, I buy gigabyte products and have had no trouble with their motherboards but a serious flaw like this even if it is end of life, Patch it and earn/keep your customers respect.

      1. Yep, Patch it and the customer may think, “Wow, What service…. Was thinking of getting another PC soon… Will stick to GoodBrand Co PCs because of their patching EOL hardware irrespectively”.

        On the other hand Gigabyte could of said (Blagged) they cannot support the EOL hardware due to having not seen the issue ahead of time and the sources are now lost on backup tapes! (In a more apologetic and sympathetic tone of course, else the blag won’t work)

  5. Indeed. I have two GB boards, one of which is bricked.
    Seems that the flash chip does indeed have a limited life and eventually fails (cough W*n*o*d 1MB/2MB/4MB /cough) and every power cycle counts as a write cycle in many cases.
    I did look into making backup chips so that bricked boards could be upcycled and have DSL installed directly from the 25Q256 IC (32MB) which is basically the same if you merely modify the chip ID.
    Some BIOSs use a special routine that locks down the chip ID to defeat repair attempts (swines!!) so if you are not aware of this replacing chip will not work as do many smart TVs and digiboxes.
    Replaced one a while back and had to change the entire board because my attempt at reflashing failed and did not want to risk my new $$$ board on the small odds that changing the chip would help.

    1. That is due to the ME Firmware, if you have a dump or full image you can change the supported/trusted Flash ID with FITC for the corresponding ME firmware version.

      You cant just put another brand Flash and expect the reading/writing to work when they have different routines -.-

      Also, you cant use a bigger flash because the last 4 bytes are the jump vector for the cpu to execute, its legacy yes, and its how it is..

      Also, bios modding is alive and well today, its a bit harder than the usual, but I have already linked this a couple of times..
      Unlocking/changing the max current that Toshiba decided that was good for the P50A..

      Also, you guys cant just go and disable writes on a UEFI bios, you do that and the system wont boot..

      And yes, dead flash chips in laptops is super common, its a 5$ fix, and lots of shops wont even know that and will quote you a “brand new” MB from ebay for half the laptop cost.

      1. If you read the PCH data sheets and learn about descriptor mode, there is a bit more nibbling you can do. One issue is that there is a region of the descriptor block that is used for ‘strapping’ the chipset in place of actual pull ups and pull downs. I believe finding many of those values requires an NDA with Intel. I know flash layout is actually pretty flexible when you are working with source from an IBV, but if you’re a model you are working blind and don’t have the benefit of documentation (but Intel does slip up and you can infer things from the data sheets, it’s just a LOT of dry reading).

        I hope BIOS models are aware of the platform initialization spec, once you have an image of the BIOS region, you can break out the individual firmware volumes then break those into their individual FFS files. As long as there isn’t too much vendor secret sauce in the form of vendor GUIDed sections, it’s pretty straightforward to get at the individual PE and TE images. But modding them will break SecureBoot.
        There is a lot of information available in public specs, you just have to know what to look for.

      2. “Also, you cant use a bigger flash because the last 4 bytes are the jump vector for the cpu to execute, its legacy yes, and its how it is..”

        Erm… I can’t remember the attempted disassembly of two tablet PCs Firmware that well however here goes….
        both same specs, one had a 64Mbit (8MB) EEPROM inside and the other had a 128Mbit (16MB) EEPROM inside. Legacy code is somewhere in the begining of the ROM aligned to around 0xFFFFFF0 for the first (in both images) flush-cache, purge-interrupts and a jmp into an image extraction routine (That is as far as I could work out LOL, and is similar on both.).

        Everything above said address is therefore arbitrary data for the purposes of storing even an entire OS if one wishes!

        About the tablet PCs:
        One had an EFI shell upon a button press (Until a multi-voltage battery pack blew it up: Powergorilla brand IRC),
        The other had a password locked Firmware configuration interface if you were lucky to see it! This was my target.

        1. I’m going to cover Intel’s stuff here. I haven’t worked with any AMD stuff in a very long time.
          The PCH contains an SPI controller and when it first gets power, it reads the first couple bytes of the flash part. If they have a particular signature, it sets descriptor mode and starts feeding data to a state machine (descriptor mode is the norm these days). Soft straps get programed, ME firmware gets loaded, the gigabit ethernet firmware gets loaded and the BIOS region gets aliased to the ‘top of low memory’ meaning the 4GB boundary. That is, the highest address in the BIOS region is mapped to 0xFFFFFFFFFFFFFFFF. Part of it also gets mapped to the legacy F000 segment. When the CPU comes out of reset, it’s running in 16 bit mode and the reset vector is F000:FFF0h.
          If you are running an Intel PC back to the original Nehalem vintage, it is almost certain you have some flavor of UEFI and if you are curious you can grab the EDK2 from the github repo you can find at and poke around there. You might seach for ResetVec.asm16, but the actual reset vector ends to be very processor specific and the code needed for most PC processors is only provided by BIOS vendors like AMI or Insyde.
          That’s not to say that the EDK2 code has no value in understanding PC BIOS, just that you will be limited in what you can try out.

          If you can understand the UEFI and PI specs, you can probably become a more effective BIOS modder. For example, if you understand the HII part of the UEFI spec and get comfortable with the form and string data, you can potentally modify some parts of the behavior of the setup utility and may be able to add additional localization options.

          If you are really interested in this, then I strongly recommend getting a dediprog (they are what we use at work). If you get super lucky, you’ll find a board with the in circuit programing header populated. If you are just lucky, it will be easy to ID the in circuit programming header and can see how much of the circuit is populated. If you are unlucky, it will take removing the SPI part and installing a socket instead.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s