16 ms·

Using Rowhammer bitflips to root Android phones

279 points by ryanlol 10y ago

nullc 10y ago
Perhaps we'll finally start being able to get mobile devices with ECC memory, now that its useful for preventing the nominal owners of devices from having actual control or visibility into their operation.
- igravious 10y ago
  That would be very nice indeed. And on a laptop that comes in less than €2k also would be doubly nice.
  - rasz_pl 10y ago
    Dont count on laptops, Intel treats ECC as one of the market segmentation features. AMD on the other hand supports ECC on everything, even the lowest budget cpu models.
    - Andys 10y ago
      There is now a Mobile Xeon CPU, which is available in the Lenovo P50/P70 series, with ECC RAM.
      - igravious 10y ago
        I priced it there, costs upwards of ~€3k
    - rlpb 10y ago
      If the choice is between insecurity and ECC, market segmentation based on ECC may no longer be possible.
      - dboreham 10y ago
        Another choice is : memory chips that work.
    - gsnedders 10y ago
      As far as I'm aware, AMD don't support ECC on many APUs, which nowadays account for the majority of CPUs they sell.
      - tmzt 10y ago
        I was trying to figure out the roadmap, pricing, and feature sets for their APUs. I gave up. I'm looking for a low-end APU with a fair amount of system ram (not dedicated vram) for use as a graphics coproccessor on a relatively slow bus. I'm finding high end CPUs with integrated graphics, and low-end CPU only chips. The only thing close to what I'm looking for is on an older process.
        paulmd 10y ago
        I think you might be looking for Socket AM1, like the Athlon 5350. If you need ECC, get the Asus AM1M-A. None of the boards have more than 2 RAM slots though. If you have a Microcenter nearby, you can get a $40 discount on an AM1 bundle deal. The motherboard and CPU end up being about $40 total. It makes a decent little Unix server. The Intel J1800/J1900/J2900 boards are pretty cheap too but no ECC. Also, Asrock just announced its Goldmont-based J4205 board.
        tmzt 10y ago
        Thanks, it's for an embedded development project so the low total price is very helpful.
      - paulmd 10y ago
        Most APUs support it. Many motherboard manufacturers choose not to expose this capability and a few sockets don't even expose it. Kabini supports it. Construction cores support it. FM2+ does not, but the mobile socket version FP3 does.
- dancek 10y ago
  Touché.
- ryuuchin 10y ago
  Does ECC memory make this harder to pull off? I was under the impression that ECC memory does not mitigate rowhammer although it may make it harder[1]. > Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word. [1] https://en.wikipedia.org/wiki/Row_hammer#Mitigation https://en.wikipedia.org/wiki/Row_hammer#Mitigation
  - Natanael_L 10y ago
    It reduces the occurrences of successful bitflips with a big margin. So it is helpful, but not perfect.
- jerf 10y ago
  If you want to leverage Rowhammer to get ECC everywhere, don't root phones; figure out how to crack into a media stream you shouldn't have access to, like a Netflix stream or a Bluray rip. Which may very well incorporate rooting phones. But that'll get the industry forces screaming for ECC everywhere (and per other threads, whatever else it takes to make hardware proof against Rowhammer) far more than merely rooting, and they'll scream for it for all hardware. No point in protecting Blurays if the cheapest hardware is what rips the most easily. Proofing hardware against Rowhammer is still necessary even if it does happen to help DRM. It is not possible to write secure code of any kind in an environment where Rowhammer can be performed. The casual dismissiveness the industry seems to have about this problem really surprises me... per the article we all just read, this at least threatens to become a Heartbleed-class problem at some point, but will make Heartbleed remediation look like a walk in the park by comparison. Hardware diversity generally protects us, but there are places where there isn't as much diversity, such as phones, where this could become a massive problem.
  - Natanael_L 10y ago
    Hey, doesn't blu-ray players have web access? Rowhammer via Javascript is already a thing. See where I'm going with this?
