[HN Gopher] AMD: Microcode Signature Verification Vulnerability
___________________________________________________________________
AMD: Microcode Signature Verification Vulnerability
Author : todsacerdoti
Score : 134 points
Date : 2025-02-03 17:59 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| dmitrygr wrote:
| > we will not be sharing full details at this time in order to
| give users time to re-establish trust on their confidential-
| compute workloads.
|
| What a load of shit! Confidence is earned, it does not grow back
| like a weed you stepped on!
| kmeisthax wrote:
| They promised additional details in March - a month away. If
| they don't release that information in March _then_ you can
| sharpen your pitchforks.
| unsnap_biceps wrote:
| I feel like this is a technical trust re-establishment, hence
| calling out specifically confidential-compute workloads
| Stevvo wrote:
| They only shared it now because Asus accidentally leaked it in
| release notes for a BIOS update Beta.
| ThatMedicIsASpy wrote:
| With ASUS leaking the fix in a beta bios one could go that
| route.
| dboreham wrote:
| > CPU uses an insecure hash function in the signature validation
|
| Do we know what this "insecure hash function" is/was?
| dmitrygr wrote:
| $5 says CRC32
| ngneer wrote:
| More likely a SHA variant that is susceptible to a second
| preimage (collision) attack.
| wrs wrote:
| "A test payload for Milan and Genoa CPUs that makes the RDRAND
| instruction return 4"... Turns out kernel RNG belt-and-suspenders
| was justified?
| bestouff wrote:
| Yes ! I wonder what's the Windows implementation of the
| equivalent API.
| cluckindan wrote:
| Run the patch and find out.
| rincebrain wrote:
| "in theory" Linux, at least, was supposed to use rdrand's
| output as _one_ source of entropy, not _the only_ source.
|
| No idea what Windows et al do for this, or if that's still
| true, but I believe the above description was how the argument
| was originally ended.
|
| Also, tbh, if you can patch arbitrary instruction behavior,
| just replacing rdrand seems like far too ham fisted a tool with
| the level of versatility in your hands...
| Tuna-Fish wrote:
| Linux's rdrand use is proof against it returning bad output,
| but is not proof against malicious microcode. Reason for this
| is that the malicious microcode can examine register contents
| and alter the value it's returning so that mixing it into the
| previous source of randomness produces the desired evil
| value.
| rincebrain wrote:
| Sure, but as stated, if you don't trust the CPU at all,
| rdrand becomes the least of your concerns.
| Tuna-Fish wrote:
| The thing is, all the other ways you can compromise the
| kernel from microcode are at least theoretically
| detectable. A security researcher could study how the cpu
| operates and find the exploit. If RDRAND is
| surreptitiously replacing all your random numbers with
| AES of the current time, you cannot find that out from
| observing behavior.
|
| I agree that worrying about RDRAND shouldn't probably be
| on the top of anyone's priorities, but there is some
| cause to at least use it defensively, for example using
| it to pre-fill buffers with random values in a different
| context, so that subversion would in the very least
| require memory references, instead of running RDRAND in
| the context of your RNG.
| wahern wrote:
| For organizations like the NSA, a simple hack like this is
| the opposite of ham-fisted, though presumably they'd try to
| ensure the output would pass common statistical tests. The
| utility in quietly breaking cryptographic protocols is
| presumably a major reason why it was chosen for the proof-of-
| concept.
| rincebrain wrote:
| Sure, but that was my point, was that just overriding
| rdrand would be much more ham-fisted than any practical
| attack I would expect someone to weaponize this into
| outside of a PoC.
| dooglius wrote:
| Intel's theory I believe was that it could become the only
| source. The argument in favor I think is the same one you are
| making now: anything that could hack the chip deeply enough
| to break rdrand is powerful enough to achieve the same goals
| in another way.
| rincebrain wrote:
| I'm sure Intel loved that idea, given that I don't think
| RDRAND showed up on AMD chips for 3 years after Intel
| launched support for it, and that would let them look much
| better on a number of benchmarks for that duration...
| formerly_proven wrote:
| I think you misunderstand where in the pipeline RDRAND
| would sit. It's not a high-performance RNG, that
| instruction takes hundreds of cycles and generates a
| couple bytes of data. It's used to derive keys for the
| actual CSPRNG providing e.g. /dev/urandom (which is
| basically a stream cipher). Having or not having RDRAND
| would have no performance impact on the CSPRNG.
| dist-epoch wrote:
| Windows collects hardware device entropy and mixes it into
| the pool.
|
| It also persists the pool across reboots so it doesn't start
| empty.
| c2xlZXB5Cg1 wrote:
| Life imitates art:
| https://imgs.xkcd.com/comics/random_number.png
| saagarjha wrote:
| I assume the Google engineers have a sense of humor
| eptcyka wrote:
| That's a reference to the PS3's RNG.
| Karliss wrote:
| I always thought the same when seeing that XKCD comic, but
| turns out it was the opposite. PS3 hack (2010) came 3 years
| after the XKCD comic(2007), they even used it as one of
| slides during 27C3 presentation.
| https://media.ccc.de/v/27c3-4087-en-
| console_hacking_2010#t=2...
| Lammy wrote:
| I realize the OP is explicitly (w/r/t 4) a reference to XKCD,
| but See Also: Dilbert 2001-10-25 :)
|
| https://web.archive.org/web/20011027002011/http://www.dilber.
| ..
|
| https://dilbert-viewer.herokuapp.com/2001-10-25
| monocasa wrote:
| I wouldn't focus so much on the rdrand part. That's more a
| proof that they have crafted a custom microcode than trying to
| say that rdrand is broken.
| unsnap_biceps wrote:
| > A test payload for Milan and Genoa CPUs that makes the RDRAND
| instruction return 4
|
| I would be tickled pink if the 4 was in reference to
| https://xkcd.com/221/
| vardump wrote:
| Of course it was.
| nspaced wrote:
| Hi, I'm one of the authors and yes it was :)
| saagarjha wrote:
| We thank you for your service
| rcthompson wrote:
| Did you roll your own die or just trust that Randall's
| original die roll was sufficiently random?
| ikiris wrote:
| It's a well recognized standard
| hedora wrote:
| As an end user, I wonder how my cloud provider can prove to me
| that they installed AMD's fix and are not simply running a
| malicious version of the microcode on their CPU that claims to
| have the fix.
| kyrra wrote:
| For the large providers (Amazon, Google, Microsoft), they buy
| so many CPUs that they for issues like this, they tend to be
| given the fixes before they are released to the public. So I'd
| wager that those 3 already have patched their entire fleet.
| rincebrain wrote:
| I don't think you can, necessarily, except by basically
| declaring bankruptcy on the old trust root on the systems and
| teaching everyone not to trust the old root.
|
| As long as the vulnerability doesn't let them actually extract
| the secrets necessary to simulate completely arbitrary
| operations including with any future keys, I _think_ you can
| trust the new attestation chain afterward?
|
| I've not been paid to work on this, though, and it would be
| pretty easy to have accidentally built it in a way where this
| is a world-ending event, and truly paranoid workloads in the
| future are going to insist on only using silicon that can't
| have ever been compromised by this either way.
| cluckindan wrote:
| _hugs the Q6600_ don't you ever die on me, you precious space
| heater.
| bornfreddy wrote:
| Try to install your own patch for RDRAND and check that it is
| returning 4? Of course, getting 4 multiple times doesn't mean
| you have succeeded [0].
|
| [0]
| https://duckduckgo.com/?q=dilbert+random+generator+nine+nine...
| (couldn't find a good link to the comic)
| tedunangst wrote:
| The exploit doesn't work in a VM.
| wmf wrote:
| In theory the PSP should probably attest the microcode but I
| don't know if that exists.
| bpye wrote:
| SEV-SNP VMs can obtain an attestation report [0].
|
| [0] - https://www.amd.com/content/dam/amd/en/documents/epyc-
| techni...
| alberth wrote:
| Don't microcode updates require a restart as well.
| monocasa wrote:
| They do not.
| formerly_proven wrote:
| Microcode updates aren't persistent, they're loaded into on-
| CPU-SRAM by firmware and/or kernel.
| bri3d wrote:
| It's in the CVE: "AMD SEV-SNP users can verify the fix by
| confirming TCB values for SNP in their attestation reports."
|
| You can read about how this works here:
| https://www.amd.com/content/dam/amd/en/documents/epyc-techni...
|
| If you aren't using SEV-SNP / attested compute, you have bigger
| fish to fry anyway since you have no actual trust in your
| hypervisor.
| kccqzy wrote:
| While I agree with you, from experience most people and most
| workloads definitely aren't using SEV-SNP. The hypervisor and
| the cloud provider are always assumed to be honest.
| nubinetwork wrote:
| I don't know how exploitable this really is, as a lot of Linux
| systems load microcode at boot time... once it's been loaded, I
| don't think it's possible to load another one (outside of
| rebooting).
| homebrewer wrote:
| It is possible, but it's generally not a good idea.
|
| https://wiki.archlinux.org/title/Microcode#Late_loading
|
| https://docs.kernel.org/arch/x86/microcode.html#late-loading
|
| although quotes from this article claim that it's fine
| specifically on AMD systems:
|
| https://www.phoronix.com/news/AMD-Late-Loading-Microcode
| rincebrain wrote:
| To my understanding, part of the reason that was a problem
| was that Intel wanted to killswitch feature bits like SGX,
| but since Linux saves the feature bit state when it inits the
| CPUs, and then other things might change codepaths based on
| that, if you then killswitch it later, boom might go the
| dynamite.
|
| (I believe this example would also still break on AMD-based
| systems, AMD just hasn't killswitched a CPUID feature flag
| yet AFAIR...)
| dooglius wrote:
| Doesn't this give enough detail for someone to replicate easily?
| I'd think it would not be too hard to look at the signature and
| find the insecure function used.
| rincebrain wrote:
| There's been a bunch of scattered public research on microcode
| payload signatures over the years.
|
| I would speculate that the problem is less that the hash
| function is weak inherently (otherwise we'd have a really
| complicated horizon of needing to chain microcode updates since
| we'd eventually want to e.g. go from MD5 to SHA1 or something),
| and more that the implementation has a flaw (similar to things
| like Nintendo using strcmp and not memcmp on their hash
| comparisons in the Wii, so you only had to collide the function
| to the first \0).
| garaetjjte wrote:
| Privileged code can load microcode? Duh, "vulnerability".
| ngneer wrote:
| There are multiple privilege levels. Microcode has higher
| privilege than an OS/VMM does.
| Kab1r wrote:
| Does anyone know if this is the same vulnerability that ASUS
| leaked in a beta BIOS?
| bri3d wrote:
| To the very best of my knowledge, yes, it is.
| bhaney wrote:
| Damn, now all those hostile microcode patches I'm always
| attempting to load might actually work?
| techwiz137 wrote:
| How do they know the internal microcode structure of instructions
| or even format?
| ris wrote:
| Some people are very good at this, e.g.
| https://app.media.ccc.de/v/35c3-9614-inside_the_amd_microcod...
| xmodem wrote:
| Security implications aside, the ability to load custom microcode
| onto these chips could have fascinating implications for reverse
| engineering and understanding them better.
| AnotherGoodName wrote:
| Also I'm curious if there's opportunity for an all out perf
| variant from home brewers.
|
| Eg. Throw away all spectre mitigations, find all the hacks to
| get each instructions timing down, etc.
| 9cb14c1ec0 wrote:
| Move over Android ROM enthusiasts, real geeks run their own
| microcode.
___________________________________________________________________
(page generated 2025-02-03 23:00 UTC)