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