Slashdot Mirror

← Back to Stories (view on slashdot.org)

Every Android Device Launched Since 2012 Impacted By RAMpage Vulnerability (bleepingcomputer.com)

Posted by msmash on from the security-woes dept.

Almost all Android devices released since 2012 are vulnerable to RAMpage bug, an international team of academics has revealed today. From a report: The vulnerability, tracked as CVE-2018-9442, is a variation of the Rowhammer attack. Rowhammer is a hardware bug in modern memory cards. A few years back researchers discovered that when someone would send repeated write/read requests to the same row of memory cells, the write/read operations would create an electrical field that would alter data stored on nearby memory. In the following years, researchers discovered that Rowhammer-like attacks affected personal computers, virtual machines, and Android devices. Through further researcher, they also found they could execute Rowhammer attacks via JavaScript code, GPU cards, and network packets.

51 of 83 comments (clear)

  1. Is iOS affected too... by SuperKendall · · Score: 4, Interesting

    The article said that Apple iOS devices may be vulnerable to, but since this is a kind of Rowhammer attack, which Apple mitigated in 2015, I wonder if it is?

    It would be nice if the article (and researchers) were more clear about other platforms being vulnerable...

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Is iOS affected too... by Tough+Love · · Score: 1

      this is a kind of Rowhammer attack, which Apple mitigated in 2015

      If Apple says they mitigated it years ago, even without knowing about current research, then we can rest assured that they told the truth just as always, right? Right?

      And Apple cultists with mod points will not stand for any criticism. No, none. Nor have any concept of ethical use of moderation, just like Apple itself has no concept of ethics.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
  2. Re:That seems like a very easy solution by AmiMoJo · · Score: 2

    The actual paper speculates that all devices since 2012 "may" be vulnerable. There is an app you can download to test, but it's not clear what it actually does.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  3. Re:That seems like a very easy solution by SuperKendall · · Score: 4, Insightful

    At some point one of these vulnerability checking apps will be found to be it's own kind of trojan, instead uploading contacts or installing spyware...

    After all, seems reasonable to grant a vulnerability checking app full permissions right?

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  4. Re:That seems like a very easy solution by olsmeister · · Score: 2

    I'm guessing people that write compilers would say "meh this isn't my issue". And they wouldn't be wrong - it would require them to spend time to do it well, legitimate users wouldn't care about the feature, and it would probably slow everything down.. Trying to solve security issues by making a compiler/malware scanning FrankenProgram is just a bad idea. Anyway, whoever is writing the code probably would just use an older compiler.

  5. Re:That seems like a very easy solution by YuppieScum · · Score: 1

    I'm guessing that anyone who wanted to make malicious use of this behaviour wouldn't use a compiler designed to mitigate the issue...

    --
    This sig left unintentionally blank.
  6. Rowhammer is garbage by ComputerGeek01 · · Score: 3, Insightful

    Unless your objective is to crash the device, rowhammer is a useless technique and even then there are far easier ways to accomplish this. Until you can tell me EXACTLY what cells you are modifying and in what way, you will NEVER be able to utilize this vulnerability interesting observation for any kind of useful exploit. Even then, you would have to know WHAT you are modifying and even the most basic memory page protection prevents that. #SLOWNEWSDAY

    1. Re:Rowhammer is garbage by geschbacher79 · · Score: 1

      That's exactly my feeling on this as well. It seems much more likely that you could use this to crash a device much more than you could ever use it to perform an attack (since you don't know exactly which cells your memory is in or what the neighbors look like). I'm still not even convinced the Spectre/Meltdown bugs are actually useful in the real world despite all of the hype. To me, a lot of these vulnerabilities boil down to "Oh if you let arbitrary code run, it can run other arbitrary code". Unless you can show an exploit that involves a browser visiting a malicious URL in a real-world scenario, I think this is a lot of smoke.

    2. Re:Rowhammer is garbage by xanthos · · Score: 2

      Its silly season. With BlackHat and Defcon on the horizon you can expect to see lots of similar "security researcher" announcements over the next few weeks.

      --
      Average Intelligence is a Scary Thing
    3. Re:Rowhammer is garbage by bluefoxlucid · · Score: 4, Informative

      Pretty much, except for the last bit: memory page protection is administrative, not technical. The CPU says, "You can't write to address 0xC0004000" and you don't. If you write to 0xB0004000 and create electrical fields messing with 0xC0004000, that's physical and bypasses any code that says no you can't.

      It's like approaching a hotel key card lock with dynamite.

      --
      Support my political activism on Patreon.
    4. Re:Rowhammer is garbage by iggymanz · · Score: 1

      it's garbage hardware design, yes.

      electrical engineers have failed in their design of memory and CPU.

    5. Re:Rowhammer is garbage by Anonymous Coward · · Score: 4, Informative

      Unless your objective is to crash the device, rowhammer is a useless technique and even then there are far easier ways to accomplish this. Until you can tell me EXACTLY what cells you are modifying and in what way, you will NEVER be able to utilize this vulnerability interesting observation for any kind of useful exploit. Even then, you would have to know WHAT you are modifying and even the most basic memory page protection prevents that. #SLOWNEWSDAY

      Exploits have been known since 2015. Basically you fill memory with Page Table Entries, then you corrupt them until a bit flips which gives you access to write your on PTE. From that point, you own the machine. I have not heard of any fixes for this.

    6. Re:Rowhammer is garbage by bobby · · Score: 1

      it's garbage hardware design, yes.

      electrical engineers' managers have failed in their managment of design of memory and CPU.

      FTFY.

    7. Re:Rowhammer is garbage by onepoint · · Score: 1

      I am thinking of what you are writing, and then I ask myself "what's the value of the attack",
      a few things of value come into play

      A) the financial calculation of taking out the competitor, design the "attack" as a vendor specific. Enough product problems and they will stop making it and the product will become another Edsel

      B) design the attack to work on specific types of networks that have specific software ( variation of the above ), take for example the security camera's, if the attack can be designed for that, a breach in the physical security system will occur or like the attack on centrifuges in Iran, sometimes you just need things to crash

      C) here is where it does get scary. Design to crash the system. think automotive tesla type system, autopilot on, crash all the redundant systems first, then primaries. smack into the wall at 65mph, it's going to hurt.

      that's what I think this is for.

      --
      if you see me, smile and say hello.
    8. Re:Rowhammer is garbage by Anubis+IV · · Score: 2

      Unless you can show an exploit that involves a browser visiting a malicious URL in a real-world scenario, I think this is a lot of smoke.

      A number of proofs of concept were published that demonstrated how the exploits could be abused using Javascript. For instance, here's a simple example that could be used to provide a script with access to the contents of your memory if your browser/system/chip hasn't been updated to prevent such an attack. This may not impact everyday users much, but if you're on a known, shared system (e.g. AWS, Azure, WordPress, Squarespace, etc.) it becomes far easier to abuse, since you could do something like, say, initiate a request that would load a private key into memory, use a sidechannel attack of these sorts to log the memory out to file, and then suddenly have the keys to the kingdom, which very much so would affect everyday users at that point.

      Rowhammer is less directly useful, but it can be used to get a foot in the door. All you need is for the right bits in a page table to flip in just the right way one time to be able to gain complete control of an application with root access. Sure, it's more likely to crash the device than grant you control, but Android users represent a large enough collective target that there'd be plenty of successful exploits accomplished across the user base, and for the remainder of the users it would constitute a major annoyance and frustration as their memory routinely became corrupted, resulting in reboots.

    9. Re:Rowhammer is garbage by Dwedit · · Score: 1

      People have working root exploits that use Rowhammer, so it's not useless.

    10. Re:Rowhammer is garbage by iggymanz · · Score: 1

      No, blame for bad design that causes damages or harm is shared by the engineer, that's how profession works. The engineer who works for PHB that mandates design of bridges that kills shares the guilt for deaths, he was whore who sold himself out.

    11. Re:Rowhammer is garbage by Aighearach · · Score: 1

      Plus, my android devices are all so slow that if they were running this type of thing they'd be unusable to me before it even succeeded! They're going to need to run it for weeks, crashing it a zillion times on the way, just to figure out where the memory locations are. They'd never get there without getting wiped.

    12. Re:Rowhammer is garbage by DamnOregonian · · Score: 1

      I wish you had researched a bit before posting this. A lot of people modded incorrect information as insightful.
      There are working rowhammer privilege escalations.
      The main one I remember involves mmap()ing a whole asston of anonymous pages, essentially to the point where you fill an appreciable amount of RAM with page table entries. At that point you can use some inference to target those PTEs with good probability of success. As soon as you can modify one PTE to give your process RW access to an arbitrary page in RAM (hopefully full of PTE entries as well) you now have unfettered access to the entire address space of the machine.

    13. Re:Rowhammer is garbage by Tough+Love · · Score: 1

      Until you can tell me EXACTLY what cells you are modifying and in what way, you will NEVER be able to utilize this vulnerability interesting observation for any kind of useful exploit

      And everyone should cast aside their caution and put their faith in Slashdot pronouncements of confident self appointed security expert, exactly why?

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    14. Re:Rowhammer is garbage by Aighearach · · Score: 1

      ...if you're on a known, shared system (e.g. AWS, Azure, WordPress, Squarespace, etc.) it becomes far easier to abuse, since you could do something like, say, initiate a request that would load a private key into memory, use a sidechannel attack of these sorts to log the memory...

      If you have a private key to load, and you're allowed to do that from javascript, you can just do it directly, there is no need to play games with this. Also, is it true that these services give you some sort of enhanced access where you'd be able to do something special by using your own key from a device that had already logged in with a user account? Wouldn't the key need to be the right key anyways? And if you have my key to load into memory, why would you also need to run the code on my mobile device?

      It sounds like a small portion of three different attack vectors cut and pasted together into an unrealistic threat. That said, I wouldn't install an app onto a mobile device that was capable of doing something to harm me; IMO mobile maps and search are huge conveniences, but mobile banking is for idiots, and controlling business-critical network services from a "mobile" device is also for idiots; get a laptop, or any other portable device that runs a full OS if you have those responsibilities!

    15. Re:Rowhammer is garbage by lexman098 · · Score: 1

      I don't think they failed. They just had different objectives at the time than you would have liked (with 20/20 hindsight). The exploits you mention are based on taking advantage of circuits that were designed for increased performance. If the memory card was more robust to electric field attacks it would have to use redundant or shielded or more spaced out cells (less memory per area) or a stronger supply voltage (more power). You could probably find a way to trade off speed for robustness as well. When you go to buy SD cards do you not shop for the cheapest, fastest, highest capacity one you can find?

    16. Re:Rowhammer is garbage by DigiShaman · · Score: 1

      create electrical fields messing with 0xC0004000

      If you somehow manage to bit-flip that address (assuming non-ECC here), you just corrupted the data. So what good is reading corrupted data?? It the wrong address, and you'll cause a kernel panic and lose the running process you're trying to access in the first place.

      Speaking of ECC, it's fucking stupid it's not mandatory these days. To hell with cost, the integrity of your data should be worth the added expense. It is after all a "Computer", which in the modern world is a machine, not a human.

      --
      Life is not for the lazy.
    17. Re:Rowhammer is garbage by bluefoxlucid · · Score: 1

      True. My point was that there isn't page protection for this.

      Some high-criticality stuff, such as disk buffers, use hashing and error protection in software. ECC can get a one-bit-flip correction and two-bit-flip detection per byte (or expanded per word) at 6 bits per byte (75%) overhead. Hamming coding needs an extra two bits whenever the data size doubles, at the expense of taking longer to verify (slower), which means a 4096-bit page only needs 24 bits (3 bytes) of ECC to achieve one-bit repair, and a 4096-byte page needs 30 bits. BCH generalizes this to correct more bits, at cost of more overhead; RS does it with a slow and complex finite field algorithm that calculates every polynomial derivable from a general polynomial over a finite field describing the data.

      It's possible to give up a quarter of your RAM to detect a large number of errors, although you'd probably go more like 2% and correct a handful of bit flips per page. Beyond that, just a hashing algorithm lets you eat 32 bytes and claim something rather large is probably not damaged.

      --
      Support my political activism on Patreon.
    18. Re:Rowhammer is garbage by viperidaenz · · Score: 1

      DRAM is getting more expensive these days. It's not just 1/8th more expensive, it's a lot more than 1/8th more power hungry, as you've got to power 9 bits of DRAM for every byte instead of 8, you've for the ECC checking for every read and ECC calculations for every write.
      In saying that, ECC is much more common on SoC's for their caches now than it used to be.

    19. Re:Rowhammer is garbage by Anubis+IV · · Score: 1

      If you have a private key to load, and you're allowed to do that from javascript, you can just do it directly, there is no need to play games with this. Also, is it true that these services give you some sort of enhanced access where you'd be able to do something special by using your own key from a device that had already logged in with a user account? Wouldn't the key need to be the right key anyways? And if you have my key to load into memory, why would you also need to run the code on my mobile device?

      I think something got lost in translation, because from what I can tell, very little of this relates back to anything I was talking about.

      [...] and you're allowed to do that from javascript

      I wrongly assumed that it would be clear we weren't talking about Javascript once I switched to discussing AWS and other hosted systems. What language you use actually doesn't matter, so long as you're able to run code on someone else's susceptible system with some guarantees regarding timing. Javascript can be used against everyday users via their browser, but with a shared system, you generally have much more direct control. And the sidechannel attack on a shared system wouldn't be directed at other users. Rather, you'd use a sidechannel attack against the host system to gain the host's keys, and then would use those keys to elevate your access in such a way that it would affect other users. Is that clearer?

      If you have a private key to load, [...] you can just do it directly, there is no need to play games with this.

      Again, I think there was some confusion here, though perhaps you may be thinking of private API tokens? Users wouldn't have anything analogous to the sorts of keys I'm talking about. What I'm talking about are capturing and using the host's private encryption keys (i.e. the keys used to establish encrypted communication, among other things). To get them, you might run a process that monitors memory on the host machine (via one of these sidechannel exploits) while initiating a secure connection to that same host from another machine. As the host loads its private key into memory in order to decrypt the handshake you sent from the other machine, your process on their machine would log the host's memory and hopefully capture their private key, thereby allowing you to potentially do any number of things you shouldn't be able to do. For instance, you may be able to forge app signatures and then push your own software updates to their machines, allowing you to escape your sandbox on their system. Or you may be able to act as a MITM with the full ability to decrypt traffic of other users, as well as any encrypted-at-rest data that might be on the system. And the list goes on, none of which would be possible if you simply provided a private key you already owned.

      That said, I wouldn't install an app onto a mobile device that was capable of doing something to harm me [...] get a laptop, or any other portable device that runs a full OS if you have those responsibilities!

      Whether we're talking about a laptop or a mobile device doesn't matter, so long as the conditions I mentioned earlier are met. Without proper mitigations, it would be possible for any site you visit on your laptop (or mobile device) to grab the contents of your memory as you you log into your bank in a different tab/window/browser/app, allowing that site to capture the shared encryption key and session ID you're using with that connection, thus enabling them to pose as you from another computer and empty your account. They could do that without even chaining together exploits to escalate their permissions on your system. Likewise, without proper mitigations the same could potentially be done by any app on your mobile device, regardless of how benign it might look. Or what about browser extensions that the bad guys buy from good people? It's already a common practice. You may have bee

    20. Re:Rowhammer is garbage by viperidaenz · · Score: 1

      Without kernel ASLR, they can figure out which addresses to hammer at compile time. No need for runtime checking, failing, crashing, etc.
      Kernel physical address aren't going to change much if at all on an Android device since there is usually no swap space. Not sure if ZRAM is common on Android.
      There's a function, virt_to_phys, that converts the virtual address of kernel memory into physical addresses. Handy.

      All they need to do is keep allocating memory or searching through memory their process can write to until they find an address next to one they want to change.
      They can figure the "next to" bit out by detecting which RAM chips are being used.

    21. Re:Rowhammer is garbage by sjames · · Score: 1

      Did they? Or did they give the people what they wanted in exchange for a small theoretical risk that has yet to cause a documented real-world issue? You can get ECC RAM that greatly reduces the risk if that's your preference. You can even get radiation hardened equipment that is even less likely to flip a bit if your wallet is up to it.

    22. Re:Rowhammer is garbage by Aighearach · · Score: 1

      I wrongly assumed that it would be clear we weren't talking about Javascript once I switched to discussing ...

      No need to read more than that.

      "We" aren't talking about whatever is in your head. Those are thoughts, and other people can't see them; and even if they can infer them, they generally don't want you to presume that your own thoughts rule what "we" were talking about.

      That also explains why it appears you didn't understand my words; you were reading using your own thoughts, instead of using my words.

      And you go right back into these nonsense assertions about being able to read computer memory through a web site, it is a bunch of "blah blah blah" that doesn't even convince me you know what a website is. You say things like, "Without proper mitigations" and then list things that there were mitigations to protect against back in Netscrape Navigator. If I thought you were being reasonable, I'd think you're referring only to a newer exploit, but none of the exploits that were being discussed enable the sort of things you mention. So instead I assume that "without proper mitigation" was just a weasel-caveat prefacing an intentionally false statement.

      You list a bunch of horribles, but you don't consider: What if other readers are programmers or sysadmins and actually understand all the words?! What then?! I mean, seriously, you're the guy who said that mobile banking on a phone, that might very well include side-loaded apps, is more secure than a laptop, which is much less likely to include sideloaded apps, because of fucking sandboxing?! Give me a brake, that's just stupid as fuck in a whole bunch of different ways. You really, really need to look up what the actual exploits that have been achieved with these bugs are, and if they only work in the exact setup given, or if they work in even a typical case. And if you're talking to people about it on slashdot, make sure that you know that linux users are also vulnerable, because if they're not you're gonna look stupid.

    23. Re:Rowhammer is garbage by Aighearach · · Score: 1

      Without kernel ASLR, they can figure out which addresses to hammer at compile time. No need for runtime checking, failing, crashing, etc.
      Kernel physical address aren't going to change much if at all on an Android device since there is usually no swap space. Not sure if ZRAM is common on Android.
      There's a function, virt_to_phys, that converts the virtual address of kernel memory into physical addresses. Handy.

      All they need to do is keep allocating memory or searching through memory their process can write to until they find an address next to one they want to change.
      They can figure the "next to" bit out by detecting which RAM chips are being used.

      And clown #2 is claiming that banking on Android is safer than on a laptop, because magic unicorns are farting sandboxes.

      So many readers, so few can read! They see something like, "Foo Attack Could Be Really Bad" and they hear, "Foo Attack Is Really Bad." But the words actually imply, "Foo Attack Unlikely To Be Really Bad." You should know that as soon as you see the sensationalist words next to the words that claim ignorance.

      We even have clowns that think that at compile time, maybe their compiler knows the memory location of random other stuff that isn't part of the program! Golly Gee! It is easy to see how a person could get that confused, when somebody tells them about virt_to_phys, especially if they don't (or can't) read the memory.h file in Android to find out that it is implemented as a preprocessor macro that calculates it using a volatile! So you have no idea at compile time, if that is how you're finding out; certainly the compiler doesn't think it knows the value of a volatile at compile time, so how do you get this information? I'll tell you how, you sniff the magic unicorn farts and then you'll Just Know!

      You have to have write access to the row next to the row you want to change. That means, everything that loads as part of the OS, that's all going to load next to each other, and be taken. Your app data is next to other app data; which data depends on what other apps are running, and on android that means just switching between apps can cause them to unload and reload data! It doesn't even stay in the same place for long, it certainly isn't loaded into predictable locations. Now, granted, some data in the backend processes from running apps will stay in the same place until you reboot. So there are some cases where it is at least not constantly moving, but you're still not going to know where it is. And you still can only even try it in neighboring rows. And you still don't know when you changed it successfully.

      None of that difficultly will prevent security researchers from presenting a proof of concept and getting page views, and surely programmers should mitigate it now and not wait to take the chance that a real exploit will be generated. But I'd think by now people would notice that most of the rowhammer attacks are real CVE reports, but not reasonable attack vectors. On older Windows, there was some legit exposure to privilege escalation, but that's not a very profound statement. ;)

    24. Re:Rowhammer is garbage by Anubis+IV · · Score: 1

      And you go right back into these nonsense assertions about being able to read computer memory through a web site, it is a bunch of "blah blah blah" that doesn't even convince me you know what a website is. You say things like, "Without proper mitigations" and then list things that there were mitigations to protect against back in Netscrape Navigator.

      A) Did you miss that I linked to sample code already? Yes, it was literally possible for the JavaScript on a site to read the contents of your memory by utilizing Spectre (which was mentioned by name earlier in this thread). I’m genuinely befuddled at how someone here doesn’t already understand that and, upon seeing the code I linked, immediately recognize that code as an implementation of such an exploit.

      B) No, these mitigation’s didn’t exist until recently in browsers. Why would they? Protecting system memory hasn’t been their job. Up to now, all they’ve really needed to worry about was protecting sites from each other.

      C) Yes, this is Slashdot, and I should hope that people understand the words I’m using. Likewise, the nature of these exploits have already been explained to death here so I assumed that you were already familiar with them, hence why I didn’t spell things out clearly. Sadly, it seems you’re not as familiar with them as I should hope. If you’d like me to clear up anything, I’d be happy to do so, but I suspect you’ve already made up your mind about anything I’m saying...

    25. Re:Rowhammer is garbage by Aighearach · · Score: 1

      Right, you linked some code, but you don't know what it is. You only know that the tin says something scary.

      Here, I'll quote you something since you don't know how to do your own research:

      Here is a quick list of tested browsers and their vulnerability status (always assume the latest version):

              Firefox -- not vulnerable
              Firefox ESR -- not vulnerable
              Internet Explorer 11 -- not vulnerable
              Microsoft Edge -- not vulnerable
              Pale Moon -- not vulnerable
              Waterfox -- not vulnerable
              Chromium (latest) -- not vulnerable
              Opera Stable -- not vulnerable
              Google Chrome Canary -- not vulnerable
              Google Chrome Stable -- vulnerable*
              Vivaldi Stable -- vulnerable*

      *not vulnerable if you enable strict site isolation in the web browser.

      So if they do their banking in Firefox, then Oh, Snap! you're wrong.

    26. Re:Rowhammer is garbage by Anubis+IV · · Score: 1

      Wait a sec. Let’s back up.

      Each and every time I referred to a Spectre-based attack via Javascript I very intentionally used past tense or qualified what I said to make it clear I was talking about what had been possible or what could potentially be possible with any systems that hadn’t yet been updated. I never once suggested it was still exploitable via Javascript in any current browser, nor was that something I was ever arguing about with you. My use of present tense was limited to other exploits.

      Hopefully that alone clears up a lot of our seeming disagreements.

      As for banking, you’ll recall that you brought it up as part of an assertion that certain tasks are unsuitable for smartphones. While you’re correct that the hypothetical scenario involving Javascript that I laid out to illustrate potential problems is not a concern today (not that I ever suggested otherwise, again), you conveniently failed to address any of the actual ongoing concerns I specifically raised in response to your assertion, namely hijacked extensions, a lack of scrutiny for installed apps, and an app’s ability to have essentially unfettered access to your system, all of which remain points of concern for your laptop that (likely) don’t apply to your smartphone.

      Perhaps you intended to confine your assertion to the sorts of exploits we were already discussing, but the way it was phrased that didn’t seem to be your intent. It seemed as if you were speaking in broad generalities about the relative security of laptops and smartphones.

  7. That's how I'd slip it in by SuperKendall · · Score: 5, Insightful

    Unless it's posted open source and GPL.

    If I were going to post some Malware, I'd make a clean open source/GPL version with handy pre-compiled binaries that had the actual exploits included... we all know very few people would actually go to the trouble to download and compile so you'd get quite a good uptake from people who assumed because the source was open it was safe.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:That's how I'd slip it in by Aighearach · · Score: 1

      I don't install very many apps, and I certainly don't read the source for all of them, however, I also don't grant very many permissions.

      The apps I do look at the source, they're the ones that ask for permissions but I still want to use the app. So I'll review all the parts of the code that use the permissions I'm uncomfortable giving out, to see how they use their access.

      Nobody is going do to full audit to check for everything possible, but OTOH, a few people will do a cursory analysis to see if there is obvious behavior that is undesired. So it takes a lot more to hide them than to just assume nobody is looking. Somebody is looking, and you'll need to be good to hide stuff for very long if you have any users. Double if the app is a security app, because who are the users?

  8. So is this just due to the design of modern memory by Fly+Swatter · · Score: 1

    .. memory chips? If so, then in theory anything using them is vulnerable with enough work. Would using ECC memory avoid all this over hyped crap?

  9. Re:android = malware by DontBeAMoran · · Score: 1

    Does it affect "anything that has RAM" or does it have to be a specific type of RAM?

    Ex: is the RAM inside an ATmega328P affected by this security problem?

    --
    #DeleteFacebook
  10. Re:So is this just due to the design of modern mem by amorsen · · Score: 4, Insightful

    Would using ECC memory avoid all this over hyped crap?

    Yes ECC memory and ECC cache mitigates Rowhammer. In theory not completely, you could cause an undetected triple-bit error if you ran the attack long enough. However, in that time you are vastly more likely to hit a detectable-but-uncorrectable two-bit error that halts the machine.

    (A quick Google implied that modern systems are still stuck with single-correction double-detection. I am not sure that is correct.)

    --
    Finally! A year of moderation! Ready for 2019?
  11. Re:So is this just due to the design of modern mem by bws111 · · Score: 1

    Or, even better, RAIM.

  12. Re:That seems like a very easy solution by Aighearach · · Score: 3, Funny

    There is an app you can download to test, but it's not clear what it actually does.

    If you install the app, you found the larger security hole. :)

  13. Re:"I was only following orders..." by bobby · · Score: 1

    Fail. You make assumptions, leaps of logic, and your result is failure.

    I conditionally agree that if an engineer knowingly designs/makes something faulty, they should be held accountable. But we engineers do not knowingly produce faulty stuff. All designs have to be tested to find things that nobody could anticipate. That testing costs time/money. I don't have the power to force a company to do testing- that's up to bean counters and management. Get it?

    It doesn't sound like you work in corporate America, nor have much concept of how it works. If/when an engineer has a job, they generally have to show up where and when management tells them to. You are paid to be there and do what they tell you. If you try to do a better job, point out potential flaws, etc., you're generally labeled a complainer and hindrance to PROFIT. Read "Dilbert" a bit.

    And yes, I'm speaking from direct experience, not conjecture and imagination. Being all big-shot tough-guy AC on /. isn't going to help anything. Go study the Challenger disaster. Learn about what is _actually_ happening, maybe go do some good somewhere and stop talking out of your A$$.

  14. Re:That seems like a very easy solution by Aighearach · · Score: 1

    Not only that, but if you're writing an OS you'd need a lot of code that malware in user apps would want.

    And for example on Android, they don't even have their own ABI for the compiler to target, you compile for Android just by coincidence and the compiler doesn't know Android code from bare metal code with no OS.

  15. Code would not have any issues, just binaries by SuperKendall · · Score: 2

    The apps I do look at the source, they're the ones that ask for permissions but I still want to use the app. So I'll review all the parts of the code that use the permissions

    I think you misunderstand - the code published would not contain anything harmful at all. It would be totally clean. If you actually downloaded, compiled and ran that version you'd be fine... and it would work.

    It would just be the pre-compiled binaries people could handily download without compiling, those would have the malicious code.

    The beauty of the plan is the people who actually downloaded and compiled the apps would vouch for the authenticity the app even as the versions most people used had malware.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Code would not have any issues, just binaries by Aighearach · · Score: 2

      You're right, I did misunderstand.

      Even when side-loading open source apps, I think most of the users get it from an "alternate store" type of thing, like F-Droid. So if you tried to substitute the wrong compiled binary, the hashes wouldn't match and people would know right away.

      You'd not only have to get people to install it directly, you'd have to somehow keep the F-Droid people from listing it, or else people would notice the different hashes. (some small percent of users will notice even a changed UPC code on packaging, and send emails in asking if the product is the same product or a different version!) So it needs to be open source, but have very few users and very little interest. It seems the attack vector is self-limiting, but I don't doubt that it does happen when narrowed that far.

      The big hole in your idea is thinking that the sort of people that would compile the app themselves, when asked about potential problems, would just vouch for it without even talking about versions and hashes. That seems an unlikely combination of advanced and beginner behavior.

  16. Re:Just one more... by Aighearach · · Score: 1

    Maybe you should reconsider your purchasing habits? Maybe even do a web search for device reviews of older devices from the same company before purchasing.

  17. Re:So is this just due to the design of modern mem by DigiShaman · · Score: 1

    So again, data corrupted. Rowhammer seems counter productive at gaining access to data. If anything, it's just a nifty exploit to corrupt data and/or kernel panic the OS running on it. Essentially, sabotage.

    --
    Life is not for the lazy.
  18. Re:That seems like a very easy solution by viperidaenz · · Score: 1

    What does GPL have to do with it?

  19. Re:So is this just due to the design of modern mem by grep+-v+'.*'+* · · Score: 1

    modern systems are still stuck with single-correction double-detection. I am not sure that is correct.

    I am not sure either -- but decades ago it took 5 extra bits to guard 16 bits. As I understood it, the ECC was kept there, and on failure it morphed and used 4 bits to point to the incorrect bit and 1 bit to indicate action needed (ie, failure.)

    This was only 1 vendor from decades ago, but that's what I remember the technical manual saying (back when they described things.) So I assume from that that it takes more bits to correct more bits; that they haven't improved the math behind the detection algorithm.

    You can kinda notice the same thing in RAID5 and ZFS. You can add extra drives for more redundancy, but a single drive can't handle 2 unit failures -- I think the math requires more bits sacrificed to the Data Gods for better coverage, and there's nothing extra the bottom level can do with the bits it can use. (I know! Let's throw away all of those fat 0s and only keep the slim 1s -- that'll easily give us twice the space!)

    --
    If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
  20. Re:So is this just due to the design of modern mem by amorsen · · Score: 1

    You can't really improve the algorithm, you can only switch which patterns you correct, which you detect, and which you fail on. Provably optimal algorithms have been known basically since anyone cared.

    However, modern memory is 64 bit, not 16 bit. That gives you 20 bit of ECC to play with, and it ought to be possible to do much better with that.

    --
    Finally! A year of moderation! Ready for 2019?
  21. Just DRAM by evanh · · Score: 1

    The article should be making the distinction.

    It's only a DRAM problem because of DRAM's requirement for refreshing. Other RAM types don't have the constant discharge curve so won't be susceptible.

    SRAM is the fastest. Buffers and caches are built of SRAM. MRAM is waiting in the wings to replace all DRAM and possibly some bulk SRAM in the larger caches too.

    I'm guessing improved DRAM refresh logic can fix the issue though.

  22. DRAM only problem by evanh · · Score: 1

    The AVR's are SRAM based. Bulk DRAM inside any uController is almost unheard of. https://it.slashdot.org/commen...