niftich 10y ago
This hardware defect just keeps on giving. Since we're unlikely to see larger memory cells again, mitigations will likely be applied. There is a good question on a discussion board [1] from last year about memory scrambling and its utility here; but with no responses. Can these questions be answered? Some points about memory scrambling are also made here [2] by Kim of the 2014 CMU paper. [1] https://groups.google.com/forum/#!topic/rowhammer-discuss/tpiC2MeowrM https://groups.google.com/forum/#!topic/rowhammer-discuss/tp... [2] https://github.com/CMU-SAFARI/rowhammer https://github.com/CMU-SAFARI/rowhammer
- b161023ar 10y ago
  Hmm, so the purpose of memory scrambling is to avoid excessive current swings on the data bus, because they have some kind of undesirable effect on the voltage regulator. I wonder if the result of such current swings is just excessive EMI or power consumption, or if the supply can actually go out of regulation. If you know the scrambling algorithm then you can generate those current swings intentionally...
  - userbinator 10y ago
    I suppose you could get some interesting things to happen if you kick the control loop of the regulator into oscillation and set up some resonance; I wrote an old comment here, related to video cameras, that describes one such experience I had: https://news.ycombinator.com/item?id=9251479 https://news.ycombinator.com/item?id=9251479 It also reminds me of the old CD copy-protection schemes that worked by attempting to (and in a lot of cases, successfully) forcing the scrambling algorithm it uses to output difficult-to-write bit strings: https://www.pricenfees.com/digit-life-archives/magic-figures-detective-story-unreadable-cds https://www.pricenfees.com/digit-life-archives/magic-figures... http://www.cdmediaworld.com/hardware/cdrom/news/0102/sd2_truth.shtml http://www.cdmediaworld.com/hardware/cdrom/news/0102/sd2_tru...
  - qb45 10y ago
    It seems somebody reversed this Intel scrambler at least to some extent (I only skimmed the article): http://www.sciencedirect.com/science/article/pii/S1742287616300032#sec4 http://www.sciencedirect.com/science/article/pii/S1742287616... They suggest that the scrambler is reseeded randomly on every power up so it may be hard to control raw bits on the data bus.
ikeboy 10y ago
So any bets on when a jailbreak based on this is developed?
- desdiv 10y ago
  Root is to Android what jailbreak is to iOS, and the proof of concept[0] that was released is exactly that rooting tool. https://play.google.com/store/apps/details?id=org.iseclab.drammer https://play.google.com/store/apps/details?id=org.iseclab.dr...
  - ikeboy 10y ago
    Except jailbreaks are historically much harder to find than root exploits. iOS 10 still has no public jailbreak. You can see this reflected in the going rates for vulnerabilities, respectively. A remote iOS jailbreak can net you a cool 1.5 million, while Android goes for $200,000.http://arstechnica.com/security/2016/09/1-5-million-bounty-for-iphone-exploits-is-sure-to-bolster-supply-of-0days/ http://arstechnica.com/security/2016/09/1-5-million-bounty-f...
    - m_eiman 10y ago
      Is there any reason to suspect that the same technique wouldn't work to get root on iOS? Then there's the slight problem of rootless that makes it harder to do a permanent jailbreak, but getting root should be a pretty decent step along the way.
      - userbinator 10y ago
        "rootless" is no real obstacle, Rowhammer is almost an arbitrary memory modification exploit. All you need to do(!) is find and modify the appropriate bits, and you will have full control. With "sufficient" effort you should be able to get files in persistent storage modified too, and from there get a permanent jailbreak.
  - ocdtrekkie 10y ago
    Unsurprisingly, Google has purged this app from the store.
smegel 10y ago
> It's not uncommon for different generations of the same phone model to use different memory chips. Actually the same generation of the same phone can use different memory chips and be produced by different manufacturers. It's very common for Apple and Samsung where they can't source enough parts from a single manufacturer.
- Natanael_L 10y ago
  Not just because of not getting enough chips. Sometimes it is plain hedging against potential flaws, or supply chain failures.
  - TorKlingberg 10y ago
    Or just to have a strong position if one manufacturer tries to raise the price.
userbinator 10y ago
On the one hand, you could argue that this is not a good thing because the hardware is fundamentally buggy. On the other hand, and this may be a bit of a contrarian view, if it leads to "the insecurity that gives us freedom", maybe it's not all so bad after all... although in this case, it might be too much of a free-for-all. But given how locked-down mobile devices are by default, this almost feels like a breath of fresh air. https://www.gnu.org/philosophy/right-to-read.en.html https://www.gnu.org/philosophy/right-to-read.en.html http://boingboing.net/2012/01/10/lockdown.html http://boingboing.net/2012/01/10/lockdown.html http://boingboing.net/2012/08/23/civilwar.html http://boingboing.net/2012/08/23/civilwar.html
- zigzigzag 10y ago
  nullc makes a similar comment below. I had thought this was too obvious to bother pointing out, but no, root exploits are not a good thing. The reason phones use kernel sandboxing is to allow users to install apps and have confidence the permissions granted mean something. A root exploit means any app or update you install may turn the phone into spyware, a portable bug-in-your-pocket. The number of users who care about that is measured in billions (all phone users). The number of phone users who care about getting a root shell for their own use is vanishingly small, especially as people who care about that buy phones like the Nexus that have unlocked bootloaders anyway. So no - this sort of exploit is pretty damn bad. The number of people hurt is multiple orders of magnitude higher than the number of people "helped", where that "help" is extremely tenuous anyway.
  - rando832 10y ago
    > The number of phone users who care about getting a root shell for their own use is vanishingly small Only a very small number of people care about how /any/ individual piece of technology could be improved, they have have other things to think about. That is a not a valid argument. It would be better to have it by some other means to get root, but it's not as simple as you make it out. Show a user 2 otherwise identical phones, explain that on one phone, they could do things like tethering, and on the other phone, it's restricted because they can't get root, they will choose the one where they can get root.
