New ZenHammer memory attack impacts AMD Zen CPUs

MrGuvernment

Fully [H]
Joined
Aug 3, 2004
Messages
21,823
New ZenHammer memory attack impacts AMD Zen CPUs
https://www.bleepingcomputer.com/news/security/new-zenhammer-memory-attack-impacts-amd-zen-cpus/

Academic researchers developed ZenHammer, the first variant of the Rowhammer DRAM attack that works on CPUs based on recent AMD Zen microarchitecture that map physical addresses on DDR4 and DDR5 memory chips.

AMD Zen chips and DDR5 RAM modules were previously considered less vulnerable to Rowhammer, so the latest findings challenge this notion.

The ZenHammer attack was developed by researchers at public research university ETH Zurich, who shared their technical paper with BleepingComputer.

Attack background
Rowhammer is a well-documented attack method that exploits a physical characteristic of modern Dynamic Random-Access Memory (DRAM) to alter data by repeatedly accessing ("hammering") specific rows of memory cells through read/write operations to change bit values inside.

Memory cells store information as electric charges that determine the value of the bits inside as a 1 or a 0. Because of the increased density of the memory cells in modern chipscells, repeated "hammering" can change the charge state in adjiacent rows, a process known as "bit flipping."

By strategically inducing these bit flips in specific locations, an attacker could gain access to sensitive data (e.g. cryptographic keys) or escalate privileges.

The technique has been demonstrated on Intel and ARM CPUs, leaving AMD's Zen architecture CPUs largely unexplored due to inherent challenges such as unknown DRAM addressing schemes, synchronization with refresh commands, and difficulty to achieve a high enough row activation throughput.

With ZenHammer, the researchers at ETH Zurich managed to address these challenges by reverse-engineering the complex and non-linear DRAM addressing functions in AMD platforms.
 
With more and more of these hardware exploits popping up all the time, if argue that the best approach is to just not allow unteusted code to ever run on the machine.
 
With more and more of these hardware exploits popping up all the time, if argue that the best approach is to just not allow unteusted code to ever run on the machine.
And controlled network access.
Solutions from HP, Cisco, and the other big networking players have options to be content and state aware, so you can designate systems that can have outgoing access but deny unsolicited incoming access even within the same vlan on the same switch.
So you can enable full communication between device A and B when initiated by A, but deny all access between them if initiated by B or any other device.
You can also granularly set access there as well so limit it to ports and specific protocols across the whole network not just at entry or exit points.
PITA to configure across the whole organization you realize how many different things need to cross communicate… F’ing BacNET but at this stage it seems like a security must have.
 
With more and more of these hardware exploits popping up all the time, if argue that the best approach is to just not allow unteusted code to ever run on the machine.
Gonna put on my conspiracy theory hat on and say that these CPU exploits are either discovered by competitors or by the CPU manufacturers themselves because it tends to effect older CPU's worse than newer ones. The problem I have with this is that no malware or virus yet uses them. So why slow down my CPU to avoid this?
giphy-3-9-11.jpg
 
Gonna put on my conspiracy theory hat on and say that these CPU exploits are either discovered by competitors or by the CPU manufacturers themselves because it tends to effect older CPU's worse than newer ones. The problem I have with this is that no malware or virus yet uses them. So why slow down my CPU to avoid this?
View attachment 644125
Nah there’s just so much money out there hiding on these that there’s significant incentive for bad people to do the bad things to make the dirty money.

We’re not to far off from some James Bond level villain antics.
I mean can you see a movie where a billionaire crypto bro decides he wants to save the world by destroying money so they want to release a computer virus over the blockchain to destroy all banks. So the only functional currency will be their new coin that they have full and total control of…
 
Gonna put on my conspiracy theory hat on and say that these CPU exploits are either discovered by competitors or by the CPU manufacturers themselves because it tends to effect older CPU's worse than newer ones.
Considering how complicated it is to find them and CPU trying to avoid them and learning from the past, how effecting older CPU's worse than newer ones is not the natural expectation ? M1/2/3-AM5 are not particularly old chips here.
 
Considering how complicated it is to find them and CPU trying to avoid them and learning from the past, how effecting older CPU's worse than newer ones is not the natural expectation ? M1/2/3-AM5 are not particularly old chips here.
Well for every dollar spent by the good guys finding these exploits, there $10 being spent by the bad guys to do the same.

Can’t protect against threats you can’t see.
 
Great. Another vulnerability that requires software mitigations that may impact performance. As if we didn't have enough of them already...

I'll be glad if I'm wrong about that, though.
 
What's not made clear from the article and the articles linked in chain is whether these related exploits can be run fully remotely and autonomously infecting RAM just by a user browsing the web, or like so many exploits where the attacker needs sustained physical access to an exposed motherboard (here the DRAM) in an opened chassis.
 
And controlled network access.
Solutions from HP, Cisco, and the other big networking players have options to be content and state aware, so you can designate systems that can have outgoing access but deny unsolicited incoming access even within the same vlan on the same switch.
So you can enable full communication between device A and B when initiated by A, but deny all access between them if initiated by B or any other device.
You can also granularly set access there as well so limit it to ports and specific protocols across the whole network not just at entry or exit points.
PITA to configure across the whole organization you realize how many different things need to cross communicate… F’ing BacNET but at this stage it seems like a security must have.

