Will Pyra memory be susceptible to Rowhammer?


oxym

Member
Joined
Mar 20, 2014
Messages
43
Some time ago there have emerged a new class of attacks, targetting hardware limitations. One of such attacks is aimed at memory controller.
You can read more about rowhammer here: https://en.wikipedia.org/wiki/Row_hammer
Recently there was devised a new attack targetted at mobile devices called: Drammer (https://www.vusec.net/projects/drammer)

Will Pyra be prepared for this kind of attack?
It would be sad if newly released device would be susceptible to a known vulnerability.
 
Well, the DRAMs and processor we use are a little older. So they are already well-hung and nobody has reported an issue so far.
On the other hand we can't do anything actively about that (we can't change the memory controller or DRAM chips).

Except one thing: adjust the refresh rate if necessary.

If it is necessary can only be said if someone runs extensive tests and finds some vulnerability. If not it would be almost
wasted time...
 
They say Google has issued some fixes, so it sounds as if there are software mitigations possible ? It looks like a hardware bug in essence so I don't know how much a software fix can help, but probably it is such a corner case that the OS can do something to avoid the weird memory accesses from completing. Quoting more knowleadgeable stuff from that Drammer page:

Due to the nature of our attack – exploiting a hardware vulnerability – implementing such comprehensive patch is not easy. It is because of this that Google first decided to disable the ION kmalloc heap. This makes it impossible for user space applications to request guaranteed contiguous physical memory through ION. However, an attacker can still exhaust the regular system heap. He can then rely on the predictable behavior of the buddy allocator to get contiguous pages anyway. In addition, the system heap allocator allocates memory from a different pool (highmem), normally separated from that used to allocate page tables and other kernel data structures (lowmem). However, an attacker can allocate many ION chunks to deplete the highmem pool and force the buddy allocator to serve new requests from lowmem. We hope that Google soon applies more fundamental changes to the Android Linux Kernel that allows for ION memory accounting. This way, Android could limit ION allocations on a per-uid base, thwarting Drammer much more. In addition, /proc filesystem entries such as /proc/pagetypeinfo that leak the state of the buddy allocator (e.g., highmem chunks available, chunks of a given size available, etc.) should be made accessible only by root.
 
We could work to harden the kernel, but the software runs everything as root anyway :)

That white paper is freaking amazing tho.
 
If someone creates exploits especially for the Pyra we would have past a new mile-stone: even hackers think the device is worth writing code for.
Hopefully they buy lots of Pyra's and make them safer.
 
  • Like
Reactions: ___
I'd be surprised if someone goes through all the trouble. Stealing a portable device would be a way more efficient way to achieve access to the data. Then again, just laughing it off saying "I can't imagine someone would try" is certainly not a satisfying answer.

How would someone achieve a breach utilizing this exploit on the pyra?

- They'd have to smuggle malicious code into either the debian repositories.
as far as I can gather, this would have to happen upstream and pass through several layers of code review, though in an open source cosmos, there is always some bug or other that might slip through anyway. good example is the recent openssl drama and that's been going on unnoticed for years.
- They'd have to do the same on a smaller scale as a binary package release where we can download dbp format packages from. This is - as I'd imagine - the attack vector to be more concerned about. there is basically no level of code review, as maintainers are mostly trusted based on their forum status. if they were to package a malicious binary, all they'd need to do was offer it as a regular game download and the only way to find out was if someone becomes a victim first and actually identify the attack. and they need to pin point which executable was responsible.
- Webscript based attack somehow executing malicious code to run the low level exploit. well... there is probably a dozen more js exploits to achieve the same quicker and with better results.

that's the three scenarios I can think of as a layman, but that doesn't mean there isn't any more. I think it's highly unlikely that someone would go through so much trouble though. there is obviously always a chance, that someone smuggles in malicious code and a billion more exploits that could be utilized... root kits, whatever. someone had already released a binary on the pandora pnd "market" that collected user data and someone else called them out for it on these boards, though that was without malicious intent. still immoral and it took some time until somebody noticed.
 
I'm in no way an expert in Linux/Debian, but everything I've downloaded for debian has had to be compiled from the source (with small exceptions like Chrome, Milkytracker). And wouldn't it be pretty difficult to sneak in malicious code in the repositories anyway?
 
