• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Jailbreak AMD microcode

1.1.2.3.5... said:
https://x.com/taviso/status/1897333770644336774


https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking

Requires local admin rights.
Click to expand...
If they have local system admin rights they already can just steal your shit, there is no need for them to go through he extra steps of performing the exploit...
It's good they are doing the work, but this would be all like, "OH NO! The bad people have managed to get a secure connection to the local hardware and have obtained the local system admin credentials, but the good news is they only decided to run some obscure hardware exploit instead of stealing all our data and nuking all the systems to cover their tracks..."
 
Lakados said:
If they have local system admin rights they already can just steal your shit, there is no need for them to go through he extra steps of performing the exploit...
It's good they are doing the work, but this would be all like, "OH NO! The bad people have managed to get a secure connection to the local hardware and have obtained the local system admin credentials, but the good news is they only decided to run some obscure hardware exploit instead of stealing all our data and nuking all the systems to cover their tracks..."
Click to expand...
This is still a concern for off site systems where an employee may be given admin rights for a number of reasons. Not every exploit is dangerous because it may affect an end users system where they are the only ones with admin rights.
 
Lakados said:
If they have local system admin rights they already can just steal your shit, there is no need for them to go through he extra steps of performing the exploit...
It's good they are doing the work, but this would be all like, "OH NO! The bad people have managed to get a secure connection to the local hardware and have obtained the local system admin credentials, but the good news is they only decided to run some obscure hardware exploit instead of stealing all our data and nuking all the systems to cover their tracks..."
Click to expand...

I'd imagine the concern is if someone infiltrates the supply chain, like either for used parts or sellers out of China or stuff like that. If someone gets in there, modifies the microcode , then sells it on.

Where does that microcode reside? In the BIOS? I guess this is yet another in a long list of reasons why you should make sure you flash a new BIOS to new equipment you buy, regardless of whether or not it is already on the latest revision.
 
Zarathustra[H] said:
I'd imagine the concern is if someone infiltrates the supply chain, like either for used parts or sellers out of China or stuff like that. If someone gets in there, modifies the microcode , then sells it on.

Where does that microcode reside? In the BIOS? I guess this is yet another in a long list of reasons why you should make sure you flash a new BIOS to new equipment you buy, regardless of whether or not it is already on the latest revision.
Click to expand...
Microcode updates are generally applied alongside BIOS updates, and sometimes it resides on the BIOS and other times on the CPU itself. It gets a little squirly, depending on what needs updating.
 
The CPU microcode instructions and data are physically stored in an on-die ROM with additional on-die patch SRAM. This patch RAM can be loaded with new instructions during a microcode update (typically occurring during BIOS and OS boot) and is impossible to directly access using the x86 core. The only documented method for changing the microcode patch RAM is by loading an authentic microcode update from AMD, verified by a cryptographic signature.

from the exploit article

In sense the fear on AMDs part could be what else can they access.
 
Lakados said:
Microcode updates are generally applied alongside BIOS updates, and sometimes it resides on the BIOS and other times on the CPU itself. It gets a little squirly, depending on what needs updating.
Click to expand...

I wonder if - when you flash a BIOS - it will force a re-flash of the microcode regardless, or if it will try to be smart, detect that the microcode is unchanged and skip it. If it does the latter, this suddenly means there is a huge un-mitigatable risk when buying CPU's.
 
Zarathustra[H] said:
I wonder if - when you flash a BIOS - it will force a re-flash of the microcode regardless, or if it will try to be smart, detect that the microcode is unchanged and skip it. If it does the latter, this suddenly means there is a huge un-mitigatable risk when buying CPU's.
Click to expand...
Intel offers microcode separately for Linux, so you can just install new versions for your system as needed, reboot-free!
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files

But not all BIOS updates contain Microcode updates, and not all vendors do theirs the same way.

When performing a BIOS update, it will check the Firmware Interface Table (FIT) in the BIOS update and act accordingly. It isn't common to update the Microcode if it already matches what is in the table, so assuming they faked the hash on whatever microcode they load, then you will need to ensure you are moving to something that doesn't pass the hash, so either something older or newer.

Dell and the likes offer the ability to perform Microcode updates directly through their BMC controllers. The specifics vary from brand to brand, but the core remains the same.
 
You must log in or register to reply here.
Back
Top