On 13/03/2025 3:55 am, Solar Designer wrote: On Sat, Mar 08, 2025 at 01:28:07AM +0000, Andrew Cooper wrote: On 06/03/2025 4:48 am, Solar Designer wrote: On Thu, Mar 06, 2025 at 04:11:25AM +0000, Andrew Cooper wrote: This issue wins points for spite, because the highest risk users are the ones who were taking proactive steps to try and improve their security, betting that AMD's patchloader crypto was sound. OK, so this is to protect legitimate sysadmins from loading malicious microcode inadvertently or via a supply chain attack. Makes sense. Sorry for the delay, I knew there was a distro formally doing this, but I'd lost track of the links.

https://github.com/divestedcg/real-ucode which is packaged for Arch as https://aur.archlinux.org/packages/amd-real-ucode-git (and an equivalent Intel package). Thank you for these followup postings, Andrew! They're very helpful.

I have one late nitpick to add - as jericho @attritionorg pointed out on Twitter, the Subject line here gives an incorrect CVE number. The correct one is CVE-2024-36347. Oops, my mistake.  (This is what happens when the sources of information try to block things like copy/paste, and I'm in a rush.)

However, happy patch Tuesday.

Zen5 CPUs have been breached too, and https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html has been quietly updated to reflect this.

~Andrew

On Wed, Mar 05, 2025 at 11:03:49PM -0600, Jacob Bachmeyer wrote: On 3/5/25 21:30, Solar Designer wrote: [...] I'll focus on what the vulnerability and its fix are: [...]

Forging On We noticed that the key from an old Zen 1 CPU was the example key of the NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588 09cf4f3c) and was reused until at least Zen 4 CPUs. [...] They... used... the... example... key... in... a... real... production... system...

[I have no words.] It appears they didn't realize the key's secrecy would matter for their use case (or else they probably wouldn't use CMAC in the first place), so it "made sense" to stick with a "standard" tested key. Given that misunderstanding, I wouldn't blame them for choosing an example key.

Whatever key, it sounds like the Google folks already had it before they realized it's an example key from NIST, so the rest of the story would have been the same with any other fixed key.

The real issue is the use of CMAC without understanding its properties, not the key choice.

Indeed, HMAC wouldn't be any weaker than its underlying hash on its own even when used with a publicly known example key. So I can see how they could have (wrongly) expected the same from CMAC.

Alexander

On 3/5/25 21:30, Solar Designer wrote: [...] I'll focus on what the vulnerability and its fix are: [...]

Forging On We noticed that the key from an old Zen 1 CPU was the example key of the NIST SP 800-38B publication (Appendix D.1 2b7e1516 28aed2a6 abf71588 09cf4f3c) and was reused until at least Zen 4 CPUs. [...]

[I have no words.]

-- Jacob

It looks like an OEM leaked the patch for a major upcoming CPU vulnerability, i.e. "AMD Microcode Signature Verification Vulnerability":

https://rog.asus.com/motherboards/rog-strix/rog-strix-x870-i-gaming-wifi/helpdeskbios/

I'm not thrilled about this - the patch is not currently in linux-firmware, so this is the only publicly available patch.

However, other people are discussing how to extract them:

https://winraid.level1techs.com/t/offer-intel-amd-via-cpu-microcode-archives-1995-present/102857/53

Tavis.

-- o) $ lynx lock.cmpxchg8b.com /\\ o) o) $ finger taviso () sdf org \V ( ) ( ) @taviso

No intent? It wouldn't be terribly hard, they could just RNG over the register afterwards or run a 1/1 to nullify any data left therein. The latter would require control lines to be in place, the latter would just mean extending the microcode instruction. That said I could understand the want to depricate zen1 support entirely, everyone upgraded when they could it was super super cheap to do so & there weren't really any enterprise users.

On Tue, Oct 3, 2023 at 3:54 PM Solar Designer <solar () openwall com> wrote: On Tue, Oct 03, 2023 at 03:02:41PM -0700, Jean Luc Picard wrote: Hi, just dropping in, is this the kind of thing to where the userspace & kernel layers need mitigation until there's microcode mitigation? In general, kind of yes - it could have been that kind of thing.

More specifically, no - in this case, only kernel and hypervisor and system configuration (disable SMT) mitigations are expected. No userspace mitigations, other than maybe specific algorithms avoiding integer divide operations based on secrets where they can. While AMD maybe could fix this in microcode (or maybe not, or maybe with unacceptable performance penalty), they expressed no plans to do so. On Tue, Oct 3, 2023 at 2:46???PM Jeremy Stanley <fungi () yuggoth org> wrote: On 2023-10-03 22:37:08 +0100 (+0100), Andrew Cooper wrote: [...] If you have a proposal for how you'd prefer it to be done, I'll see what I can do. Perhaps BCC oss-security, or just send out a second mail? When I send advisories, I prepare two basically identical E-mail messages: one to the project's announcement list and one to oss-security (signing both of them). It seems like this is the most common approach to avoiding cross-posting between lists. Andrew, sending a second message like Jeremy suggests works best. Bcc currently isn't expected to work at all. Thank you!

BTW, in this case I think the problem was actually for Xen's lists more than for oss-security - you included xen-announce among the CC'ed lists, and this means e.g. Demi Marie's reply was attempted to be posted to there, while certainly not being a valid Xen announcement. However, I guess external messages to the announcement list are very easy to reject on your side. It's not so easy for us on oss-security because we've setup some senders to bypass moderation, yet those people participate in threads on other lists that might just happen to be CC'ed in here and they might not notice that the rest of the sub-thread is moderated-out.

I'm not too concerned about this issue with Xen announcements in particular - things have worked pretty well with these so far.

Alexander

Daniël Trujillo, Johannes Wikner, and Kaveh Razavi discovered that some AMD processors utilising speculative execution and branch prediction may allow unauthorised memory reads via a speculative side-channel attack. A local attacker could use this to expose sensitive information, including kernel memory.

Tavis Ormandy discovered that some AMD processors did not properly handle speculative execution of certain vector register instructions. A local attacker could use this to expose sensitive information.

Jann Horn discovered that microprocessors utilizing speculative execution and branch prediction may allow unauthorized memory reads via sidechannel attacks. This flaw is known as Spectre. A local attacker could use this to expose sensitive information, including kernel memory. This update provides the microcode updates for AMD 17H family processors required for the corresponding Linux kernel updates.