rcthompson 10y ago
Is there any way to statically analyze an app for code that might be attempting to execute a rowhammer attack? I'd imagine that rowhammer requires a tight loop doing nothing but writing to the same value in memory repeatedly, or something similarly recognizable. Such a tool could be used to at least keep any malicious apps out of the play store. It would probably be fine if it sometimes gave false positives on innocuous code that a human (at Google) could override after inspecting the suspect code.
- gizmo686 10y ago
  Doubtful. A malicious app could always programatically write the attacking binary after it has been installed. At that point, you no longer have serious performance requirements, so you can make the functionality as obfuscated as necessary. Not to mention the possibility of self modifying code, or downloading the payload from the internet.
  - rcthompson 10y ago
    How much of this is possible within an Android app? Are Android apps allowed to download a file and then make it executable?
    - BoorishBears 10y ago
      With root? Yes, you don't even need special permissions past an Internet permission. SuperSU is popular app used to limit which apps can get root permission via the su binary. But depending on the way the device is rooted you can actually use root permission to remove SuperSU while leaving the binary that grants root in-tact. This allows you to create a "backdoor" in which your "legitimate app" asks for root, then downloads an update and deletes SuperSU, allowing the payload (and any other apps) to get root access silently.
      - rcthompson 10y ago
        If you already have root, then you don't need to execute a rowhammer attack to gain root. I'm asking if an Android app with no root access on an un-rooted phone has a way to execute code that wasn't included with the apk, in order to hide the code that executes the rowhammer attack. If not, then a static analyzer that detects rowhammer attacks in the code of an apk would be sufficient.
jasoncchild 10y ago
I first read bout this a few months ago. Coming from a hardware background I was particularly struck by how damned clever this is!
- PhantomGremlin 10y ago
  It's clever because you aren't a memory design or test engineer. This type of problem has been known and tested for since shortly after DRAM was invented. E.g. here's a 1977 databook from Mostek, at the time the premier DRAM manufacturer: https://archive.org/stream/bitsavers_mostekdataryProducts_17995288/1977_Mostek_Memory_Products_djvu.txt https://archive.org/stream/bitsavers_mostekdataryProducts_17... Look at these tests in particular: Adjacent Row Disturb Refresh Column Disturb Pattern Sensitivity Look at the details of the column disturb test: Column is written with an all ones data pattern an "0" is then written into row of the column 100 times followed by reading all other bits of the column and checking each bit for a logic "1" output. Row of the column is then rewritten to a "1" and the procedure is repeated for rows 1,2,3, ... 63 of the column under test. The entire procedure is then repeated for columns 1-63. That particular test step is only repeated 100 times, because it's a production test and short test time is critical. You can bet that in design verification the chip was characterized a lot more thoroughly. The downside of increasing memory sizes over the decades (now literally billions of bits in a single chip rather than thousands) is reduced design margins. So we get rowhammer. You can bet that rowhammer did not come as any surprise to key engineers at the DRAM manufacturers. They just didn't take it very seriously as a possible real world problem, because the access patterns required to cause it are atypical from those of "normal" operation.
  - osivertsson 10y ago
    Thanks for the interesting historical reference! As you state, this type of problem is not new, and as noted at [1] e.g. Intel have taken this seriously on their Xeon lineup for a while. It's a shame (LP)DDR4 standards did not make Target Row Refresh mandatory. From the FAQ at [2]: I have a phone with LPDDR4 memory. Am I safe against Drammer attacks? Again, we don’t know. Chances are that your DRAM comes with the Target Row Refresh (TRR) mitigation, which makes it harder – but still not impossible, in theory – to induce bit flips. Moreover, TRR for LPDDR4 is optional, so your DRAM manufacturer may have decided to drop this technique and leave you vulnerable. [1] https://en.wikipedia.org/wiki/Row_hammer#Mitigation https://en.wikipedia.org/wiki/Row_hammer#Mitigation [2] https://www.vusec.net/projects/drammer/ https://www.vusec.net/projects/drammer/
