Every Android Device Launched Since 2012 Impacted By RAMpage Vulnerability (bleepingcomputer.com) 83
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.
Re: (Score:3)
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 (Score:5, 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?
That's how I'd slip it in (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.
Re: (Score:2)
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 o
Code would not have any issues, just binaries (Score:3)
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 co
Re: (Score:3)
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 co
Re: (Score:2)
What does GPL have to do with it?
Re:That seems like a very easy solution (Score:4, 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. :)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
Is iOS affected too... (Score:5, 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 [scmagazineuk.com], I wonder if it is?
It would be nice if the article (and researchers) were more clear about other platforms being vulnerable...
Re: (Score:1)
this is a kind of Rowhammer attack, which Apple mitigated in 2015 [scmagazineuk.com]
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: (Score:2)
this is a kind of Rowhammer attack, which Apple mitigated in 2015 [scmagazineuk.com]
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 (Score:4, 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
Re: (Score:2)
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". Un
Re: (Score:3)
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 [react-etc.net] 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, in
Re: (Score:2)
...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?
Re: (Score:2)
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 sha
Re: (Score:2)
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 sit
Re: (Score:2)
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 th
Re: (Score:2)
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: (Score:2)
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 explo
Re: (Score:3)
Re:Rowhammer is garbage (Score:5, 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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
it's garbage hardware design, yes.
electrical engineers have failed in their design of memory and CPU.
Re: (Score:1)
it's garbage hardware design, yes.
electrical engineers' managers have failed in their managment of design of memory and CPU.
FTFY.
Re: (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 Ameri
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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 (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 [blackhat.com] 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: (Score:2)
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 fo
Re: (Score:2)
People have working root exploits that use Rowhammer, so it's not useless.
Re: (Score:2)
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: (Score:2)
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
Re: (Score:2)
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 th
Re: (Score:2)
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
Re: (Score:2)
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: (Score:2)
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?
DRAM only problem (Score:2)
The AVR's are SRAM based. Bulk DRAM inside any uController is almost unheard of. https://it.slashdot.org/commen... [slashdot.org]
So is this just due to the design of modern memory (Score:2)
Re:So is this just due to the design of modern mem (Score:5, 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.)
Re: (Score:2)
Or, even better, RAIM.
Re: (Score:2)
Re: (Score:2)
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 algorit
Re: (Score:2)
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.
Just DRAM (Score:2)
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.
Re: (Score:2)
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.