You could accomplish that with pfSense or OPNSense, a badass NIC and at least two VLAN's and firewall rules between them, but the content/state aware enterprise solutions seem a little easier.

I just stuck a cheap old Intel X520 two port fiber NIC into my OPNSense box (Rocket Lake Xeon E-2314), and it does a great job of routing between VLAN's when I need it to.

Relatively low cost, and never any license fees :p
 
What's not made clear from the article and the articles linked in chain is whether these related exploits can be run fully remotely and autonomously infecting RAM just by a user browsing the web, or like so many exploits where the attacker needs sustained physical access to an exposed motherboard (here the DRAM) in an opened chassis.

They can be triggered from any native code execution, including remote. So not yet from Javascript in a wen browser, but any form of remote code execution will do. Physical access is irrelevant for this class of vulnerabilities.
 
You could accomplish that with pfSense or OPNSense, a badass NIC and at least two VLAN's and firewall rules between them, but the content/state aware enterprise solutions seem a little easier.

I just stuck a cheap old Intel X520 two port fiber NIC into my OPNSense box (Rocket Lake Xeon E-2314), and it does a great job of routing between VLAN's when I need it to.

Relatively low cost, and never any license fees :p
Between PaloAlto, HPE Aruba, and the others license fees are half my budget.
 
With more and more of these hardware exploits popping up all the time, if argue that the best approach is to just not allow unteusted code to ever run on the machine.
I mean... that's always been the best answer but it is hard if you want functionality and flexibility. To have only trusted code would require going to something like the Apple/Microsoft store and only being able to install things the OS vendor deems safe. Even then those stores would need to be curated much better than they are, which means not only more cost but also just less things getting approved. Also websites would have to go back to the old static HTML content, no more interactive JavaScript as that is literally code running on your machine.

There are systems out there where it is a heavily regulated, verified, design and you only run trusted code, but they are inflexible. They are the sort of thing where "this does the things it does and no you can't change/upgrade it." If we want computers that are flexible and let us run whatever we want, that also means that we are going to have the ability to run code that hasn't been vetted.
 
I mean... that's always been the best answer but it is hard if you want functionality and flexibility. To have only trusted code would require going to something like the Apple/Microsoft store and only being able to install things the OS vendor deems safe. Even then those stores would need to be curated much better than they are, which means not only more cost but also just less things getting approved. Also websites would have to go back to the old static HTML content, no more interactive JavaScript as that is literally code running on your machine.

There are systems out there where it is a heavily regulated, verified, design and you only run trusted code, but they are inflexible. They are the sort of thing where "this does the things it does and no you can't change/upgrade it." If we want computers that are flexible and let us run whatever we want, that also means that we are going to have the ability to run code that hasn't been vetted.
Newer AV solutions can also also scan and report on known vulnerabilities. Playing with the stuff from SentinelOne right now so probably going on the list of yet another subscription service my budget goes toward.

I swear I spend more on security than I do for productivity at this point…
 
Considering how complicated it is to find them and CPU trying to avoid them and learning from the past, how effecting older CPU's worse than newer ones is not the natural expectation ? M1/2/3-AM5 are not particularly old chips here.
But it is worse for older CPU's, and Apple did used to have Intel chips in their machines. It's not like every Intel Mac user just dropped their machines and immediately switched over to M1's. It also doesn't take long for mitigations to be created and immediately implemented into OS's. There's no agreement on your end to enable these mitigations. Who wants to lose 1% to 6% CPU performance for something that no malware or virus uses?

Think of it like this. Who took the time to create the ghost logo for Spectre? Keeping my tinfoil hat on. Here's methods to disable them in Windows.
logo.png

https://www.grc.com/inspectre.htm
screenshot.png
 
But it is worse for older CPU's,
But why would it not (CPU try get better at this over time + people trying to find flaw had more time on the older model, everything naturally point in the direction that the situation would be worst on the older cpu than the newer, at least for what it is known)
 
Newer AV solutions can also also scan and report on known vulnerabilities. Playing with the stuff from SentinelOne right now so probably going on the list of yet another subscription service my budget goes toward.

I swear I spend more on security than I do for productivity at this point…
For sure, but that's not only running trusted code, that's scanning the system and the code on it to try and filter out code that might be malicious. That's a good thing and we all should do it, but it is still basically blacklisting whereas only allowing trusted code to run is whitelisting. Whitelisting works REALLY WELL if you can do it. In a corporate environment if you turn on AppLocker (or use another solution) that right there stops over 90% of exploits cold according to ACIS. Combine that with whitelisting only websites needed for business and man, you are exceedingly hard to attack, even if you do nothing else. Even when there's an unauthenticated remote code exploit that usually stops it as the code itself is just not allowed to run.