deleted 10y ago
[deleted]
beambot 10y ago
Dumb question (maybe OT): why is rooting phones so hard in the first place? Shouldn't root permissions be part of device ownership (akin to fair use)? Why do I have to hack my own phone to get unfettered access?
- grawlinson 10y ago
  Most likely related to strict FCC regulations regarding the mobile transceivers. And it's always been done this way, old "dumb phones" have always been closed proprietary blobs.
  - askvictor 10y ago
    That doesn't explain phones with easily and officially supported unlockable bootloaders (eg Nexus). The transceiver is, in any case, a seperate processor (the baseband) which is much more locked down. The real reason is that hardware manufacturers like control.
    - Jonnax 10y ago
      Well there's also the part where root access fundamentally breaks the security model of the device. I'd say it's a better way of running a consumer device for the typical user. For example, any application you run on a Windows PC even without administrator access could access and upload your web browser profiles. The average user doesn't expect this. But a lot of manufactures do give you the choice to run your own firmwares which can have the root user access. It'll require a bootloader unlock which removes the signature checking. For example: HTC: http://www.htcdev.com/bootloader http://www.htcdev.com/bootloader Motorolla: https://motorola-global-portal.custhelp.com/app/standalone/bootloader/unlock-your-device-a https://motorola-global-portal.custhelp.com/app/standalone/b... Sony: http://developer.sonymobile.com/unlockbootloader/unlock-yourboot-loader/ http://developer.sonymobile.com/unlockbootloader/unlock-your... LG: https://developer.lge.com/resource/mobile/RetrieveBootloader.dev?categoryTypeCode=ANRS https://developer.lge.com/resource/mobile/RetrieveBootloader... Huawei: https://emui.huawei.com/en/plugin/unlock/index https://emui.huawei.com/en/plugin/unlock/index Couldn't find an official page for Samsung but it looks like it's a matter of running fastboot after enabling OEM unlock in developer settings. The other side of this is that there are quite a few devices that are carrier branded. And usually what happens is that carrier requests that the phone's bootloader is not unlockable. Sadly unlike how Apple can sell their phone without any carrier modifications, Android manufacturers have to accept these kinds of changes otherwise they won't be able to sell their phone.
Steeeve 10y ago
> In a statement, Google officials wrote: "After researchers reported this issue to our Vulnerability Rewards Program, we worked closely with them to deeply understand it in order to better secure our users. We’ve developed a mitigation which we will include in our upcoming November security bulletin." Then why am I reading about this in October?
- gcb0 10y ago
  because nobody dares publishing anything on Android at Google without going past legal, pr and recently the founder
- bagacrap 10y ago
  Presumably you're asking why you're hearing about it before the fix is out. Perhaps Google is trying to apply public pressure to the manufacturers/carriers to actually update their devices since they have a habit of not pushing critical security updates very quickly.
- burkaman 10y ago
  Because the existence of this exploit was already publicly known, as you can see in the many links in that article. That statement doesn't have any new information for people who want to break into your phone.
dancek 10y ago
So, the proof of concept code is at https://github.com/vusec/drammer https://github.com/vusec/drammer . Can we get a reliable rooting tool based on this?
cairo_x 10y ago
There's something about Rowhammer that warms the cockles of my heart.
deleted 10y ago
[deleted]
SixSigma 10y ago
Rowhammer was first presented in 2014 https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Row_hammer
Aissen 10y ago
Very interesting application of the rowhammer. Funny that it comes at the same time http://dirtycow.ninja http://dirtycow.ninja allows us to write very reliable and portable exploits (which should be applicable to Android).
tmzt 10y ago
Interesting. This is not something that has a simple fix and can be patched. The arms race continues. Or we could end it and give users (limited) root access to their stock phones. Let us run OCI containers with restricted root user accounts. Bind mount certain filesystems given the correct Android permissions, such as the SD card or internal storage, or the user's emulated root. Or supported nested ARM virtualization. Modern Linux supports a uid 0 with less than complete access in a cgroup, using the LSM to regulate specific capabilities, or creating the cgroup with limited caps to begin with. Make access to areas the carrier considers sensitive conditional on a capability, or limit access to the full video decode hardware or shared memory from this root jail. I have been able to compile but not run the runc binary from OCI/docker/rkt. Nested cgroupfs would solve a lot of these restrictions.

