Shortly after I joined Microsoft in 2004, all new feature work on Windows Longhorn (Vista) was halted. There had been yet another high profile computer virus on Windows XP caused by a buffer overflow. It was an all-hands-on-deck type moment. Everyone spent weeks adding SAL (source-code annotation language) annotations to the entire Windows code base. SAL annotations enabled automated source code analysis to identify potential buffer overflow bugs and other common security vulnerabilities. Once annotated, we identified and fixed who knows how many hundreds of security vulnerabilities in Windows.
This colossal security update was released as Windows XP Service Pack 2. This is the beauty of software.
Hardware vulnerabilities scare me. There are millions of Intel CPUs and DRAM modules installed in data centers and PCs around the world. When we find vulnerabilities in hardware how are we supposed to fix them?
The past few years have been really scary for me as a software engineer. I keep thinking that the next one will pop the software bubble.
Whenever you have sharing, you usually have side channels. We're going to see more and more of this until we have much better hardware isolation.
This is a kind of obvious variant of Rowhammer, which hasn't generally been fixed AFAIK.
Hardware in the late 2010s seems a bit like Windows in the late 1990s - a house of cards waiting to collapse, but the dominant vendors know that very few customers are willing to pay more for security and reliability vs. performance/features/new and shiny.
(So if we're lucky then we'll end up with a "more secure" version of hardware that is analogous to... Windows Vista.)
Real-world side channels are going to start getting more attention as the technology and techniques for extracting information from EM radiation from circuits (not radios) leaking state improve.
From the speed figures (many hours of setup and runtime, very low read rate) I can suggest that restarting your important service often, and moving it between VMs, would prevent an attack like that.
In many deployments, automatic scaling and failover already provide the necessary mechanics. Then the Chaos Monkey suddenly becomes a security enforcement tool :)
You know what software's like, though. What today takes the blood of a virgin and a dozen dribbly candles will be doable next week with a toothpick and three cc's of mouse blood.
If I understood correctly, this is orders of magnitude worst that RowHammer, as it is kind of passive: you set some program to do the RowHammer side, within its own memory space, and then use RAMBleed to see changes from memory cells, not exactly the ones that were RowHammered. Is that it ?
> a bit is more likely to flip when the bits above and below it have the opposite charge. ... To exploit this effect, we developed novel memory massaging techniques to carefully place the victim's secret data in the rows above and below the attacker's memory row.
The secret data has to be duplicated, column aligned, and have a single unallocated row between it. Controlling the alignment of the secret data seems like a major complication for realistic exploitation.
Edit: The strategy in the paper requires allocating a bunch of physical memory from all the small blocks so that memory allocation requests from a new process are allocated deterministically to a desired physical row.
These recent CPU and Memory vulnerabilities are calling into question the economics of the public cloud. A lot of these bugs only really matter if you have multiple programs from different entities running on the same computer system. A company that has its own private cloud, doesn't have to care about these attacks so much.
The cost of mitigating these attacks both in terms of CPU performance and increased hardware costs may offset some of the economies of scale.
Since the mention of OpenSSH can cause readers to jump to false conclusions: This attack still requires that the attacker's code runs on the victim machine; it is not a remote vulnerability.
(I don't think the authors implied otherwise, I just know that I somehow got confused for a second.)
Perhaps I'm missing something really obvious, but doesn't hardware-provided memory encryption solve this quite handily? You might be able to read single bits of raw physical memory from another process, but this won't tell you anything substantial about what that process is up to.
Anyone else love how vulnerabilities these days have full on marketing-esque campaigns backing them? In any case, if it increases awareness, I'm mostly supportive.
> Previous attacks exploited the Rowhammer effect to write (or flip) bits in the victim's memory. RAMBleed is different in that it uses Rowhammer for reading data stored inside the computer's physical memory. As the physical memory is shared among all process in the system, this puts all processes at risk.
> What data can be read by RAMBleed?
> While the end-to-end attack we demonstrated read out OpenSSH 7.9's RSA key, RAMBleed can potentially read any data stored in memory. In practice, what can be read depends on the victim program's memory access patterns.
> What technologies are affected by RAMBleed?
> RAMBleed relies on Rowhammer-induced bit flips to read privileged memory. As such, any system that uses Rowhammer-susceptible DIMMs is vulnerable. Previous research has demonstrated bit flips on both DDR3 and DDR4 with TRR (targeted row refresh) enabled. While we demonstrated our attack on a desktop machine and an ECC enabled server machine, Rowhammer attacks have been demonstrated against both mobile devices and laptops. As such, we suspect that many classes of computers are susceptible to RAMBleed.
> How can I mitigate this issue?
> Users can mitigate their risk by upgrading their memory to DDR4 with targeted row refresh (TRR) enabled. While Rowhammer-induced bit flips have been demonstrated on TRR, it is harder to accomplish in practice.
> Memory manufacturers can help mitigate this issue by more rigorously testing for faulty DIMMs. Furthermore, publicly documenting vendor specific TRR implementations will facilitate a stronger development process as security researchers probe such implementations for weaknesses.
Unless your CEO loves talking about CVEs all day long, I think we should all be grateful for these good-looking marketing campaigns for serious security issues.
This really sux - that the fix is "Move to DDR with TRR enabled - which means for many people: Buy a new computer. Or new RAM. Or new RAM, motherboard, CPU, etc - ie - a new computer; ie - spend a lot of money".
Not sure if this attack is feasible cross VM as long as the memory is not deduped/over provisioned. You need to make sure the victim allocates memory between the attacker controlled memory.
Edit: As long as the memory is not deduped on the VMs it should not be possible since it won't be interleaved
It sure sounds like it—have there been any responses from the major cloud providers? This doesn’t exactly seem like something that can be patched easily....
This is a tangent, but I find it (somewhat) annoying when f.a.q's don't answer their own questions. I see this happen occasionally and I always wonder if it's intentional to side-step an issue by raising it yourself, and then answering something else.
> Can RAMBleed be detected by antivirus?
> We believe that it is very unlikely that any antivirus software on the market currently detects RAMBleed.
What should they say? It's theoretically possible for any AV to detect the bug (how else did they prove it exists?) but a simple "Yes" hardly conveys accurate information.
I want to find a way to run each application I use on its own machine so that memory attacks (like spectre/meltdown, etc.) are theoretically impossible.
I still want to have a reasonable computing experience (e.g. copy + paste works and the experience is kind of like using one computer the normal way).
Any ideas? I was thinking some kind of remote desktop setup with a bunch of cheap boxes, each running Linux, on a LAN.
I am so torn about the whole vulnerability branding thing. On the one hand, it gives a great amount of visibility and motivation for brass to actually provide for getting prod patched when IT might not have had the political capital to do so otherwise. But on the other hand, I think about things like:
-- What happens when the cure is worse than the disease (some variants of Spectre), and we "have to" patch because otherwise we're "not secure against this scary sounding thing." It takes a lot of agency away from the IT department to make an informed decision about the appropriate mitigation and threat model, and turns it into a business requirement regardless of the trade-off - because brass "understands" Spectre, they don't understand CVE-1234
-- Or, theoretical exploits that aren't practical in the real world, but we spend a lot of effort or make tradeoffs to fix just because someone needs some material for their PhD.
-- What do you call it when we find another way to read RAM next year - RAMBleed2? I guess.
Very cool and scary, but in reality actually exploiting this without a cooperative target, and a relatively quiet machine is quite unlikely. Does not mean it shouldn't be looked at, but do not lose sleep over it.
Well, this sounds really bad. Though on a positive note, I guess we could try a similar exploit in meatspace to figure out if we're living in a simulation or something.
[+] [-] rsweeney21|6 years ago|reply
This colossal security update was released as Windows XP Service Pack 2. This is the beauty of software.
Hardware vulnerabilities scare me. There are millions of Intel CPUs and DRAM modules installed in data centers and PCs around the world. When we find vulnerabilities in hardware how are we supposed to fix them?
The past few years have been really scary for me as a software engineer. I keep thinking that the next one will pop the software bubble.
[+] [-] anaphor|6 years ago|reply
[+] [-] mehrdadn|6 years ago|reply
Are there tools for developers to use these (e.g. with VC++), or are they all Microsoft internal?
[+] [-] mey|6 years ago|reply
[+] [-] AnaniasAnanas|6 years ago|reply
[+] [-] 29athrowaway|6 years ago|reply
[+] [-] musicale|6 years ago|reply
This is a kind of obvious variant of Rowhammer, which hasn't generally been fixed AFAIK.
Hardware in the late 2010s seems a bit like Windows in the late 1990s - a house of cards waiting to collapse, but the dominant vendors know that very few customers are willing to pay more for security and reliability vs. performance/features/new and shiny.
(So if we're lucky then we'll end up with a "more secure" version of hardware that is analogous to... Windows Vista.)
[+] [-] colechristensen|6 years ago|reply
[+] [-] jiveturkey|6 years ago|reply
https://en.wikipedia.org/wiki/Row_hammer#Mitigation
[+] [-] bumblebritches5|6 years ago|reply
[deleted]
[+] [-] nine_k|6 years ago|reply
In many deployments, automatic scaling and failover already provide the necessary mechanics. Then the Chaos Monkey suddenly becomes a security enforcement tool :)
[+] [-] taneq|6 years ago|reply
You know what software's like, though. What today takes the blood of a virgin and a dozen dribbly candles will be doable next week with a toothpick and three cc's of mouse blood.
[+] [-] woliveirajr|6 years ago|reply
[+] [-] deckar01|6 years ago|reply
The secret data has to be duplicated, column aligned, and have a single unallocated row between it. Controlling the alignment of the secret data seems like a major complication for realistic exploitation.
Edit: The strategy in the paper requires allocating a bunch of physical memory from all the small blocks so that memory allocation requests from a new process are allocated deterministically to a desired physical row.
[+] [-] calibas|6 years ago|reply
[+] [-] RcouF1uZ4gsC|6 years ago|reply
The cost of mitigating these attacks both in terms of CPU performance and increased hardware costs may offset some of the economies of scale.
[+] [-] tgsovlerkhgsel|6 years ago|reply
(I don't think the authors implied otherwise, I just know that I somehow got confused for a second.)
[+] [-] Rapzid|6 years ago|reply
[+] [-] 0815test|6 years ago|reply
[+] [-] dredmorbius|6 years ago|reply
https://whois.domaintools.com/rambleed.com
[+] [-] heybrendan|6 years ago|reply
Allow me to save some time, from TFA:
> Is there a CVE number?
> Yes, see CVE-2019-0174 [1].
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0174
---
> What is RAMBleed?
> Previous attacks exploited the Rowhammer effect to write (or flip) bits in the victim's memory. RAMBleed is different in that it uses Rowhammer for reading data stored inside the computer's physical memory. As the physical memory is shared among all process in the system, this puts all processes at risk.
> What data can be read by RAMBleed?
> While the end-to-end attack we demonstrated read out OpenSSH 7.9's RSA key, RAMBleed can potentially read any data stored in memory. In practice, what can be read depends on the victim program's memory access patterns.
> What technologies are affected by RAMBleed?
> RAMBleed relies on Rowhammer-induced bit flips to read privileged memory. As such, any system that uses Rowhammer-susceptible DIMMs is vulnerable. Previous research has demonstrated bit flips on both DDR3 and DDR4 with TRR (targeted row refresh) enabled. While we demonstrated our attack on a desktop machine and an ECC enabled server machine, Rowhammer attacks have been demonstrated against both mobile devices and laptops. As such, we suspect that many classes of computers are susceptible to RAMBleed.
> How can I mitigate this issue?
> Users can mitigate their risk by upgrading their memory to DDR4 with targeted row refresh (TRR) enabled. While Rowhammer-induced bit flips have been demonstrated on TRR, it is harder to accomplish in practice.
> Memory manufacturers can help mitigate this issue by more rigorously testing for faulty DIMMs. Furthermore, publicly documenting vendor specific TRR implementations will facilitate a stronger development process as security researchers probe such implementations for weaknesses.
[+] [-] joshdance|6 years ago|reply
https://www.kalzumeus.com/2014/04/09/what-heartbleed-can-tea...
I think the marketing campaigns are awesome. Makes it much easier to get resources to fix.
[+] [-] mtgx|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] cr0sh|6 years ago|reply
But there really isn't any other good options.
[+] [-] lacker|6 years ago|reply
[+] [-] polskibus|6 years ago|reply
[+] [-] rasz|6 years ago|reply
[+] [-] the8472|6 years ago|reply
AMD's SEV might help protecting VMs from each other.
[+] [-] jontro|6 years ago|reply
[+] [-] snazz|6 years ago|reply
[+] [-] air7|6 years ago|reply
> Can RAMBleed be detected by antivirus? > We believe that it is very unlikely that any antivirus software on the market currently detects RAMBleed.
[+] [-] tedunangst|6 years ago|reply
[+] [-] sumnulu|6 years ago|reply
[+] [-] thatcat|6 years ago|reply
[+] [-] pkaye|6 years ago|reply
How does one enable this feature? Is it in the BIOS?
[+] [-] horyzen|6 years ago|reply
For those who don't understand: https://en.wikipedia.org/wiki/Feng_shui
[+] [-] tptacek|6 years ago|reply
https://en.wikipedia.org/wiki/Heap_feng_shui
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] javert|6 years ago|reply
I still want to have a reasonable computing experience (e.g. copy + paste works and the experience is kind of like using one computer the normal way).
Any ideas? I was thinking some kind of remote desktop setup with a bunch of cheap boxes, each running Linux, on a LAN.
[+] [-] blablabla123|6 years ago|reply
But the computing experience is quite unreasonable - with copy&paste working though ;)
[+] [-] ClassyJacket|6 years ago|reply
[+] [-] akersten|6 years ago|reply
-- What happens when the cure is worse than the disease (some variants of Spectre), and we "have to" patch because otherwise we're "not secure against this scary sounding thing." It takes a lot of agency away from the IT department to make an informed decision about the appropriate mitigation and threat model, and turns it into a business requirement regardless of the trade-off - because brass "understands" Spectre, they don't understand CVE-1234
-- Or, theoretical exploits that aren't practical in the real world, but we spend a lot of effort or make tradeoffs to fix just because someone needs some material for their PhD.
-- What do you call it when we find another way to read RAM next year - RAMBleed2? I guess.
[+] [-] dmitrygr|6 years ago|reply
[+] [-] vardump|6 years ago|reply
... until someone does it somewhat reliably. I always assume my knowledge and imagination does not come close the collective creativity of exploiters.
[+] [-] tathougies|6 years ago|reply
[+] [-] anon_cow1111|6 years ago|reply
/sarc but also maybe not