Last edited:
Well, everything (including chrome and milkytracker) have to be compiled from some source, but there's no intrinsic proof that the source you can find is the same that was used to build the package. There was a debian project to ensure that binary equivalent files could be generated from public sources for all packages, which I heard about a year or two back, but to me there felt like a good couple of years work to get to 95%, and my googlefu is not sufficient to find that project today and find out for sure where they got to. But that would fix the gap that exists, and mean the only remaining problem is getting enough interested eyes on the source code to make sure it's not doing anything malicious either accidentally or on purpose (but the fallout from Heartbleed and other bugs has improved that too, at least temporarily).
 
Well, everything (including chrome and milkytracker) have to be compiled from some source, but there's no intrinsic proof that the source you can find is the same that was used to build the package. There was a debian project to ensure that binary equivalent files could be generated from public sources for all packages, which I heard about a year or two back, but to me there felt like a good couple of years work to get to 95%, and my googlefu is not sufficient to find that project today and find out for sure where they got to. But that would fix the gap that exists, and mean the only remaining problem is getting enough interested eyes on the source code to make sure it's not doing anything malicious either accidentally or on purpose (but the fallout from Heartbleed and other bugs has improved that too, at least temporarily).
Yeah pretty much, the pre-compiled downloads are more likely to be malicious than the downloads you have to compile the code yourself.
Because if you have the source code you can basically find the malicious code and if anyone found out about it, the creators of the program would get in deep s*** quick.
But if they only put malicious code in the pre-compiled downloads only, but not in the actual source code release. It would be harder for people to discover. That's the only thing that would worry me about these exploits.

I prefer to compile everything myself anyway, HOPEFULLY I don't run into any trouble haha.
 
How would someone achieve a breach utilizing this exploit on the pyra?

- They'd have to smuggle malicious code into either the debian repositories.
Not necessarily. There is a similar discussion going on in the Maemo forums and it was pointed out, that there are rowhammer implementations in Javascript. [1] So all you need to be vulnerable is to run an almost random web browser.

edit:
- Webscript based attack somehow executing malicious code to run the low level exploit. well... there is probably a dozen more js exploits to achieve the same quicker and with better results.
Sorry! I didn't read that thoroughly enough.
/edit

I'm in no way an expert in Linux/Debian, but everything I've downloaded for debian has had to be compiled from the source (with small exceptions like Chrome, Milkytracker). And wouldn't it be pretty difficult to sneak in malicious code in the repositories anyway?
Again, not necessarily. I see three ways of "sneaking in" code into the Debian repos:
A: Put it in some package in non-free or in the content of something that is loaded by a package in contrib. This way you can totally avoid Debian's quality assurance. Granted, this is less likely on an arm platform if most of the closed source stuff will be x86.
B: Put it in one of the meta data scripts (config/preinst, config/postinst). These scripts can basically do anything. They are open source but I have a feeling there might not be as many eyes on them as on the actual payload data.
C: Hide it in plain sight. Some months ago there was a bug in Debian concerning xscreensaver, that revolved around the upstream author putting a warning popup into his software triggered at a specific date, that advised the end-user to upgrade xscreensaver from upstream because he felt that a distribution that did not follow upstream closely would do its users a disservice. [2] The issue itself was harmless, but it showed that putting "time bombs" in Debian packages and getting them all the way through unstable and testing into stable is totally possible.

bottom line:
Don't trust that Debian will be safe! It might be one of the safest distributions out there, but there will never be absolute certainty (obviously).


[1] http://talk.maemo.org/showthread.php?t=91142&page=283#2829
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703
 
Last edited by a moderator:
If someone creates exploits especially for the Pyra we would have past a new mile-stone: even hackers think the device is worth writing code for.
Hopefully they buy lots of Pyra's and make them safer.

I don't know how likely it is that someone creates specific exploits for the Pyra, but I believe (I'm no expert) that exploits start as more specialized and are generalized and gathered in toolkits so that
they become easier to use against more targets.

And nowadays everyone is a target. There are some states, and quite likely some criminal organisations that go to big expenses to own huge amount of computers, they don't bother to look
the case color of the devices they break into (that's how you know they're the bad guys, civillized people would set up huge forum threads on which color devices they should prefer for their
attacks and only break into them once they reached consensus if ever :p).