279 points by ryanlol 10y ago

nullc 10y ago

Perhaps we'll finally start being able to get mobile devices with ECC memory, now that its useful for preventing the nominal owners of devices from having actual control or visibility into their operation.

igravious 10y ago
That would be very nice indeed. And on a laptop that comes in less than €2k also would be doubly nice.
- rasz_pl 10y ago
  Dont count on laptops, Intel treats ECC as one of the market segmentation features. AMD on the other hand supports ECC on everything, even the lowest budget cpu models.
  - Andys 10y ago
    There is now a Mobile Xeon CPU, which is available in the Lenovo P50/P70 series, with ECC RAM.
    - igravious 10y ago
      I priced it there, costs upwards of ~€3k
  - rlpb 10y ago
    If the choice is between insecurity and ECC, market segmentation based on ECC may no longer be possible.
    - dboreham 10y ago
      Another choice is : memory chips that work.
  - gsnedders 10y ago
    As far as I'm aware, AMD don't support ECC on many APUs, which nowadays account for the majority of CPUs they sell.
    - tmzt 10y ago
      I was trying to figure out the roadmap, pricing, and feature sets for their APUs. I gave up. I'm looking for a low-end APU with a fair amount of system ram (not dedicated vram) for use as a graphics coproccessor on a relatively slow bus. I'm finding high end CPUs with integrated graphics, and low-end CPU only chips. The only thing close to what I'm looking for is on an older process.
      - paulmd 10y ago
        I think you might be looking for Socket AM1, like the Athlon 5350. If you need ECC, get the Asus AM1M-A. None of the boards have more than 2 RAM slots though. If you have a Microcenter nearby, you can get a $40 discount on an AM1 bundle deal. The motherboard and CPU end up being about $40 total. It makes a decent little Unix server. The Intel J1800/J1900/J2900 boards are pretty cheap too but no ECC. Also, Asrock just announced its Goldmont-based J4205 board.
        tmzt 10y ago
        Thanks, it's for an embedded development project so the low total price is very helpful.
    - paulmd 10y ago
      Most APUs support it. Many motherboard manufacturers choose not to expose this capability and a few sockets don't even expose it. Kabini supports it. Construction cores support it. FM2+ does not, but the mobile socket version FP3 does.
