Cross-user malware propagation : how to reduce the risks?

dhhdjbd

I think the allow installs toggle is not a security feature like that. For example, it does not affect private spaces. Or it is still possible to update system apps.
so i think it should be treated as another hurdle for the user to accidently install an app in my opinion. And not as something that can stop an sophisticated attacker

i think, about user profiles, the features one wants to rely on in this case, is the at rest encryption of unused profiles + secure boot (frequent reboots).
(i think most of these maleware exploits are not persistent)

DeletedUser421

de0u That doesn’t prove any of your claims. I’m particularly interested in your claims about the Android client being written in memory unsafe languages. AFAIK Java is not considered memory unsafe, like for example C.

Memory safe languages can still have those issues, so I don’t think that your link proves anything.

de0u

de0u Here is a list of WhatsApp CVEs: https://app.opencve.io/cve/?vendor=whatsapp

That list contains "stack overflow", "buffer overflow", "heap corruption", etc.

DeletedUser421 That doesn’t prove any of your claims. I’m particularly interested in your claims about the Android client being written in memory unsafe languages. AFAIK Java is not considered memory unsafe, like for example C.

What I posted was a list of WhatsApp CVEs. I don't think I made any claim about which languages WhatsApp is written in.

To my eyes, that list of CVEs does seem consistent with a claim (made by somebody else) that WhatsApp is "poorly coded".

For comparison, here is a list of Signal CVEs: https://app.opencve.io/cve/?vendor=signal

By the way, a web search for zero-click WhatsApp seems to turn up more than a search for zero-click Signal (the latter search includes reports of a location leak in CloudFlare that affected Signal among other messaging apps).

To be clear, I am not making any claims about which language(s) WhatsApp or Signal are written in.

DeletedUser421

de0u It looks like both WhatsApp and Signal use libraries that are written in memory unsafe languages. For example WebRTC. Signal proxies traffic through their own middleware library called RingRTC, which seems to be written in memory safe languages: https://github.com/signalapp/ringrtc
However, I don’t think that this prevents memory safety issues, since it still uses WebRTC.

I don’t know exactly how WhatsApp utilizes WebRTC.

I think that this is a better source: https://margin.re/2024/07/you-cant-spell-webrtc-without-rce-part-1/

In order to prevent those issues, it would be necessary to remove video calls and probably other functions as well, like https://github.com/mollyim/mollyim-android/issues/141

DeletedUser421

de0u I’m sorry, I thought that I was replying to the same person as before, so forget about the "your claims". And sorry for posting so many times.

DeletedUser421

de0u Yes, I made a mistake, that was ryrona.
To be fair, it’s quite likely that WhatsApp is using more libraries written in memory unsafe languages, so it’s probably true to some extend. I also made a mistake in my assumption that WhatsApp is using WebRTC. It seems to be using PJSIP which is primarily written in C. Project Zero team at Google has written several posts about Android Messengers, WebRTC and WhatsApp/PJSIP

ryrona

alf1342 For me, apks are stored in a separate memory space from those of the users.

True.

alf1342 If you clone an application for a secondary user from the owner user, the apk is installed from that space into the user space.

No. It is still only in the shared space. All that happens is that a launcher for it is added in the secondary user profile, pretty much. And data and cache directories for the app is created in that user profile.

alf1342 But if a secondary user has the right to install applications, and updates the application, the shared space apk will be modified and all users will install this new version of the application.

Yes, the APK in the shared space will be updated with the new version, so all users will automatically be using the new version.

alf1342 In a way, a secondary user can "propagate" a modified version of an application to all other users.

All APKs are signed. It is only possible to upgrade an APK for an app with a certain ID if the new upgraded version is signed by the same key as the already installed one. This might be the key of the developer or the app store. So one cannot upgrade to a compromised version without the original app developer or trusted app store cooperating by signing the compromised version.

Not even uninstalling the app and installing a new compromised one with the same app ID will work. All uninstalling will do is remove the launcher, and data and cache directories. The APK from the shared space is only removed if no user profile has the app anymore. So if the launcher is removed from within a secondary user profile, and one attempts to install a new compromised version signed with attacker controlled keys, the installation will be rejected since signing keys doesn't match already installed APK.

alf1342 Preventing a secondary user to install apps, may reduce that risk.

No, it should be secure against that already.

alf1342 So, if I understand, if an app use an OS exploit to escape the app sandbox, for you, it can monitor all the activities taking place in the other running user sessions (like doing screenshot, ..)?

That is my understanding, yes. There are no isolation between user profiles beyond the app sandbox.

ryrona

DeletedUser421 Do you have a source for your claim about the WhatsApp android client not being written in memory safe languages? How do you know that it’s poorly coded?

There are many reports on this forum about WhatsApp crashing with memory tagging violation when MTE is enabled for all apps on 8th gen and 9th gen Pixel devices that supports MTE. MTE only detects true memory violations, and those can only happen in memory unsafe languages. So WhatsApp is partially coded in memory unsafe languages. Not only that, it is so poorly coded that MTE triggers all the time even in the absence of attacks. That doesn't happen for your average app written in memory unsafe languages. And basic internal testing for security issues would catch these, so they are clearly not testing WhatsApp for security issues.

I don't know what components of WhatsApp it is that is written in memory unsafe languages, or what languages, but MTE does not lie. It only detects actual memory violations.

(To be fair, there was a single report of Signal crashing this way too. Unclear if it was due to an attack or not. So somewhere there is memory unsafe code there too. Everything in Signal seems to be written in Kotlin and Rust, so maybe there is some Rust library that is using unsafe Rust code. Will be interesting to see where that reported ticket leads to.)

userofgos

ryrona @DeletedUser421 I can attest to WhatsApp being poorly coded when it comes to MTE crashes, DCL via memory or via storage. Happens all the time, it's extremely annoying.

DeletedUser421

ryrona If you look at past WhatsApp RCE vulnerabilities, they usually affect the media parsing libraries or (video) calls. E.g. the android-gif-drawable library which is 41% C. I don’t know if they still use those.

The recent MTE crash in Signal seems to affect RingRTC, probably due to WebRTC which is written in C++. I don’t know which media parsing libraries Signal is using.

DeletedUser405

Disclaimer: I'm not a professional on this front, I just like to research for fun.

ryrona Signal is written in memory safe languages, and they are taking memory security issues extremely seriously. Messengers like Element that requires you to accept a chat before any messages or other content is even attempted to be loaded are likelier also a safer choice than WhatsApp

Consider using Molly as an alternate Signal client, or SimpleX.
https://www.privacyguides.org/en/real-time-communication/

alf1342 But I have trouble understanding the analyses that have been done on discovered malware

GrapheneOS's auditor app can help scan Android devices for malware, and nonpersistent malware can be wiped after a device restart. Consider restarting every day if it suits your threat model.

If malware executes kernel level code, you might be cooked, though. Practice good browsing, email, and password habits.

Pixels 8 and later with and without GrapheneOS can be used as an alternative to desktop operating systems, you can display your phone to a monitor. This is much more secure than traditional operating systems, so it may be worth considering.

Lastly, you may want to check out this guide below, and ask the Privacy Guides forum too.
https://discuss.privacyguides.net/t/defending-against-targeted-attacks/27344/1

DeletedUser405

DeletedUser405 This is much more secure than traditional operating systems, so it may be worth considering.

Important to note that this feature is still in beta, too, so you will have to tolerate some hiccups