Some state armies have like tens of thousands of people with full dedication to breaking everything. They may find something that also works for the Pyra, on purpose or as a byproduct.
The drammer site says it is not very especific of a single device. Just as they did it for Android, they could do it for GNU/linux, maybe.

I'd be surprised if someone goes through all the trouble. Stealing a portable device would be a way more efficient way to achieve access to the data. Then again, just laughing it off saying "I can't imagine someone would try" is certainly not a satisfying answer.

A remote attack sounds easier and more useful, because you can keeping on stealing data or basing your further attacks from that target, or whatever. Sending someone to go steal a device seems like a last recourse when all else fails.

How would someone achieve a breach utilizing this exploit on the pyra?

- They'd have to smuggle malicious code into either the debian repositories.
as far as I can gather, this would have to happen upstream and pass through several layers of code review, though in an open source cosmos, there is always some bug or other that might slip through anyway. good example is the recent openssl drama and that's been going on unnoticed for years.

Yes, it's the best we have, but bugs will always slip through. Go read DSA and you'll see them.

- They'd have to do the same on a smaller scale as a binary package release where we can download dbp format packages from. This is - as I'd imagine - the attack vector to be more concerned about. there is basically no level of code review, as maintainers are mostly trusted based on their forum status. if they were to package a malicious binary, all they'd need to do was offer it as a regular game download and the only way to find out was if someone becomes a victim first and actually identify the attack. and they need to pin point which executable was responsible.

Debian packages have crypto signatures to avoid tampering. Dbp packages could include them if they don't have them already ?
This does not stop rogue maintainers, but does stop attacks between good maintainers and the users (faking or phising the download site, or so on).

- Webscript based attack somehow executing malicious code to run the low level exploit. well... there is probably a dozen more js exploits to achieve the same quicker and with better results.

Yes webscript or any other remote attack (there are more protocols than HTTP, maybe DNS or SIP or whatever).

that's the three scenarios I can think of as a layman, but that doesn't mean there isn't any more. I think it's highly unlikely that someone would go through so much trouble though. there is obviously always a chance, that someone smuggles in malicious code and a billion more exploits that could be utilized... root kits, whatever. someone had already released a binary on the pandora pnd "market" that collected user data and someone else called them out for it on these boards, though that was without malicious intent. still immoral and it took some time until somebody noticed.

It depends on how much trouble it is and how much it is worth to the attacker. IF a device was very secure it could attrack "interesting" users for targeted attacks, and if it isn't so secure, it can suffer broad attacks.
I don't like to think in those terms. I like to think on what can I do to protect me as much as possible within my budget. Risk sceneraios are more general (like remote attack vs physiscla access, DoS or informaiton leak).
Not so much "will they come after me or the kind of device I use?"

I'm in no way an expert in Linux/Debian, but everything I've downloaded for debian has had to be compiled from the source (with small exceptions like Chrome, Milkytracker). And wouldn't it be pretty difficult to sneak in malicious code in the repositories anyway?

Well, My experience is the opposite I compile some programs, but the vast majority of the software are downloaded debian packages. I haven't downloaded them with a browser, but with apt-get or aptitude or the like,
but they are still downloaded binaries. I guess you mean to compare it with non easily verifiable binaries downloaded from not too trusted sites which are common in other systems ? Yes, I avoid those, and there's not
much need in debian.

Well, everything (including chrome and milkytracker) have to be compiled from some source, but there's no intrinsic proof that the source you can find is the same that was used to build the package. There was a debian project to ensure that binary equivalent files could be generated from public sources for all packages, which I heard about a year or two back, but to me there felt like a good couple of years work to get to 95%, and my googlefu is not sufficient to find that project today and find out for sure where they got to. But that would fix the gap that exists, and mean the only remaining problem is getting enough interested eyes on the source code to make sure it's not doing anything malicious either accidentally or on purpose (but the fallout from Heartbleed and other bugs has improved that too, at least temporarily).

You mean reproducible builds ?

Not necessarily. There is a similar discussion going on in the Maemo forums and it was pointed out, that there are rowhammer implementations in Javascript. [1] So all you need to be vulnerable is to run an almost random web browser.

