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

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.

Comments

That seems like a very easy solution

[Anonymous Coward]

That any compiler could figure out, and the processor specs as to "when and how" that would happen would be given to the compiler.

In other news, a bigger fire is hotter than a smaller fire.

Re:That seems like a very easy solution

[AmiMoJo]

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.

Re:That seems like a very easy solution

[SuperKendall]

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?

Re:That seems like a very easy solution

[olsmeister]

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.

Re:That seems like a very easy solution

[YuppieScum]

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

Re:That seems like a very easy solution

[Anonymous Coward]

Unless it's posted open source and GPL.

Re:That seems like a very easy solution

[Anonymous Coward]

Your "any compiler could figure out" solution is totally fucking irrelevant to fixing or circumventing the bug.
This is like expecting unencrypted data on an stolen external drive to be safe because the thief doesn't know your laptop's password.
Attackers aren't going to use the front door or whatever hobbled tools you give them.

Re: That seems like a very easy solution

[Anonymous Coward]

Could someone translate this to to English please? Not Layman, just English.

Re:That seems like a very easy solution

[Anonymous Coward]

Android devices are just poorly designed in general to be cheap, not secure.

Re:That seems like a very easy solution

[Aighearach]

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. :)

Re:That seems like a very easy solution

[Anonymous Coward]

Yup. Every Android device...

Despite there being Exynos, Snapdragon, MediaTek, HiSense, Nvidia, and even something called "allwinner"

Re:That seems like a very easy solution

[Aighearach]

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.

Re:That seems like a very easy solution

[Anonymous Coward]

Just like your mom.

Re: That seems like a very easy solution

[Anonymous Coward]

*Everything

Re:That seems like a very easy solution

[viperidaenz]

What does GPL have to do with it?

Is iOS affected too...

[SuperKendall]

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...

Re:Is iOS affected too...

[Tough Love]

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?

Re:Is iOS affected too...

[Tough Love]

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.

Rowhammer is garbage

[ComputerGeek01]

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

Re:Rowhammer is garbage

[geschbacher79]

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.

Re: Rowhammer is garbage

[Anonymous Coward]

They want people to run their test code, to see if it's a real problem or whether the problem is academic nonsense being repeated on slashdot.

I wouldn't run their app if you paid me.

Re:Rowhammer is garbage

[xanthos]

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.

Re:Rowhammer is garbage

[bluefoxlucid]

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.

Re:Rowhammer is garbage

[iggymanz]

it's garbage hardware design, yes.

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

Re:Rowhammer is garbage

[Anonymous Coward]

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.

Re:Rowhammer is garbage

[Anonymous Coward]

  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.

I think you're going a bit far. In the vast, vast majority of cases you're right. This is going to be extremely difficult to exploit, and likely impossible. But I'm not sure you need to know EXACTLY the cells you're modifying. You just need to get lucky, and it needs to be a situation of very limited scope where flipping random bits (which should happen a lot) isn't really a big deal. I can't really think of any situations where that applies, but it doesn't mean they don't exist.

It's a legitimate exploit, and it should be fixed in some way (parity memory for instance). But I agree it's something that should be mostly ignored.

Re:Rowhammer is garbage

[Anonymous Coward]

Unless your objective is to crash the device, rowhammer is a useless technique...

If you're still wondering in the 21st Century as to whether or not Denial of Service attacks are "useless", perhaps you should talk to a victim or two...

Re:Rowhammer is garbage

[bobby]

it's garbage hardware design, yes.

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

FTFY.

Re:Rowhammer is garbage

[onepoint]

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.

Re:Rowhammer is garbage

[Anubis IV]

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.

Re:Rowhammer is garbage

[Dwedit]

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

Re: Rowhammer is garbage

[Anonymous Coward]

And just like using dynamite on a card lock, you get access but it won't be silent. You leave damage behind and chances are you just destroy whatever you set out to steal.

Re:Rowhammer is garbage

[Anonymous Coward]

This is orthogonal to what @ComputerGeek01 was pointing out, which was the fact that even though Rowhammer might allow one to write to address 0xC0004000 with electrical field magic, the attacker is unable to know which process address 0xC0004000 belongs to, because of memory page protection. OTOH, if one write exploit code to random memory addresses often enough, I suppose they will get executed eventually. Maybe 1/100 chance? I'm no security or OS expert, anybody have a better estimate on that?

Re:Rowhammer is garbage

[Anonymous Coward]

Why use rowhammer when OS's provide
readprocessmemory

and any process can do this to any other process.

Re:Rowhammer is garbage

[iggymanz]

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.

Re:Rowhammer is garbage

[Aighearach]

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.

Re:Rowhammer is garbage

[DamnOregonian]

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.

Re:Rowhammer is garbage

[Tough Love]

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?

Re:Rowhammer is garbage

[Aighearach]

...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!

Re:Rowhammer is garbage

[lexman098]

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?

Re:Rowhammer is garbage

[DigiShaman]

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.

Re:Rowhammer is garbage

[bluefoxlucid]

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.

Re:Rowhammer is garbage

