Lastpass

[rjrizzuto]

I just installed GrapheneOS on a Pixel6a to test how it would suit my needs. I am using the sandboxed Google Play Store, and installed Lastpass from it. It failed to run till I turned on "Exploit protection compatibility mode".

Thankfully this isn't a showstopper, but it would be helpful to have a list of apps known to have this issue.

[thestinger]

They should fix the memory corruption bugs in their app. You should file an issue with them, not us.

[rjrizzuto]

I doubt I have either sufficient insight into the issue, or leverage with LastPass, to effect that change. In my experience as a software engineer, issues like this could be due to bugs on either side, or some difference of interpretation of the API.

My purpose in entering this information was to report this incompatibility, not get into a debate on what is causing the problem. My secondary purpose was to suggest that it would be useful to other users to know which apps needed to have this compatibility mode set.

I have literally just installed GrapheneOS today, and Lastpass is the 3nd app I have installed after the sandboxed play store. I have ~50 apps total that I will be installing as part of my evaluation to see if I can move to GrapheneOS.

[thestinger]

It's not a bug in GrapheneOS. It's a memory corruption bug in the app. They need to fix it. It's not caused by a difference in interpretation of an API.

[rjrizzuto]

I can try to report it to Lastpass, but I may get the response that GrapheneOS is not a supported environment. In my experience, it would be better to call it an incompatibility between Lastpass and GrapheneOs unless there is some evidence (logs?) that I can provide to them to show that it is a memory corruption bug.

[thestinger]

It's a memory corruption bug detected by GrapheneOS, not an incompatibility with something we do.

[rjrizzuto]

I didn't say it was. I was saying it is more political to call it an incompatibility. It is my experience that I get better results being less confrontational.

[rjrizzuto]

Since I have a paid Lastpass account, I was able to create a support ticket about this issue.

I do think it would be helpful to users to have a list of other apps that will need this switch turned on. FWIW, I am using LastPass 5.25.0.14913

[rjrizzuto]

FWIW, this is what I reported to LastPass

"I am in the process of migrating to GrapheneOS, which is a privacy enhanced version of Android. When I install and run Lastpass, it fails unless I turned on "Exploit protection compatibility mode". The GrapheneOS team has said that this may be an issue caused by their enhanced malloc, which is designed to enhance the privacy and security of GrapheneOS. I wanted to report this, in the hopes that a future version of Lastpass will work better with GrapheneOS, i.e. without needing this compatibility mode."

Best regards,

Ray

[thestinger]

The GrapheneOS team has said that this may be an issue caused by their enhanced malloc, which is designed to enhance the privacy and security of GrapheneOS.

This is not what we said. The issue you've filed is going to encourage them to ignore the issue and future issues going forward.

[thestinger]

We know their app has a memory corruption bug. It has been looked into before. The memory corruption bug is present with or without GrapheneOS and is a serious problem they should fix. GrapheneOS detects it with hardened_malloc and the app aborts. It's known to be an issue in the app and it's not hardened_malloc causing the problem. You've written this as if you're trying to convince them that they should ignore the report and future reports going forward.

[rjrizzuto]

I must respectfully disagree with you. You said "You should file an issue with them, not us.". I have done so, and I can provide them additional details when they reply.

If this has been investigated in the past, I'd be grateful for any details I can add.

You mention that the app aborts. Is it aborting itself, or is it aborted by GrapheneOs? If the latter, I think it would be helpful to the user if there was a popup about that.

I am so far very impressed with GrapheneOs. I was a programmer for 40 years, so I can appreciate the amount of time and effort that has gone into it. I hope you will take my input in the fashion it was intended, as constructive.

[matchboxbananasynergy]

@rjrizzuto Hi there. I think you might find a good explanation of what is going on in this section of the website:

https://grapheneos.org/usage#bugs-uncovered-by-security-features

What is happening is that Lastpass has a memory corruption issue. Hardened_malloc catches it and intentionally makes the app abort to protect the user. It is not a GrapheneOS related bug, but rather an intentional feature. The app won't crash on devices not using hardened_malloc as they don't catch the memory corruption issues like it does. That doesn't mean that the memory corruption issue on Lastpass and other apps doesn't exist there; it does, and goes unnoticed, and is a security issue.

Exactly because hardened_malloc catches memory corruption and intentionally makes bugs abort, we introduced the "exploit protection compatibility mode" toggle for apps so that you can disable hardened_malloc for those specific apps if they have memory corruption security issues which are being caught by it, but you still want to use it.

We essentially provide the security feature by default, with the ability for the user to override it if they choose to use it anyway. That said, the root cause of the issue is still that Lastpass (or any other app with a memory corruption issue, of which there are many) has a memory corruption bug that they need to address, which is a security issue and goes unchecked in other OSes.

I hope that this additional context was helpful!

[rjrizzuto]

Thanks, @matchboxbananasynergy, I had already read that. I programmed for 40 years, and I have used malloc libraries with similar capabilities. Even wrote some simple tools that would add sentinals before and after the block of memory to detect overwrites beyond the buffer on some embedded OSs I worked on.