...the problem is that only works in a corporate environment where there's a security team that can review and test and keep on top of all this, and it is still a big administrative amount of overhead. For personal devices where we wanna do what we want, it doesn't work. So instead we go for solutions that look for known bad actors and exploits, look for code that is doing suspicious shit, etc, etc.

I think it is just the compromise we have to live with for now.
 
With more and more of these hardware exploits popping up all the time, if argue that the best approach is to just not allow unteusted code to ever run on the machine.

Some security flaw-attack cannot be necessarily detected by testing the code, has the program do nothing suspicious most of the time, it act on a trigger, large part of the planet was infected by the Bush-Obama Whitehouse with Stuxnet, it was sleeping for years and if you did not had the industrial machine plugged in your computer that it targeted and destroyed not sure it ever did anything.

I do not imagine important part of Bank system and so on run untested code ever, but you can have something that nothing suspicious until something that trigger it (moment in time, detect a specific activity, etc....) or obviously an attack that does not come from the system owner code they run themselve.
 
Are you at liberty to post info about your security spend? I assume that you are working for a corporate.
The specifics get a bit tricky because they don't charge us per head, we get charged per FTE, so we might have some 80 staff but it currently only counts as 58 FTE as the part-time employees are lumped up into a bulk seating agreement, so 3, 0.6 FTE employees would consume 2 FTE allotments.

But there are the O365 A5 license packs, soon-to-be Sentinal One (accounting is working on those details now), Palo Alto support contracts, and feature agreements for VPNs, traffic shaping, wildfire protection, etc. HPE Aruba for their GreenLake and ClearPass platforms, Azure for a segregated offsite failover, Veeam for incremental backups, which go to the secure AWS storage (that is kept blind from the domain, and gets contracted out for pen testing), and VMWare / Nvidia licenses for the secured virtual workstations. I have been informed that sometime next year I will be expected to be deploying some form of internal active network monitoring that will be looking for unusual behavior on the network to prevent any situations should a non-managed and unauthorized device still get connected to the network and start doing bad things or just snoop around in general.

Sadly I don't have the specifics on the final costs because of how it gets spread out over multi-year agreements but it isn't insubstantial.

And I don't consider Azure, AWS, or Veeam as disaster recovery items because we have redundant server clusters in separate synchronized locations, each contains its own local backups. So they can fail over and recover from each other so we would need to loose two separate sites in some form of accident for there to be any down time resulting from hardware failure. So those 3 services are intended to recover from or remain operational in the event of a Crypto attack or other such event that would render the local sites offline or unusable.
 
Last edited:
The specifics get a bit tricky because they don't charge us per head, we get charged per FTE, so we might have some 80 staff but it currently only counts as 58 FTE as the part-time employees are lumped up into a bulk seating agreement, so 3, 0.6 FTE employees would consume 2 FTE allotments.

But there are the O365 A5 license packs, soon-to-be Sentinal One (accounting is working on those details now), Palo Alto support contracts, and feature agreements for VPNs, traffic shaping, wildfire protection, etc. HPE Aruba for their GreenLake and ClearPass platforms, Azure for a segregated offsite failover, Veeam for incremental backups, which go to the secure AWS storage (that is kept blind from the domain, and gets contracted out for pen testing), and VMWare / Nvidia licenses for the secured virtual workstations. I have been informed that sometime next year I will be expected to be deploying some form of internal active network monitoring that will be looking for unusual behavior on the network to prevent any situations should a non-managed and unauthorized device still get connected to the network and start doing bad things or just snoop around in general.

Sadly I don't have the specifics on the final costs because of how it gets spread out over multi-year agreements but it isn't insubstantial.

And I don't consider Azure, AWS, or Veeam as disaster recovery items because we have redundant server clusters in separate synchronized locations, each contains its own local backups. So they can fail over and recover from each other so we would need to loose two separate sites in some form of accident for there to be any down time resulting from hardware failure. So those 3 services are intended to recover from or remain operational in the event of a Crypto attack or other such event that would render the local sites offline or unusable.
Wow. All that must keep you very busy. "Idleness is the Devil's handiwork." That won't be your worry.
 
Wow. All that must keep you very busy. "Idleness is the Devil's handiwork." That won't be your worry.
I just want to paint my Warhammers and play video games :'(
And it's probably overkill, the likelihood that even half of that ever actually does something is unlikely but even a flight across the desert has seats that double as flotation devices in the event of a water landing.
 
Gonna put on my conspiracy theory hat on and say that these CPU exploits are either discovered by competitors or by the CPU manufacturers themselves because it tends to effect older CPU's worse than newer ones. The problem I have with this is that no malware or virus yet uses them. So why slow down my CPU to avoid this?
View attachment 644125
If an exploit is only on two architectures by default without much funding and you spend a large amount of effort targeting a more resilient architecture at some point it becomes more of a tech demo. Reverse engineering anything takes A LOT of resources more than your average hacker. So yeah chances are they are funded by a competitor.
 
. Reverse engineering anything takes A LOT of resources more than your average hacker. So yeah chances are they are funded by a competitor.
Or maybe a bad state actor. Like, Russia, North Korea, China. The usual suspects.
 
Back
Top