Row Hammer

[SCGenius]

Anyone think about using row hammer as a vector to gain more btc?

[1715544404]

1715544404

[ca333]

Anyone think about using row hammer as a vector to gain more btc?

i think the bad guys will use everything to gain more wealth. But also we don't forget that a user MUST run a underprivileged process itself on a computer so then its able to use it and this means it don't matter WHAT kind of vuln it uses then, because when a user run untrusted software EVERYTHING can happed with its computer... BUT WHAT I THINK IS MORE A RISK: people can rent other shared servers or VPS and then in example load a software on it (limited privileges) and use the row-hammer vulnerability to GAIN CONTROL OF ALL PHYSICAL MEM AND STEAL ALL DATA(also PRIVKEY when available). also this is only possible when the mem is not monitored by the hoster company and also no proper memtest.

For other readers, this is basics of ROM-HAMMER exploits:
ITS DETAILED EXPLANATION IS HERE: http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
Google project zero published 2 exploits which use the row-hammer effect so for priviliege escalation to allow the Google native client run subset of x86-64 machine instructions within sandbox to escape from sandbox and then be able to directly call system functions (CVE-2015-0565). This is already fixed now, so the cache flush instruction is not allwed now in the NaCl. And this clflush command is prrequisite  to run TO MANY activate commands @memory. so take for Example this assembly LOOP:

Code:

code1a:
  mov (X), %eax  // read from address X
  mov (Y), %ebx  // read from address Y
  clflush (X)    // flush cache for address X
  clflush (Y)    // flush cache for address Y
  jmp code1a

so this is also how they called this VULN because the row of memory cells are being ‘hammered’ with ACTIVATE commands and so it affects the nearby memory-row because the silicon is sooo thin in the NEW DRAM technologies because its developed smaller and smaller..

ok and the other exploit is explained perfect here:

"The second exploit revealed by the Project Zero runs as an unprivileged Linux process on the x86-64 architecture, exploiting the row hammer effect to gain unrestricted access to all physical memory installed in a computer. By combining the disturbance errors with memory spraying, this exploit achieves to alter page table entries (PTEs) used by the virtual memory system for mapping between virtual addresses and physical addresses, gaining that way unrestricted memory access. Due to its nature and inability of the x86-64 architecture to make clflush a privileged machine instruction, this exploit is hardly mitigable on computers that do not use hardware with built-in row hammer prevention mechanisms. While testing the viability of exploits, Project Zero found that about one half out of 29 tested laptops (manufactured between 2010 and 2014, with all of them using non-ECC memory) experienced disturbance errors within a limited amount of time.[1][2][3]

Due to the need for huge numbers of rapidly performed DRAM row activations, row hammer exploits issue large numbers of uncached memory accesses that cause cache misses, which can be detected by monitoring the rate of cache misses for unusual peaks using hardware performance counters.[2] Also, version 6.0.0 of the memtest86 memory diagnostic software, released on February 13, 2015, includes a so-called hammer test that checks whether computer hardware is susceptible to disturbance errors.[4]"

zit-source: wikipedia.org
[1]Dan Goodin (March 10, 2015). "Cutting-edge hack gives super user status by exploiting DRAM weakness". Ars Technica. Retrieved March 10, 2015.
[2]Mark Seaborn; Thomas Dullien (March 9, 2015). "Exploiting the DRAM rowhammer bug to gain kernel privileges"
[3]Liam Tung (March 10, 2015). ""Rowhammer" DRAM flaw could be widespread, says Google". ZDNet. Retrieved March 11, 2015.
[4]"PassMark MemTest86 – Version History". memtest86.com. February 13, 2015. Retrieved March 11, 2015.




#EDIT: google also published test-application: https://github.com/google/rowhammer-test

[2112]

Thanks for posting this.

Anyway, anyone who was using non-ECC memory for the financial applications was already in the state of sin.

The good thing is that I expect the hardware quality to improve after this exploit becomes widely known. New DDR4LP standard apparently already includes the mitigations/workarounds.

One thing I really liked was intECC DRAM chips: DRAM which is pin-compatible with the current non-ECC DRAMs but internally uses ECC. This will allow many people to preserve most of their hardware investments (mostly laptops) by just replacing the DRAM modules.

[gmaxwell]

One thing I really liked was intECC DRAM chips: DRAM which is pin-compatible with the current non-ECC DRAMs but internally uses ECC. This will allow many people to preserve most of their hardware investments (mostly laptops) by just replacing the DRAM modules.

Progress is progress, perhaps that'll convince the cpu/chipset makers to stop price discriminating on ECC capability. That said-- internal ECC doesn't protect the data on the bus or in a number of failure points along the way, so it's not a complete replacement.

It's also, from what I've seen, not clear how much protection ECC actually provides... all data covered by the protection is in the same domain for row aliasing, and typical protection only provides single error correction; soo...

Ever since the first paper on this subject was published I've been running hosts doing anything important with overspec memory running underclocked, as an additional mitigation. A couple percent performance isn't worth any risk of corruption.

[2112]

It's also, from what I've seen, not clear how much protection ECC actually provides... all data covered by the protection is in the same domain for row aliasing, and typical protection only provides single error correction; soo...

Single Error Correction is usually Double Error Detection (SECDED) or even better (Chipkill)

For the intECC case I presume that the internally-erroring chip/module will return something obviously outrageous (all ones, 0xDEADBEEF, maybe something configurable?) so at least the crashes should be obvious and harder to exploit than bitflips.

For the classic ECC all hardware that I know will do Machine Check Fault/Non-Maskable Interrupt and then SIGBUS or equivalent.

I hope this exploit will get sufficient publicity that I can stop having to think about such things like bitsquatting  and similar nonsense.

Ever since the first paper on this subject was published I've been running hosts doing anything important with overspec memory running underclocked, as an additional mitigation. A couple percent performance isn't worth any risk of corruption.

I've been fortunate enough to be bitten by the bitflip early in school, and after that I never did any serious work without parity or ECC RAM. I always take care to verify the operation of machine check exceptions and properly configure memory scrubbers.

The copy of yaccpar in my project lost one bit in this line ("!" became " ", 0x21 to 0x20):

Code:

for( yyxi=yyexca; (*yyxi!= (-1)) || (yyxi[1]!=yystate) ; yyxi += 2 ) ; /* VOID */

changing it to

Code:

for( yyxi=yyexca; (*yyxi!= (-1)) || (yyxi[1] =yystate) ; yyxi += 2 ) ; /* VOID */

which still compiles and even kinda-sometimes-runs. After that I was inoculated to ever trusting a computer without memory error detection or correction. The school computer that produced this error actually had parity DRAM chips, but the school's vendor did a "leg lift" on it, i.e. bent a pin upwards to disable parity error interrupts.