The RAM shredding feature seems kind of silly to me, but I don’t know the details. Ideally the operating system should clear pages before giving them to other applications… While I can see the appeal in also doing it in the application, it seems kinda wasteful, and I wouldn’t trust the application to do a good job of that anyway. If the point is to prevent the app itself from leaking private keys on a buffer overflow or whatever… I guess I can see the value of that, but I’d rather see mitigations for the buffer overflows highlighted instead. I guess this just makes me a little suspicious of the actual value provided by the app.
I’m not an Android dev, but at first glance it looks like all this does is try to allocate all of the free memory in the system, and walks through the pages and uses rand() to fill in all of the bytes. Technically it’s possible for the pages returned by malloc to contain old data, but only if it was allocated by your process in the first place (maybe that’s not the case on Android?)… So I guess the idea is that if Molly itself is compromised and an attacker is able to allocate memory in the Molly process they could conceivably get an old page from memory and that page might contain secrets from the Molly app itself… But at that point, surely you’re fucked anyway, and the attacker can presumably read all of the currently allocated memory which is certainly far more of a security concern anyway? I just don’t think it’s worth the cycles.
That’s fair. Just when applications tout dubious security features it makes me a little sceptical of the expertise of the developers. At the very least I’m disappointed that they don’t have more details on this. If it is valuable, I’d be interested to hear more about it.
The RAM shredding feature seems kind of silly to me, but I don’t know the details. Ideally the operating system should clear pages before giving them to other applications… While I can see the appeal in also doing it in the application, it seems kinda wasteful, and I wouldn’t trust the application to do a good job of that anyway. If the point is to prevent the app itself from leaking private keys on a buffer overflow or whatever… I guess I can see the value of that, but I’d rather see mitigations for the buffer overflows highlighted instead. I guess this just makes me a little suspicious of the actual value provided by the app.
Okay, I got curious and looked into it… These are the relevant files for the “RAM shredding”
I’m not an Android dev, but at first glance it looks like all this does is try to allocate all of the free memory in the system, and walks through the pages and uses
rand()to fill in all of the bytes. Technically it’s possible for the pages returned bymallocto contain old data, but only if it was allocated by your process in the first place (maybe that’s not the case on Android?)… So I guess the idea is that if Molly itself is compromised and an attacker is able to allocate memory in the Molly process they could conceivably get an old page from memory and that page might contain secrets from the Molly app itself… But at that point, surely you’re fucked anyway, and the attacker can presumably read all of the currently allocated memory which is certainly far more of a security concern anyway? I just don’t think it’s worth the cycles.The biggest thing molly has going for it is its f-droid repo and fully Foss version.
That’s fair. Just when applications tout dubious security features it makes me a little sceptical of the expertise of the developers. At the very least I’m disappointed that they don’t have more details on this. If it is valuable, I’d be interested to hear more about it.