Yes, there was an Ars Technica article on that. Is was April, and it didn't look very general yet, but it might have evolved, I don't know.
Rowhammer.js and Drammer look like they could eventually be joined. And in fact the Drammer artiicle talks of breaking into an Android
phone in the audience without much problem, so it must already be somehow done with some other remote vulnerability.

A: Put it in some package in non-free or in the content of something that is loaded by a package in contrib. This way you can totally avoid Debian's quality assurance. Granted, this is less likely on an arm platform if most of the closed source stuff will be x86.
There are lots of ARM binaries for drivers and stuff.
In the case of the Pyra, at least the 3D acceleration and wifi firmware. Maybe something could be hidden there.
B: Put it in one of the meta data scripts (config/preinst, config/postinst). These scripts can basically do anything. They are open source but I have a feeling there might not be as many eyes on them as on the actual payload data.

Different eyes, I guess, debian maintainers may look more at debian scripts than upstream source (which they also look) and upstrem devels or the larger community accross distros may look more at upstream code.
I'd say it might balance out. But I don't know, and I feel you can't know. The risk of being found may be a bigger deterrent than actual audits. And besides, we have no better system, so you can as well trust this
(and you may want to minimize the amount of sfotware you run, because the only secure software is that which is never run).

C: Hide it in plain sight. Some months ago there was a bug in Debian concerning xscreensaver, that revolved around the upstream author putting a warning popup into his software triggered at a specific date, that advised the end-user to upgrade xscreensaver from upstream because he felt that a distribution that did not follow upstream closely would do its users a disservice. [2] The issue itself was harmless, but it showed that putting "time bombs" in Debian packages and getting them all the way through unstable and testing into stable is totally possible.
Interesting. I didn't know.

bottom line:
Don't trust that Debian will be safe! It might be one of the safest distributions out there, but there will never be absolute certainty (obviously).

+1
 
Would be interesting to know whether the RAM chips used for the 4GB version are more susceptible to the attack than the ones used for the 2GB version.
 
Wow... that's all smells very iffy to me. Can we get some more if on that?

This type of attack relies on the physical hardware and OS being known to the attacker. Because of that fact alone, it is far more likely to be thrown at devices sold in the millions than devices sold in the thousands.

To work, it requires knowledge of the physical address spaces to the point of knowing which bits are directly beside the bits holding authentication/access bits. To get there, they need to know exactly what was read or written to an exact physical memory address.

Odds of it being done to this little obscure device from a small company - not high. By those measures, the Pyra is probably 'safer' from this than pretty much any other device.

The proof of concept has been proven on machines running the Linux kernel, but this exploit isn't necessarily limited to only Linux - that is simply where it is easier to spot.

I'm not a fan of security through obscurity, but I understand that this hack is getting addressed upstream in the kernel too.

The worry and concern over this exploit isn't Pyra speciic- in fact it should be less concerning for the Pyra - which doesn't even exist in the wild yet for anyone to attempt it on.

Oh, and nobody caught hns's Pyra information leak. It's official. The Pyra will have mature, well hung DRAM. So, we'll have that going for us.
 
That's the one, thanks. Looks like there's still some way to go, but at least the list of unreproducible armhf builds aren't that much bigger than the list of unreporoducible arm64 builds: https://tests.reproducible-builds.org/debian/unstable/armhf/index_notes.html
[doublepost=1477419798,1477417886][/doublepost]
To work, it requires knowledge of the physical address spaces to the point of knowing which bits are directly beside the bits holding authentication/access bits. To get there, they need to know exactly what was read or written to an exact physical memory address.

Odds of it being done to this little obscure device from a small company - not high. By those measures, the Pyra is probably 'safer' from this than pretty much any other device.

I couldn't make complete sense of Pyrat's google quote above, but it sounded like there was some system call you could make to guarantee getting back a contiguous block of memory (and adjacent to previously allocated blocks, I assume). Some sort of ASLR over this allocated area might be able to mitigate the impact that a rowhammer exploit has, but reports of this being exploitable to priviledge crack is news to me, so I haven't really read up on how it uses rowhammer to do that yet.
 
The other thing too, my main Windows pc has been running from the same harddrive for the last 5 years, installed an mbam just the other day and found nothing. I doubt anything damaging will reach the pyra if you have common sense and know what sites are shady.
 
Back
Top