Hello,

Recently, there has been a significant amount of discussion surrounding the WebP vulnerability identified as CVE-2023-4863 - mainly because of the severe implications it has in a lot of different software.
There is a really good technical explanation for those that are interested.

While I am aware that GrapheneOS already provided a patch for this in 2023091800, it made me curious of the possible impact it would have had, if exploited prior to the patch.
I am especially curious about the potential impact within the context of app sandboxing and the per-app permissions provided by GrapheneOS.

Consider a scenario in which a device is running GrapheneOS prior to the patch.
Let also assume the device has a vulnerable app installed that uses the webP library (for example, a messenger app).
In the event of an exploit, the attacker can inject a payload into the device's memory heap and execute it.
Now, here are my questions:

  • I presume that the exploit would operate with the same permissions as the compromised app. Is that correct?
  • Would the sandbox prevent the payload from elevating further? Would the sandboxing mechanism of GrapheneOS prevent the payload from escalating is privileges further?
  • How would the app-specific permissions come into play? For instance, if the vulnerable app had not been granted any network-related permissions, and the payload is loaded manually, e.g. by opening a file (payload) from disk within the messenger app - would the permission system prevent the exploit from establishing a connection once it is executed?
  • Would hardened_malloc provide additional complications for an attacker, trying to craft a payload?

    6gsxdr3U I'm commenting here so I can easily check this thread later, please do not take me as a verifiable matter-of-fact resource, for this particular inquiry.

    Due to the nature that all Google apps and services are ran as user not system 'Administrator', pretending for example that Google messages is the one being targeted I don't believe much would happen unless it was able to escape the sandbox and even then it would still be quite limited but it would still be possible for things to happen..I think? I'm not that knowledgeable about the inner workings of GOS, just the general concepts of what would need to happen in order for this to have any effect.

    However, if this was done on the same Google messages but stock Android, there is a chance that because some services while not Google messages itself is ran is system 'administrator' then there could be a higher propensity for something to happen. for example Google framework

    If anybody has any other thing to add and/or correct please feel free as my take on this is based on my own professional experience of computer system protocols and capabilities not GoS

      6gsxdr3U I presume that the exploit would operate with the same permissions as the compromised app.

      At least to start with.

      6gsxdr3U Would the sandboxing mechanism of GrapheneOS prevent the payload from escalating [its] privileges further?

      That's the idea! But it's not possible to provide precise answers when the question is "Exactly what would happen after something happens that isn't supposed to happen?".

      If an evil image can result in code execution, that's RCE ("remote code execution"). The next question is "how much code can be run, in what context?". If it's only a little code, but the little code can open up a network connection and download more code, that's bad.

      6gsxdr3U How would the app-specific permissions come into play? For instance, if the vulnerable app had not been granted any network-related permissions, and the payload is loaded manually, e.g. by opening a file (payload) from disk within the messenger app - would the permission system prevent the exploit from establishing a connection once it is executed?

      That's the idea! But if the RCE is coupled with a privilege-escalation attack, then maybe the code can take over more than just the one application.

      Would hardened_malloc provide additional complications for an attacker, trying to craft a payload?

      That's the idea!

      I've read that this WebP attack was carried out by NSO, i.e., a highly-skilled and well-funded attacker. Highly-skilled, well-funded attackers (including the governments of North Korea, China, the U.S., etc.) are good. It would not be surprising if NSO had a full-time staff member searching for Android privilege-escalation attacks to be deployed any time an RCE is found. It would not be surprising if some APT had a full-time staff member dedicated to GrapheneOS vulnerability research.

      Good vulnerabilities are worth a lot of money, so a good one may be deployed judiciously against a small number of high-value targets, rather than against "regular people". So if you are a regular GrapheneOS user, the increased security of GrapheneOS versus baseline unpatched Android, plus you not being a high-value target, may put you in a good place. But if you are a high-value target then you'd better be deploying good opsec.

      A lot of people are running old versions of Android that have lots of known vulnerabilities. You may wish to avoid doing that. GrapheneOS chooses devices carefully, and issues security updates promptly, and doesn't ship a lot of convenience-only features, and drops support for old devices -- because skipping any of those adds a lot of risk.

      Please note that I don't speak for the GrapheneOS project.

      • [deleted]

      • Edited

      N3rdTek Due to the nature that all Google apps and services are ran as user not system 'Administrator'

      Both Android and GrapheneOS don't have an 'administrator' mode. There is only root and only a few highly privileged components like init and voldrun as root, and even they are confined by the SELinux policy.