Tweet
Security warning: uncommon DRAM bug allows privilege elevation!
Security researchers from Google's Project Zero have found rather uncommon way to escalate privileges in virtually any OS. Few months earlier there was rather uncommon security issue report in LKML. This attack has been named rowhammer, thanks to access pattern which implies excessive use of single row line of DRAM.
What is the problem? DRAM stores bits as charge in capacitor in array of rows and columns. This is generally compact, only requires 1 transistor to work, but charge could dissipate over time so regeneration cycle needed. Some researchers figured out that specially crafted DRAM access pattern could cause excessive leakage on "abused" DRAM row. This in turn can cause bit flip in some cells of row line before refresh cycle occurs, causing DRAM content corruption. This issue has been recognized in DDR4 and DDR4 controllers are required to address this issue. However, it does not tells anything about earlier DDR memories which are widely used to the date.
Some experiments revealed that it is possible to create problematic access pattern under software control. It may or may not cause DRAM data corruption, depending on DRAM manufacturer and IC. Yet, unexpectedly large number of systems proven to be affected. This is hardware-level trouble and OS can't address it directly. In some cases OS can work it around, but it really depends. Catch here is that very specific DRAM access pattern required. This could only be achieved if attacker can flush CPU cache. Else repeated requests will hit CPU cache, failing to abuse DRAM row. On some systems like ARM, cache flushing requires privileged code and it can get on the way, thwarting application level attacks. But on x86 any user mode program can flush cache. This is unprivileged instruction. It can't be intercepted by OS. So x86 systems lack obvious fix for this problem.
Initially it has been thought it only usable for relatively useless memory corruption, causing DoS. Yet, Google's researchers found ways to use this problem to escalate privileges from usermode to kernel, without need of root, or anything, by just corrupting proper memory region. So it could be far more harmful than expected. Actually, there are many ways to trigger this nasty DRAM bug. It is speculated things can go as bad as some malicious java script on some web page can find way to provoke problematic memory access, gaining kernel mode rights if attack has been successful, being able to completely overtake control over system as the result.
Of course Google devs coded tool and put it on github, which allows to check if your system haves problematic DRAM and affected. I think it could be worth of news article on Phoronix, since it also affects *nix like systems and PoC from Google actually deals with these. Yet I can't remember this in Phoronix news. So here it goes.
What is the problem? DRAM stores bits as charge in capacitor in array of rows and columns. This is generally compact, only requires 1 transistor to work, but charge could dissipate over time so regeneration cycle needed. Some researchers figured out that specially crafted DRAM access pattern could cause excessive leakage on "abused" DRAM row. This in turn can cause bit flip in some cells of row line before refresh cycle occurs, causing DRAM content corruption. This issue has been recognized in DDR4 and DDR4 controllers are required to address this issue. However, it does not tells anything about earlier DDR memories which are widely used to the date.
Some experiments revealed that it is possible to create problematic access pattern under software control. It may or may not cause DRAM data corruption, depending on DRAM manufacturer and IC. Yet, unexpectedly large number of systems proven to be affected. This is hardware-level trouble and OS can't address it directly. In some cases OS can work it around, but it really depends. Catch here is that very specific DRAM access pattern required. This could only be achieved if attacker can flush CPU cache. Else repeated requests will hit CPU cache, failing to abuse DRAM row. On some systems like ARM, cache flushing requires privileged code and it can get on the way, thwarting application level attacks. But on x86 any user mode program can flush cache. This is unprivileged instruction. It can't be intercepted by OS. So x86 systems lack obvious fix for this problem.
Initially it has been thought it only usable for relatively useless memory corruption, causing DoS. Yet, Google's researchers found ways to use this problem to escalate privileges from usermode to kernel, without need of root, or anything, by just corrupting proper memory region. So it could be far more harmful than expected. Actually, there are many ways to trigger this nasty DRAM bug. It is speculated things can go as bad as some malicious java script on some web page can find way to provoke problematic memory access, gaining kernel mode rights if attack has been successful, being able to completely overtake control over system as the result.
Of course Google devs coded tool and put it on github, which allows to check if your system haves problematic DRAM and affected. I think it could be worth of news article on Phoronix, since it also affects *nix like systems and PoC from Google actually deals with these. Yet I can't remember this in Phoronix news. So here it goes.
Comment