In my original post, I merely wanted to report the issue (I didn't know it was a known one) and ask if there was a list of apps that were known to fail under the stricter malloc.

I do want to point out that there isn't any indication to a user when an app is killed due to a memory overwrite/exploit detection. A simple popup saying app was terminated and why would have made it easier to figure out the cause and work-around. It is only because of a youtube video I saw that I knew of this being a possibility.

Given that GrapheneOS has less than a .1% market share compared to stock android, it would be hard to get Lastpass or any other app company to acknowledge or fix their app without providing a log or screenshot as evidence. As a user, I can't give an attestation to Lastpass on the reason for the app failing. All I can do is pass on what I was told, in as effective a manner as possible. If that doesn't suffice, then @thestinger should engage Lastpass directly.

I am debating continuing with GrapheneOS. I do like the privacy features that it provides, but from my experience in this post I am not sure that it is well enough supported. I hope it continues to grow and develop a revenue stream that will allow for better support.

What I wish I had heard in response to my initial post is:

"Thank you for taking the time to report this. The issue with Lastpass is a known memory corruption bug, which was reported to them on x. A list of apps that are known to have similar bugs is at y."

Such a response would have been very helpful to me and other users transition to GrapheheOS.

[thestinger]

It's unrealistic to get every app developer to fix detected memory corruption bugs and it's unrealistic for us to track their progress doing it. We'd have to test every new release of LastPass to see if they'd fixed it yet, and the same for every other app. We'd also have to confirm these things ourselves. We can't simply rely on user reports alone. We'd need to have people who are responsible for doing it so the info can be trusted, otherwise people could submit incorrect data by accident or even on purpose.

There are signs of a crash being caused by a memory corruption bug being detected. hardened_malloc has a bunch of cases it directly detects corruption, but in many cases it's detected via memory protected pages due to extensive use of guard pages for freed data, as guards between every slab and random guards between every large allocations. For example, 16 byte allocations are in a 4k slab with 256 slots for them. The order they're allocated is randomized. There's a 1/256 chance that the first one in a new slab ends up at the end. If it's at the end, then right after the 8 byte random canary with leading zero byte, there's protected memory. If the process reads or writes the protected memory, the process crashes. These kinds of crashes exist without hardened_malloc, but it's much less likely that the memory corruption will be detected since there aren't comparable checks in the allocator guaranteed to detect all invalid frees, data isn't zeroed or memory protected on free, data isn't checked to make sure it's still zeroed before being handed out to be used again, there aren't aggressively interspersed guard regions, etc.

We have planned to implement a notification for these kinds of crashes for a while, but we don't want to encourage people to simply enable exploit protection compatibility mode after any crash. It reduces the exploit protections for the app significantly and closer to the stock OS than normal GrapheneOS. The app is easier to exploit. These hardened_malloc features don't have false positives and every case is the app doing something highly invalid and dangerous. It's not based on heuristics or anything like that.

I am debating continuing with GrapheneOS. I do like the privacy features that it provides, but from my experience in this post I am not sure that it is well enough supported. I hope it continues to grow and develop a revenue stream that will allow for better support.

The issue tracker isn't a support platform. Our chat rooms and discussion forum are the support platforms and GrapheneOS project members do provide support there.

[matchboxbananasynergy]

To expand on what was said above, there are community sourced app compatibility lists (one example is banking apps). It might be worth doing this for apps with memory corruption bugs which would not only help GrapheneOS users know when they need to enable exploit protection compatibility mode for an app, but also help to highlight how many apps have memory corruption issues that they need to address.

This would have to be an unofficial community-sourced effort, however, for the reasons mentioned above, those being:

• It would be unrealistic for our team to maintain a list like that and keep it up to date
• Since the above wouldn't be possible, and we'd be relying on crowd-sourced data, we couldn't officially vouch for it, so any recommendation to refer to that list would come with a disclaimer explaining that it is not an official resource to make sure that this is understood.

Regarding your closing statement about using GrapheneOS or not, I do hope that you'll give it a shot, and I'm sorry to hear that your experience was not ideal here, but rest assured that we're constantly improving across all areas, which you should be able to see if you stick around :)

[rjrizzuto]

@thestinger, thank you for the additional information. It is a bit of a conundrum on how to track and handle apps that crash with the hardened malloc. As the author of GrapheheOS, you prefer to have users use the hardened_malloc. As a user, Lastpass is mission critical to me. My only choices are to turn off the hardened malloc, or abandon GrapheneOS.

Previously you said "We know their app has a memory corruption bug. It has been looked into before.". It seems like there might be a mechanism for users to report apps that only misbehave under the hardened malloc. Perhaps they could be vetted by other users, or a Graphene developer.

Adding notification of logging into Graphene might make it easier for users to provide more accurate reports of these cases.

I apologize if I have used the wrong vehicle for this report. I was following the directions at https://grapheneos.org/contact#reporting-issues, specifically the one for the hardened malloc. https://app.element.io/#/room/#grapheneos:grapheneos.org didn't seem as useful since it was more of a chat room. Plue I already had a github account.