dancek 10y ago
Touché.
ryuuchin 10y ago
Does ECC memory make this harder to pull off? I was under the impression that ECC memory does not mitigate rowhammer although it may make it harder[1]. > Tests show that simple ECC solutions, providing single-error correction and double-error detection (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per memory word. [1] https://en.wikipedia.org/wiki/Row_hammer#Mitigation https://en.wikipedia.org/wiki/Row_hammer#Mitigation
- Natanael_L 10y ago
  It reduces the occurrences of successful bitflips with a big margin. So it is helpful, but not perfect.
jerf 10y ago
If you want to leverage Rowhammer to get ECC everywhere, don't root phones; figure out how to crack into a media stream you shouldn't have access to, like a Netflix stream or a Bluray rip. Which may very well incorporate rooting phones. But that'll get the industry forces screaming for ECC everywhere (and per other threads, whatever else it takes to make hardware proof against Rowhammer) far more than merely rooting, and they'll scream for it for all hardware. No point in protecting Blurays if the cheapest hardware is what rips the most easily. Proofing hardware against Rowhammer is still necessary even if it does happen to help DRM. It is not possible to write secure code of any kind in an environment where Rowhammer can be performed. The casual dismissiveness the industry seems to have about this problem really surprises me... per the article we all just read, this at least threatens to become a Heartbleed-class problem at some point, but will make Heartbleed remediation look like a walk in the park by comparison. Hardware diversity generally protects us, but there are places where there isn't as much diversity, such as phones, where this could become a massive problem.
- Natanael_L 10y ago
  Hey, doesn't blu-ray players have web access? Rowhammer via Javascript is already a thing. See where I'm going with this?

niftich 10y ago

This hardware defect just keeps on giving. Since we're unlikely to see larger memory cells again, mitigations will likely be applied. There is a good question on a discussion board [1] from last year about memory scrambling and its utility here; but with no responses. Can these questions be answered? Some points about memory scrambling are also made here [2] by Kim of the 2014 CMU paper. [1] https://groups.google.com/forum/#!topic/rowhammer-discuss/tpiC2MeowrM https://groups.google.com/forum/#!topic/rowhammer-discuss/tp... [2] https://github.com/CMU-SAFARI/rowhammer https://github.com/CMU-SAFARI/rowhammer

b161023ar 10y ago
Hmm, so the purpose of memory scrambling is to avoid excessive current swings on the data bus, because they have some kind of undesirable effect on the voltage regulator. I wonder if the result of such current swings is just excessive EMI or power consumption, or if the supply can actually go out of regulation. If you know the scrambling algorithm then you can generate those current swings intentionally...
- userbinator 10y ago
  I suppose you could get some interesting things to happen if you kick the control loop of the regulator into oscillation and set up some resonance; I wrote an old comment here, related to video cameras, that describes one such experience I had: https://news.ycombinator.com/item?id=9251479 https://news.ycombinator.com/item?id=9251479 It also reminds me of the old CD copy-protection schemes that worked by attempting to (and in a lot of cases, successfully) forcing the scrambling algorithm it uses to output difficult-to-write bit strings: https://www.pricenfees.com/digit-life-archives/magic-figures-detective-story-unreadable-cds https://www.pricenfees.com/digit-life-archives/magic-figures... http://www.cdmediaworld.com/hardware/cdrom/news/0102/sd2_truth.shtml http://www.cdmediaworld.com/hardware/cdrom/news/0102/sd2_tru...
- qb45 10y ago
  It seems somebody reversed this Intel scrambler at least to some extent (I only skimmed the article): http://www.sciencedirect.com/science/article/pii/S1742287616300032#sec4 http://www.sciencedirect.com/science/article/pii/S1742287616... They suggest that the scrambler is reseeded randomly on every power up so it may be hard to control raw bits on the data bus.

ikeboy 10y ago

So any bets on when a jailbreak based on this is developed?

desdiv 10y ago
Root is to Android what jailbreak is to iOS, and the proof of concept[0] that was released is exactly that rooting tool. https://play.google.com/store/apps/details?id=org.iseclab.drammer https://play.google.com/store/apps/details?id=org.iseclab.dr...
- ikeboy 10y ago
  Except jailbreaks are historically much harder to find than root exploits. iOS 10 still has no public jailbreak. You can see this reflected in the going rates for vulnerabilities, respectively. A remote iOS jailbreak can net you a cool 1.5 million, while Android goes for $200,000.http://arstechnica.com/security/2016/09/1-5-million-bounty-for-iphone-exploits-is-sure-to-bolster-supply-of-0days/ http://arstechnica.com/security/2016/09/1-5-million-bounty-f...
  - m_eiman 10y ago
    Is there any reason to suspect that the same technique wouldn't work to get root on iOS? Then there's the slight problem of rootless that makes it harder to do a permanent jailbreak, but getting root should be a pretty decent step along the way.
    - userbinator 10y ago
      "rootless" is no real obstacle, Rowhammer is almost an arbitrary memory modification exploit. All you need to do(!) is find and modify the appropriate bits, and you will have full control. With "sufficient" effort you should be able to get files in persistent storage modified too, and from there get a permanent jailbreak.
- ocdtrekkie 10y ago
  Unsurprisingly, Google has purged this app from the store.

smegel 10y ago

> It's not uncommon for different generations of the same phone model to use different memory chips. Actually the same generation of the same phone can use different memory chips and be produced by different manufacturers. It's very common for Apple and Samsung where they can't source enough parts from a single manufacturer.

Natanael_L 10y ago
Not just because of not getting enough chips. Sometimes it is plain hedging against potential flaws, or supply chain failures.
- TorKlingberg 10y ago
  Or just to have a strong position if one manufacturer tries to raise the price.

userbinator 10y ago

On the one hand, you could argue that this is not a good thing because the hardware is fundamentally buggy. On the other hand, and this may be a bit of a contrarian view, if it leads to "the insecurity that gives us freedom", maybe it's not all so bad after all... although in this case, it might be too much of a free-for-all. But given how locked-down mobile devices are by default, this almost feels like a breath of fresh air. https://www.gnu.org/philosophy/right-to-read.en.html https://www.gnu.org/philosophy/right-to-read.en.html http://boingboing.net/2012/01/10/lockdown.html http://boingboing.net/2012/01/10/lockdown.html http://boingboing.net/2012/08/23/civilwar.html http://boingboing.net/2012/08/23/civilwar.html

zigzigzag 10y ago
nullc makes a similar comment below. I had thought this was too obvious to bother pointing out, but no, root exploits are not a good thing. The reason phones use kernel sandboxing is to allow users to install apps and have confidence the permissions granted mean something. A root exploit means any app or update you install may turn the phone into spyware, a portable bug-in-your-pocket. The number of users who care about that is measured in billions (all phone users). The number of phone users who care about getting a root shell for their own use is vanishingly small, especially as people who care about that buy phones like the Nexus that have unlocked bootloaders anyway. So no - this sort of exploit is pretty damn bad. The number of people hurt is multiple orders of magnitude higher than the number of people "helped", where that "help" is extremely tenuous anyway.
- rando832 10y ago
  > The number of phone users who care about getting a root shell for their own use is vanishingly small Only a very small number of people care about how /any/ individual piece of technology could be improved, they have have other things to think about. That is a not a valid argument. It would be better to have it by some other means to get root, but it's not as simple as you make it out. Show a user 2 otherwise identical phones, explain that on one phone, they could do things like tethering, and on the other phone, it's restricted because they can't get root, they will choose the one where they can get root.

rcthompson 10y ago

Is there any way to statically analyze an app for code that might be attempting to execute a rowhammer attack? I'd imagine that rowhammer requires a tight loop doing nothing but writing to the same value in memory repeatedly, or something similarly recognizable. Such a tool could be used to at least keep any malicious apps out of the play store. It would probably be fine if it sometimes gave false positives on innocuous code that a human (at Google) could override after inspecting the suspect code.

gizmo686 10y ago
Doubtful. A malicious app could always programatically write the attacking binary after it has been installed. At that point, you no longer have serious performance requirements, so you can make the functionality as obfuscated as necessary. Not to mention the possibility of self modifying code, or downloading the payload from the internet.
- rcthompson 10y ago
  How much of this is possible within an Android app? Are Android apps allowed to download a file and then make it executable?
  - BoorishBears 10y ago
    With root? Yes, you don't even need special permissions past an Internet permission. SuperSU is popular app used to limit which apps can get root permission via the su binary. But depending on the way the device is rooted you can actually use root permission to remove SuperSU while leaving the binary that grants root in-tact. This allows you to create a "backdoor" in which your "legitimate app" asks for root, then downloads an update and deletes SuperSU, allowing the payload (and any other apps) to get root access silently.
    - rcthompson 10y ago
      If you already have root, then you don't need to execute a rowhammer attack to gain root. I'm asking if an Android app with no root access on an un-rooted phone has a way to execute code that wasn't included with the apk, in order to hide the code that executes the rowhammer attack. If not, then a static analyzer that detects rowhammer attacks in the code of an apk would be sufficient.

jasoncchild 10y ago

I first read bout this a few months ago. Coming from a hardware background I was particularly struck by how damned clever this is!

PhantomGremlin 10y ago
It's clever because you aren't a memory design or test engineer. This type of problem has been known and tested for since shortly after DRAM was invented. E.g. here's a 1977 databook from Mostek, at the time the premier DRAM manufacturer: https://archive.org/stream/bitsavers_mostekdataryProducts_17995288/1977_Mostek_Memory_Products_djvu.txt https://archive.org/stream/bitsavers_mostekdataryProducts_17... Look at these tests in particular: Adjacent Row Disturb Refresh Column Disturb Pattern Sensitivity Look at the details of the column disturb test: Column is written with an all ones data pattern an "0" is then written into row of the column 100 times followed by reading all other bits of the column and checking each bit for a logic "1" output. Row of the column is then rewritten to a "1" and the procedure is repeated for rows 1,2,3, ... 63 of the column under test. The entire procedure is then repeated for columns 1-63. That particular test step is only repeated 100 times, because it's a production test and short test time is critical. You can bet that in design verification the chip was characterized a lot more thoroughly. The downside of increasing memory sizes over the decades (now literally billions of bits in a single chip rather than thousands) is reduced design margins. So we get rowhammer. You can bet that rowhammer did not come as any surprise to key engineers at the DRAM manufacturers. They just didn't take it very seriously as a possible real world problem, because the access patterns required to cause it are atypical from those of "normal" operation.
- osivertsson 10y ago
  Thanks for the interesting historical reference! As you state, this type of problem is not new, and as noted at [1] e.g. Intel have taken this seriously on their Xeon lineup for a while. It's a shame (LP)DDR4 standards did not make Target Row Refresh mandatory. From the FAQ at [2]: I have a phone with LPDDR4 memory. Am I safe against Drammer attacks? Again, we don’t know. Chances are that your DRAM comes with the Target Row Refresh (TRR) mitigation, which makes it harder – but still not impossible, in theory – to induce bit flips. Moreover, TRR for LPDDR4 is optional, so your DRAM manufacturer may have decided to drop this technique and leave you vulnerable. [1] https://en.wikipedia.org/wiki/Row_hammer#Mitigation https://en.wikipedia.org/wiki/Row_hammer#Mitigation [2] https://www.vusec.net/projects/drammer/ https://www.vusec.net/projects/drammer/

deleted 10y ago

[deleted]

beambot 10y ago

Dumb question (maybe OT): why is rooting phones so hard in the first place? Shouldn't root permissions be part of device ownership (akin to fair use)? Why do I have to hack my own phone to get unfettered access?

grawlinson 10y ago
Most likely related to strict FCC regulations regarding the mobile transceivers. And it's always been done this way, old "dumb phones" have always been closed proprietary blobs.
- askvictor 10y ago
  That doesn't explain phones with easily and officially supported unlockable bootloaders (eg Nexus). The transceiver is, in any case, a seperate processor (the baseband) which is much more locked down. The real reason is that hardware manufacturers like control.
  - Jonnax 10y ago
    Well there's also the part where root access fundamentally breaks the security model of the device. I'd say it's a better way of running a consumer device for the typical user. For example, any application you run on a Windows PC even without administrator access could access and upload your web browser profiles. The average user doesn't expect this. But a lot of manufactures do give you the choice to run your own firmwares which can have the root user access. It'll require a bootloader unlock which removes the signature checking. For example: HTC: http://www.htcdev.com/bootloader http://www.htcdev.com/bootloader Motorolla: https://motorola-global-portal.custhelp.com/app/standalone/bootloader/unlock-your-device-a https://motorola-global-portal.custhelp.com/app/standalone/b... Sony: http://developer.sonymobile.com/unlockbootloader/unlock-yourboot-loader/ http://developer.sonymobile.com/unlockbootloader/unlock-your... LG: https://developer.lge.com/resource/mobile/RetrieveBootloader.dev?categoryTypeCode=ANRS https://developer.lge.com/resource/mobile/RetrieveBootloader... Huawei: https://emui.huawei.com/en/plugin/unlock/index https://emui.huawei.com/en/plugin/unlock/index Couldn't find an official page for Samsung but it looks like it's a matter of running fastboot after enabling OEM unlock in developer settings. The other side of this is that there are quite a few devices that are carrier branded. And usually what happens is that carrier requests that the phone's bootloader is not unlockable. Sadly unlike how Apple can sell their phone without any carrier modifications, Android manufacturers have to accept these kinds of changes otherwise they won't be able to sell their phone.

Steeeve 10y ago

> In a statement, Google officials wrote: "After researchers reported this issue to our Vulnerability Rewards Program, we worked closely with them to deeply understand it in order to better secure our users. We’ve developed a mitigation which we will include in our upcoming November security bulletin." Then why am I reading about this in October?

gcb0 10y ago
because nobody dares publishing anything on Android at Google without going past legal, pr and recently the founder
bagacrap 10y ago
Presumably you're asking why you're hearing about it before the fix is out. Perhaps Google is trying to apply public pressure to the manufacturers/carriers to actually update their devices since they have a habit of not pushing critical security updates very quickly.
burkaman 10y ago
Because the existence of this exploit was already publicly known, as you can see in the many links in that article. That statement doesn't have any new information for people who want to break into your phone.

dancek 10y ago

So, the proof of concept code is at https://github.com/vusec/drammer https://github.com/vusec/drammer . Can we get a reliable rooting tool based on this?

cairo_x 10y ago

There's something about Rowhammer that warms the cockles of my heart.

deleted 10y ago

[deleted]

SixSigma 10y ago

Rowhammer was first presented in 2014 https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Row_hammer

Aissen 10y ago

Very interesting application of the rowhammer. Funny that it comes at the same time http://dirtycow.ninja http://dirtycow.ninja allows us to write very reliable and portable exploits (which should be applicable to Android).

tmzt 10y ago

Interesting. This is not something that has a simple fix and can be patched. The arms race continues. Or we could end it and give users (limited) root access to their stock phones. Let us run OCI containers with restricted root user accounts. Bind mount certain filesystems given the correct Android permissions, such as the SD card or internal storage, or the user's emulated root. Or supported nested ARM virtualization. Modern Linux supports a uid 0 with less than complete access in a cgroup, using the LSM to regulate specific capabilities, or creating the cgroup with limited caps to begin with. Make access to areas the carrier considers sensitive conditional on a capability, or limit access to the full video decode hardware or shared memory from this root jail. I have been able to compile but not run the runc binary from OCI/docker/rkt. Nested cgroupfs would solve a lot of these restrictions.