[viperidaenz]

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.

Re:Rowhammer is garbage

[Anubis IV]

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

Re:Rowhammer is garbage

[viperidaenz]

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.

Re:Rowhammer is garbage

[sjames]

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.

Re:Rowhammer is garbage

[Aighearach]

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.

Re:Rowhammer is garbage

[Aighearach]

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. ;)

Re:Rowhammer is garbage

[Anubis IV]

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...

Re:Rowhammer is garbage

[Aighearach]

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.

Re:Rowhammer is garbage

[Anubis IV]

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.

Re: android = malware

[Anonymous Coward]

Yes combined with web assembly and Google's advertising network the devices are working (worming?) as intended.

ALL Androids, eh?

[Anonymous Coward]

Every time I see one of these 'Every Android device is vulnerable!' things, I go 'Wanna bet?' and throw the test app on my Blackberry Priv.

The Priv hasn't been vulnerable to any of 'em yet.

Which makes me suspect most of these things don't work on the various 'security focused' Android builds. I don't have a Samsung Knox or the like to test, however.

Re: android = malware

[Anonymous Coward]

I feel you but what mobile OS isnâ(TM)t.

Can we have some grammar?

[Anonymous Coward]

when someone would send repeated write/read requests to the same row of memory cells,

Ouch!

That's how I'd slip it in

[SuperKendall]

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.

Re: That's how I'd slip it in

[Anonymous Coward]

Few people would bother with compiling - but only one is needed. Typically someone in the computer security business.

Also, hobbyist who want to add his own improvements to the app.

Re:That's how I'd slip it in

[Aighearach]

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?

Perhaps not, but your Blackberry definitely is.

[Anonymous Coward]

Snapdragon 808 in the Priv is vuln. Nothing you can do in the OS or with virtualization makes it cease being vulnerable. In addition the hypervisor used on the 808 by all OEMs, including Blackberry, is known to be open to an ARM variant of BluePill and virtualization rootkits are possible on the device.

So is this just due to the design of modern memory

[Fly Swatter]

.. 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?

Re:android = malware

[Anonymous Coward]

How about RTFA -
The researcher team also believes RAMpage may also affect Apple devices, home computers, or even cloud servers.

Dope.

Re:android = malware

[DontBeAMoran]

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?

Re:So is this just due to the design of modern mem

[amorsen]

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.)

Re:So is this just due to the design of modern mem

[bws111]

Or, even better, RAIM.

Just one more...

[Anonymous Coward]

> Every Android Device Launched Since 2012 Impacted By RAMpage Vulnerability

Since none of my Android devices have *ever* gotten a *single* OS update, I think it's fair to say that they're actually vulnerable to, well, *everything* that's ever been found out, with no fix in sight.

"Buy new hardware to get up to date" -- fuck you, I'm done playing that game.

Re:Just one more...

[Anonymous Coward]

Maybe you shouldn't be buying $150 Android phones if you care about this kind of thing?

Every single Android device I have, has at least 3-5 MINIMUM, if not more updates.

Re:Just one more...

[Aighearach]

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.

General rule of computing;

[Anonymous Coward]

If its source isn't open, it is bullshit.
And likely criminal.

"I was only following orders..."

[Anonymous Coward]

That excuse didn't work at the Nürnberg trials, and it doesn't work for you.

I don't care what excuses you come up with; you worked for them; you have to deal with what that entails.
Whether it is because Adolf Hiter personally commands you to build ovens and gas chambers for people, or you design a memory chip that you know will leak information because a tied psycho suit is commanding you to.

Re:"I was only following orders..."

[bobby]

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$$.

Re:"I was only following orders..."

[Anonymous Coward]

Even with full management support for testing, it is difficult to anticipate and expose bugs that require narrow voltage, temperature, timing, and data contents before expressing themselves. Imagine brute forcing an encryption key that potentially has the entire length of your memory as it's bit-width. It is only with extreme insight, prior experience, luck, and the grace of God that the most obscure bugs are detected prior to general availability.

And even if you had a perfectly bug-free piece of silicon, I guarantee you can still get it to misbehave by abusing the voltage, temperature, and clock timings outside of the manufacturer specified limits.

No scrambler?

[Anonymous Coward]

I thought rowhammer issues were more or less resolved years ago. Do smartphone memory controllers sold today not have memory scramblers?

Code would not have any issues, just binaries

[SuperKendall]

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.

Re:Code would not have any issues, just binaries

[Aighearach]

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.

Re:So is this just due to the design of modern mem

[DigiShaman]

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.

Re:So is this just due to the design of modern mem

[grep -v '.*' *]

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!)

Re:So is this just due to the design of modern mem

[amorsen]

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.

Re:So is this just due to the design of modern mem

[Anonymous Coward]

An attacker could potentially target a specific program's memory if they can figure out where to hit it with the rowhammer (which is at least theoretically possible with a spectre or meltdown-like attack). Being able to crash or corrupt the memory of a specific program sounds like the kind of thing that could lead to other exploits.

Just DRAM

[evanh]

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.

DRAM only problem

[evanh]

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