So fundamentally, due to mitigatable-but-impossible-to-fully-patch hardware exploits like Rowhammer and Spectre, client-based sandboxing cannot be relied upon.
Seems that a good approach for the average HN user is to disable Javascript for all sites, but whitelisting trusted sources (of course with HTTP MITM over compromised routers, never execute any code with questionable integrity, so anything delivered over a non-TLS connection)
Goes without saying one should only use the minimal possible amount of native applications too: ideally none except perhaps the smartphone OS-vendor's trusted applications (your OS-vendor can already arbitrarily execute code and read memory). Using the OS-vendor's web browser with Javascript disabled shouldn't be too much of a security risk.
Even seemingly trusted web sites are often pulling in JavaScript libraries from third party CDNs, analytics services, and advertising networks. It's almost impossible to be certain that none of those are compromised.
Decentraleyes[0] is a great plugin that intercepts many popular 3rd party CDN requests and replaces them with local copies. It's not a silver bullet, but it reduces CDN-based tracking and the chance of the attack described in the parent comment.
Subresource integrity[1] is a technology that's been available for a while that also mitigates this attack, if used properly by website owners.
True, but at least the attack surface area will have been reduced by a large amount which is worth something.
Disabling Javascript served over HTTP is such a good security improvement that I'm surprised no browser vendor has implemented yet, in the age of Let's Encrypt. It'll break a lot of websites, but better than compromised routers and ISPs serving JS malware.
JS broke the presentation vs data abstraction. It's an obfuscation layer used to make it harder to use data the way you want. It's also a linkrot catalyst. To scrape many sites you must exec an arb program, that may never halt, and save the state. For the majority of cases it's unnecessary. I cant render text on many sites unless I linearlize or execute the JS. Minor additions to HTML could remove the majority of reasons to use JS. It's entirely possible to make a maps site that still works right now. It's also a side channel that makes it near impossible for browsers to fingerprint the same.
I don't know what the solution is other than users understanding the problem.
I will be joining a long line of people with "I told you..." said in address of dotcom browser devs shoveling OpenGL with effectively raw GPU memory access into browsers.
That is a line that historically had no one in it. There was much wringing of hands over WebGL, but "access to raw GPU memory" never came up as a concern, and is not even the issue here!
This exploit specifically only functions on UMA devices, where GPUs use unified system memory, and thus have no more or less access to it than ArrayBuffers. It turns out CPU memory accesses are too slow (really simplifying here) to rowhammer.
Yeah, it's a valid position to want to limit the web platform's capabilities so that implementations are simpler and have fewer places where bugs can happen. The other position is that walled garden platforms (like Apple/Google app stores) could then make the web irrelevant as an app platform.
It would be nice if there were 2 "profiles" that web pages could conform to, browsers would only enable "simple content" profile by default...
No need to "doubt". Just try Rowhammer via GLitch on a test iOS device. It will either work, or it will not. We need more people trying this out, informing vendors, and reporting their results in a REPLICABLE fashion.
This makes me _more_ certain iOS will end up being _more_ vulnerable to this type of attack.
It's almost certainly quite hardware specific, and if you were weaponising this there's way more homogeneous hardware on iOS than Android. Get this working on iPhone 7/8/X and you've probably got 75% of the "high value" iOS device fleet covered.
They are probably immune to this specific implementation simply because the relevant bits are in different locations - but not to the attack in general.
Although not evidence either way - were apple to include mitigation for row hammer its most likely they would advertise it as they do their other security infrastructure. Its about on-par with the encryption processor in the imac pro in terms of technicality and that is public information.
They did increase their DRAM refresh rate and mentioned it in release notes. There is not much more you can do easily - and it comes at a real cost in power usage.
You can actually refresh specific rows adjacent to frequently accessed ones by issuing ACT->Precharge command combos. Timed right it only comes into play during attacks (whether intentional or by coincidence) and therefore has little additional power usage.
Also that release note was for the Mac not the iPhone. They are less likely to apply that mitigation to the iPhone precisely because it would result in increased power consumption. They could however integrate the more advanced fix in the memory controller since they control the SoC. I would expect them to brag about it if they had.
Problem is the battery and storage degradation is very real. While a simple factory reset solves some of the storage fragmentation, you'll never get the original owner's same experience with the device (unless you won the used device lottery and received a barely used handset).
But something like an iPhone 6 definitely is a competitor against a brand new $200 Android device (and may receive security updates for longer).
Out of curiosity, when have you last used a 200$ Android phone?
The options available nowadays are pretty good with updates (from Android One initiative) and hardware similar to (in a few cases, significantly better than) last gen flagships.
I just bought a few for testing at work. There's the HTC EVO 10 for $185[1], the Huawei Honor 6X for $200[2], and the Motoroloa Moto E4 Plus for $130(!)[3]. I also got a Samsung S6 to test, but at $250 for a much older phone, I wouldn't recommend it (but it is a fine phone, it's what I've been using personally for a few years).
I just set them up today, but I have to say, the $130 price point of the Moto E4 is pretty enticing given it seems responsive and has a fairly large screen (and if you are fine with Verizon, you can get it for $70 no contract[4]). The H6 seems like the one aimed the most to be a flagship phone. Fairly polished, and with a rear fingerprint sensor (all or almost all the rest have a fingerprint sensor, it's just on the front).
Edit: Whoops, the Verizon link and price is for the Moto E4, while what I purchased was a Moto E4 Plus, which Verizon has for $110[5]).
This makes some sense. A few months back Apple was found to be limiting the performance of iPhones with degraded batteries. A fresh battery wouldn't have that issue.
Any Android One device is probably worth a look. Maybe used iPhones too - though given Apple's slowdown with old batteries and attitude towards right to repair I'd be quite hesitant to seriously suggest that these days.
Google may be marginally better at updating their own devices, but they regularly suggest Play Protect as how to stay safe from malware, a piece of software that ranks dead last (literally zero stars) for detection rate on AV-TEST[1]. It's the sort of "here's a green check mark, just trust us" security approach that has carried McAfee for decades.
I was hoping we'd hear some changes with the new security lead at Android, but so far its been more of the same.
How to stay safe from Android malware: buy a phone with regular security updates. Don't install random APK's from Russian boards. Simple.
Android AV is useless bloat. It runs in its own sandbox just like every other app. Play Protect is the only one with privileges to actually do something.
I'm a sucker who bought from nexus one to moto x dev edition (during google ownership of motorola), and all in between... all promised continuous android updates. all had a SINGLE major version update, just like any other flagship phone. don't buy google marketing.
btw, im running recent versions via community roms on all of them, even the nexus one! so not hardware limitation, but the same greed and planed obsolescence at play on other companies makes google abandon phones just the same.
Ok, I was going to let this go as a difference of opinion, but now you've called me a liar. I've owned the following Android phones:
1. Nexus One
2. LG G2x
3. Samsung Galaxy S2
4. Samsung Galaxy S4
5. Motorola Moto X
6. Moto G2
7. Nexus 5x
8. Pixel (1st gen, non XL)
Of those, the best android phone I've ever had was the Nexus One. Amazing phone. I would LOVE a new version of that, same form factor (you can kill the ball), please make another dock, but modern innards and screen. It had THREE major versions of Android, it debuted with Eclair, saw Froyo, and then Gingerbread. 3 major versions.
The LG G2x was trash, so bad they lost a class action suit on the faulty hardware. I swore never another LG phone. I have no idea what OS updates it got, it was horrible.
The Galaxy S2 and 4 were ok, better with CyanogenMod. The S2 saw Gingerbread, ICS, and Jellybean from Samsung, an impressive array. The S4 got Jellybean, Kitkat, and Lollipop. Both got 3 major versions.
The Moto X was a close #2 to the Nexus One. Incredible phone that they screwed up with the X2. It saw Jelly Bean, Lollipop, and Kitkat. The G2 was great for a budget phone, saw Kitkat, Lollipop, and Marshmallow. 3 major versions.
My 5x was beautiful, but a bit disappointing at times. Again, LG, I thought the Nexus name would make it better, it was, but not by much. LG has a talent for making self destructing phones. It had Marshmallow, Nougat, and Oreo. 3 major versions.
My Pixel came with Nougat, and now has Oreo. 2 major versions.
All of these phones had 3 major OS updates, aside from the G2x and the Pixel, and the Pixel hasn't seen a third because it's on the latest Android available right now.
Looking at Wikipedia, only the Galaxy Nexus got two letter-revisions, but that takes it from 4.0 to 4.3, with Jelly Bean being 4.1, 4.2, and 4.3 (as well as 4.x.y releases), seeing THREE 6 month release cycles in July 2012, November 2012, and July 2013.
Every single Google Nexus phone has had years of new releases, with at least three major versions for every single Nexus phone, and the Pixels will see at least three major revisions as they've releaed the dev preview of Android P on the 1st gen Pixels.
Nexus and Pixels get the new releases first, very quickly, with monthly updates over the past several years. So, in summary, please do not call me a liar.
It is interesting to note that DDR and DDR2 are more immune to this kind of attack. Older computers with decently patches OS/browser would be safer to use for those who want to avoid Row hammer.
Well webgl, canvas and audio functionality of javacript are anyway nice to be disabled due to browser fingerprinting, now there is just another good case to disable webgl. But this is getting crazy, I think that todays CPUs, need a serious step back and rethinking.
Seems that a good approach for the average HN user is to disable Javascript for all sites, but whitelisting trusted sources (of course with HTTP MITM over compromised routers, never execute any code with questionable integrity, so anything delivered over a non-TLS connection)
Goes without saying one should only use the minimal possible amount of native applications too: ideally none except perhaps the smartphone OS-vendor's trusted applications (your OS-vendor can already arbitrarily execute code and read memory). Using the OS-vendor's web browser with Javascript disabled shouldn't be too much of a security risk.