[I’m pretty dumb when it comes to AMD systems. 😦 I am just catching up to what most of the rest of the world knows about their technology, and security. I asked on the EDK2-devel mailing list for a clue on AMD’s firmware strategy, and Gary Simpson of AMD was kind enough to answer my questions. I’ll post a version of his answers in an upcoming blog, in the mean time look on the edk2-devel archives on 7/31 for his message. I’m still trying to understand some of the answers from AMD, from firmware development perspective, mainly AGSEA and how it works. Much more on this in future blog posts. In the mean time, I’m also catching up to AMD silicon/firmware security, and the most recent public story appears to be from January:]
Back in January of this year, there were a few stories on one AMD firmware vulnerability, reported last April, fixed last November, reported at December’s Chaos Communications Congress. At 31C3, Rudolf Marek, a Czech programmer, gave a presentation about a security vulnerability on AMD’s x86 chips, insufficient security checks before execution allows malware injection. AMD’s Mullins, Beema, Temash, Trinity, Richland, Kaveri, and Kabini chips are impacted. AMD released new free firmware update to resolve things.
It is nice to hear that “AMD responded quickly” and that this vulnerability was resolved in a “timely” manner!
If you have AMD systems, make sure you have this recent update!
Some quotes from stories on this vulnerability:
“The problem is caused by a vulnerability in the AMD SMU (System Management Unit) Unit APU / SoC mentioned, which does not perform pre-implementation code ‘appropriate checks’. AMD responded quickly, closing this security gap with a firmware update to your AGESA (AMD Generic Encapsulated Software Architecture), which is available for manufacturers of motherboards for PCs, notebooks and tablets, based on these APU / SoC AMD. The developer recommends users, requiring manufacturers of compatible motherboards with the APU / SoC affected, the release of new versions of BIOS with the new version of AGESA incorporated; since some motherboard manufacturers might not feel obliged to publish BIOS updates for older products such as stem socket FM2 cards (compatible with Trinity and Richland).”
“Marek told an audience at the Chaos Communications Congress that he worked with AMD for a year to fix the security flaw. He recommended that users contact their motherboard vendors to push the fix to their computers. “[Ask] your vendors for a fixed AGESA [AMD Generic Encapsulated Software Architecture],” Marek said. “This is the only way to push vendors to update BIOSes for older platforms,” he added.”
“As pointed out by Marek firmware insufficiently correctly checks the signature code that allows an attacker to insert your own code and execute it. This is done via the System Management Unit (SMU), which is also responsible for the power saving function. But he was also deeply involved in the configuration. The firmware on 32-bit controller LatticeMicro32 (LM32) from Lattice Semiconductor. Rudolf Marek broke the key used to sign the code hash SHA1. He took the code from SMU update BIOS, and then run the code on an emulator. After breaking the code Rudolph was able to add their own team in SMU and execute them.”
“The firmware is available as part of AMD AGESA (AMD Generic Encapsulated Software Architecture). It has already been updated AMD in late November, the request was sent to manufacturers of motherboards, notebooks and complete systems. They should implement AGESA in your BIOS and UEFI. Updates should already be implemented for most systems, but manufacturers do not disclose relevant information.”
“Back in April last year, Rudolf Marek informed of its existence AMD, who has confirmed the vulnerability in the summer, and it was fixed at the end of November. Hopefully, manufacturers have responded to this problem in a timely manner, and added in a modified AGESA updating the BIOS.”