Has anyone tested if the L5 is susceptible to any known Rowhammer bugs? For instance against the TRRespass? https://github.com/vusec/trrespass
If I understand this “Rowhammer” thing correctly, it is about tricks that a malicious program can use to gain access to parts of computer memory that it is not supposed to have access to. So for example, some program running in a sandbox that is supposed to be locked in there, can using such tricks reach outside of its sandbox.
Then, I would think that as a Librem 5 user I don’t need to worry too much about that, because the idea with the Librem 5 is to run only free software on it. That is my main line of defense here, I aim to not have any malicious programs running on my CPU. Android users might be more worried, if they have all kinds of unknown proprietary code running and they are relying on sandboxing to keep some things safe.
Does the above make sense, or have I misunderstood some part of this?
You’re not going to be limited to running Free Software only if you ever browse the web. The memory module on the L5 offers some self-refresh boost thingy to protect against rowhamer, at least on the data sheet. I don’t think its efficacy was tested.
There are variants of RH that work with JS in the browser. Basically everyone runs untrusted code while surfing the web. Hence I would not generally rule out that RH can be applied to the L5.
Edit: maybe @dcz’s answer can rule it out. I can’t judge.
Yes the risk is that a remote hacker will gain full access to your L5. Like the other answers point out, there are many cases where open-source does not protect you. For instance, you read an email in your favorite open-source email reader that exploits your email process, and then from there the attacker runs a Rowhammer on the L5 and gains full access.
Ah, I forgot about that. So it is this issue again:
Any data that you receive may exploit your computer or phone. It could be an email, a web-site, a video, an image, a text message, a phone call, really any data. How it works is quite difficult to explain in detail, but I’ll try a simple explanation using Geary.
You receive an email from a friend that contains an image. You open the email, and either Geary or you open the image to see it. To display it the computer needs to read the image and parse it. If there are bugs in the code or parser known by the attacker then the attacker can create (or craft like it is called in this context) an image that exploits this bug. This will give the attacker the same privileges as the exploited process. From there the attacker can use other bugs to escalate their privileges if they like.
Here is just one example. There are at least millions of these exploits out there, publicly know, privately known (undisclosed), or unknown.
Thanks for explaining what you meant, but this is no longer about Rowhammer but just the fact that attackers can exploit bugs, that is of course true but it is nothing new and not related to Rowhammer?
Suppose there are no exploitable bugs in Geary (or libraries etc that Geary uses) that the attacker knows about. Then I can read my emails safely?
Yes, but the assumption should be that there are many of these bugs in Geary or in one of it’s dependencies, like png-parser, etc. Formal verification is the only thing that could fix the bug-problem.
The example is not about Rowhammer, but it could be. A correctly crafted image together with a certain type of bug could probably run a Rowhammer exploit. The easiest example though is the one already given, the browser and web-sites.
The point is that RH triggers physical effects to switch bit values in your devices memory. With this the attacker might overcome ordinary boundaries of protection.
To trigger this phyisical effect the attacker needs to write memory fast. This is done by some program code from the attacker.
If the attacker manages to run his malicious code, he triggers the effect, overcome the boundary and has more control over the system than he should.
There are many many exploits involving specially-crafted, usually malformed files targeting bugs in parsers or other file processing code. That affects web browsers as well as email clients.
Just about every file type (maybe excluding ASCII plain text ) has had an exploit at some time or other on some platform. Everything from business cards to fonts.
If the code is 100% bug-free then you may be safe, if the hardware is also bug-free. I wouldn’t call this assumption unlikely, I would call it very extremely unlikely At least for the following decades. It does not really have with open-source to do in this case, since you could have bug-free proprietary software. It is even possible to be able to verify that some properties hold for proprietary software by only inspecting the binary code. The open-source seL4 project has done that, verifying the binary implementation of a small OS.
It really is the same case. Both scenarios deal with unknown (and possibly crafted) data being processed by some process.
Quoting from this paper: https://arxiv.org/pdf/1507.06955v1.pdf
Although our eviction-strategy-finding algorithm (pre-sented in Section III) works on different Intel CPUs, it isnecessary to evaluate how it performs on non-Intel platforms,e.g., AMD x86 or ARM CPUs. Modern smartphones havefast DRAM modules integrated and should be examined forpotential security risks.
Either that or fixing the problem with the hardware. The main question is still not answered, though, does the L5 suffer from this Rowhammer bug? Please post the results here if you try it. I may try it if I get some time.
Interesting project. Please document your procedure as well as the results.
You should look if prior work on ARM systems has been done meanwhile. Maybe even something near the L5’s HW. Maybe you can take existing PoCs and adapt them.
Also keep in mind:
Maybe you can find out more.
edit: maybe it’s worth to read the papers of RH & Co.
Does ECC memory help mitigate rowhammer attacks?