đĄ So sieht die Agov Access App bei mir aus, die man in der Schweiz fĂŒr digitale BehördengĂ€nge braucht.
-
@toke @adfichter There's a bunch of stuff that's normally preloaded which gets loaded on demand with secure spawning instead. There are also things which simply aren't present in memory because it's only set up in the Zygote. None of this impacts correctly written apps not looking at internal implementation details. Unfortunately, these anti-tampering checks do very strange and incorrect things as part of their misguided goal of detecting tampering. It's completely insecure and has no benefit.
@GrapheneOS @adfichter right, I'm not disputing that the app is broken. However, it's also the only available payment solution in many places in Denmark, so it would be kinda nice to have a workaround or a per-app toggle to make it work. I'd rather not turn off the security feature system-wide, for obvious reasons
-
@GrapheneOS @adfichter right, I'm not disputing that the app is broken. However, it's also the only available payment solution in many places in Denmark, so it would be kinda nice to have a workaround or a per-app toggle to make it work. I'd rather not turn off the security feature system-wide, for obvious reasons
@toke @adfichter We could make a per-app toggle for secure spawning. However, the Zygote has all of our per-app hardening features enabled so ones requiring a fresh address space to disable can't be disabled without secure spawning. If an app has a memory corruption bug requiring disabling hardened_malloc or can't run with a 48-bit address space then it will require secure spawning unless we have a non-hardened Zygote which we don't want to. It would also mean leaking Zygote layout to the app.
-
@toke @adfichter We could make a per-app toggle for secure spawning. However, the Zygote has all of our per-app hardening features enabled so ones requiring a fresh address space to disable can't be disabled without secure spawning. If an app has a memory corruption bug requiring disabling hardened_malloc or can't run with a 48-bit address space then it will require secure spawning unless we have a non-hardened Zygote which we don't want to. It would also mean leaking Zygote layout to the app.
@toke @adfichter Zygote doesn't have much attack surface but we don't really want to have a compatibility approach for this depending on leaking the layout to specific apps which would then also know each other's layout. It's different than exploit protections which only protect apps from attacks. We already resolved the issue of apps checking the call stack to try to detect hooking and we should be able to resolve any other compatibility issues from anti-tampering checks for secure spawning.
-
@toke @adfichter Zygote doesn't have much attack surface but we don't really want to have a compatibility approach for this depending on leaking the layout to specific apps which would then also know each other's layout. It's different than exploit protections which only protect apps from attacks. We already resolved the issue of apps checking the call stack to try to detect hooking and we should be able to resolve any other compatibility issues from anti-tampering checks for secure spawning.
@toke @adfichter It would be possible to apps to go out of the way to detect secure spawning in a way we couldn't prevent but they're not actually trying to detect it, they're just doing all kinds of cargo cult security checks by checking that things are the way they were on devices they tested which happen to be different when using exec after fork. We have a good idea about what the main remaining compatibility issue is and we should be able to fix it fairly easily. We just have a lot to do...
-
@toke @adfichter It would be possible to apps to go out of the way to detect secure spawning in a way we couldn't prevent but they're not actually trying to detect it, they're just doing all kinds of cargo cult security checks by checking that things are the way they were on devices they tested which happen to be different when using exec after fork. We have a good idea about what the main remaining compatibility issue is and we should be able to fix it fairly easily. We just have a lot to do...
@toke @adfichter Our most recent release (2026050400) hasn't gone to the Stable channel due to incorrect anti-tampering checks which crash with this change:
> bionic: clamp the minimum size of the random guard region we add between the stack and pthread_internal_t (thread-local storage and other sensitive data) for secondary stack randomization to the page size to guarantee we always add a guard page protecting pthread_internal_t from stack buffer overflows
We fixed it for today's release.
-
@toke @adfichter Our most recent release (2026050400) hasn't gone to the Stable channel due to incorrect anti-tampering checks which crash with this change:
> bionic: clamp the minimum size of the random guard region we add between the stack and pthread_internal_t (thread-local storage and other sensitive data) for secondary stack randomization to the page size to guarantee we always add a guard page protecting pthread_internal_t from stack buffer overflows
We fixed it for today's release.
@toke @adfichter Banking apps often use third party SDKs which claim to detect tampering. They do all kinds of invasive checks depending on internal implementation details. It's highly insecure and serves no actual purpose. The latest example we ran into is that apps are scanning /proc/self/maps for the first anonymous mapping named stack_and_tls:main which is where Android puts the pthread_internal_t and other per-thread data for the main thread. Other threads have their stack there too.
-
@toke @adfichter Banking apps often use third party SDKs which claim to detect tampering. They do all kinds of invasive checks depending on internal implementation details. It's highly insecure and serves no actual purpose. The latest example we ran into is that apps are scanning /proc/self/maps for the first anonymous mapping named stack_and_tls:main which is where Android puts the pthread_internal_t and other per-thread data for the main thread. Other threads have their stack there too.
@toke @adfichter In Android, it's a mapping with a guard page at both ends with the stack, pthread_internal_t, static thread-local storage and libgen buffers in between the guard pages. We put a randomized guard region at the top of the stack to have secondary stack randomization and it also protects pthread_internal_t, etc. from stack buffer overflows. We were already rounding up to page size but the random size could be 0 which resulted in no guard. 2026050400 clamps minimum size to 1 page.
-
@toke @adfichter In Android, it's a mapping with a guard page at both ends with the stack, pthread_internal_t, static thread-local storage and libgen buffers in between the guard pages. We put a randomized guard region at the top of the stack to have secondary stack randomization and it also protects pthread_internal_t, etc. from stack buffer overflows. We were already rounding up to page size but the random size could be 0 which resulted in no guard. 2026050400 clamps minimum size to 1 page.
@toke @adfichter We also randomize the top of the stack for secondary threads by up to 1 page below the gap to have the lower bits randomized. It doesn't break anything because it's normally space used by pthread_internal_t and we added reserved space for it and the random gap.
Clamping to 1 page minimum resulted in adding a redundant guard to the main thread stack's pthread_internal_t / TLS region since the stack there is 0 size which is also the case for self-allocated secondary stacks.
-
@toke @adfichter We also randomize the top of the stack for secondary threads by up to 1 page below the gap to have the lower bits randomized. It doesn't break anything because it's normally space used by pthread_internal_t and we added reserved space for it and the random gap.
Clamping to 1 page minimum resulted in adding a redundant guard to the main thread stack's pthread_internal_t / TLS region since the stack there is 0 size which is also the case for self-allocated secondary stacks.
@toke @adfichter That resulted in having a PROT_NONE page called anon:stack_and_tls:main page in /proc/self/maps followed by the area with pthread_internal_t, thread-local storage and libgen buffers. The anti-tampering checks and obfuscation done by these apps is doing something with that data and it crashes trying to access the guard. It's a nice example of how horrific these checks are. We've had a lot of problems caused by them which have certain security improvements into a hassle.
-
@toke @adfichter That resulted in having a PROT_NONE page called anon:stack_and_tls:main page in /proc/self/maps followed by the area with pthread_internal_t, thread-local storage and libgen buffers. The anti-tampering checks and obfuscation done by these apps is doing something with that data and it crashes trying to access the guard. It's a nice example of how horrific these checks are. We've had a lot of problems caused by them which have certain security improvements into a hassle.
@toke @adfichter Facebook's React Native has a buggy stack overflow check which breaks if the minimum stack guard size (the one below the stack to catch stack overflows) is raised from 4k to 64kiB as required by the AArch64 ABI for the default stack probe size of 64k. We enable stack clash protection ourselves and use the default 4k probes although it's really meant to be 64k on 64-bit ARM in the ABI, but too many things use 4k themselves so 4k is the safe value. We still want a 64k guard.
-
@toke @adfichter That resulted in having a PROT_NONE page called anon:stack_and_tls:main page in /proc/self/maps followed by the area with pthread_internal_t, thread-local storage and libgen buffers. The anti-tampering checks and obfuscation done by these apps is doing something with that data and it crashes trying to access the guard. It's a nice example of how horrific these checks are. We've had a lot of problems caused by them which have certain security improvements into a hassle.
@GrapheneOS @adfichter ugh, that sounds horrible indeed! But good to know that this is on your radar; I'll keep an eye on the release notes and retry the Mobile Pay app from time to time. And thanks for explaining the details, very interesting! -
@GrapheneOS @adfichter ugh, that sounds horrible indeed! But good to know that this is on your radar; I'll keep an eye on the release notes and retry the Mobile Pay app from time to time. And thanks for explaining the details, very interesting!
@toke @adfichter We also could have fixed compatibility with the guard page change we made in our most recent release by changing the name of guard part of the mapping. We were actually giving it a separate name but Android started naming the whole stack in 1 place at the end instead of naming the components of it separately which was overwriting our name. We dropped our code setting separate names for today's release too. Nothing should be inspecting and accessing memory that way though...
-
@toke @adfichter We also could have fixed compatibility with the guard page change we made in our most recent release by changing the name of guard part of the mapping. We were actually giving it a separate name but Android started naming the whole stack in 1 place at the end instead of naming the components of it separately which was overwriting our name. We dropped our code setting separate names for today's release too. Nothing should be inspecting and accessing memory that way though...
@toke @adfichter Their code does all kinds of stuff like this depending on internal memory layout details of Bionic. It shows why us making important security improvements which are entirely correct and compatible with correct code can cause problems. There's no way an app should be messing with the internal libc pthread_internal_t struct and thread-local storage. It's ridiculous. It means adding or reordering fields would likely break it too. These apps often break with major Android releases.
-
@toke @adfichter Their code does all kinds of stuff like this depending on internal memory layout details of Bionic. It shows why us making important security improvements which are entirely correct and compatible with correct code can cause problems. There's no way an app should be messing with the internal libc pthread_internal_t struct and thread-local storage. It's ridiculous. It means adding or reordering fields would likely break it too. These apps often break with major Android releases.
@toke @adfichter It's very common for these banking and government apps to stop working with a new major Android release. They start getting a trickle of negative reviews about it with the Developer Preview and Beta releases which build up into a regular stream of negative reviews until they're flooded with them after it's a stable release. They sometimes only deal with it weeks after a stable major release of Android. We just have to work around this stuff ourselves as they won't care.
-
@toke @adfichter It's very common for these banking and government apps to stop working with a new major Android release. They start getting a trickle of negative reviews about it with the Developer Preview and Beta releases which build up into a regular stream of negative reviews until they're flooded with them after it's a stable release. They sometimes only deal with it weeks after a stable major release of Android. We just have to work around this stuff ourselves as they won't care.
@GrapheneOS @adfichter yup, the national ID app breaking on an OS version update makes the news on a regular basis here. It's really terrible, and there doesn't seem to be a way to get through to the people responsible in a way that they will listen to. Really sad to see security theatre win out this way. -
@GrapheneOS @adfichter yup, the national ID app breaking on an OS version update makes the news on a regular basis here. It's really terrible, and there doesn't seem to be a way to get through to the people responsible in a way that they will listen to. Really sad to see security theatre win out this way.
@toke @adfichter We're doing our best to work around the horribly incorrect code in these apps but it's difficult to deal with all of it.
People often wrongly blame the Play Integrity API even though we show a user-facing notification for that to end users. We regularly have requests to add more apps to our Play Integrity API list at https://grapheneos.org/articles/attestation-compatibility-guide even though it's not the problem.
It's hard to get reliable reports to figure out which apps have these issues and then hard to deal with.
-
@toke @adfichter We're doing our best to work around the horribly incorrect code in these apps but it's difficult to deal with all of it.
People often wrongly blame the Play Integrity API even though we show a user-facing notification for that to end users. We regularly have requests to add more apps to our Play Integrity API list at https://grapheneos.org/articles/attestation-compatibility-guide even though it's not the problem.
It's hard to get reliable reports to figure out which apps have these issues and then hard to deal with.
@toke @adfichter The apps are often region locked on the Play Store which can make it a pain to even obtain them for testing. We often can't trigger the checks because we lack a way to make an account and log into it. The apps are typically extremely obfuscated and doing all kinds of horrific things depending on internal OS implementation details including the layout of libc structs and much more. It's often difficult to determine what the apps are doing wrong and how we could work around it.
-
@toke @adfichter The apps are often region locked on the Play Store which can make it a pain to even obtain them for testing. We often can't trigger the checks because we lack a way to make an account and log into it. The apps are typically extremely obfuscated and doing all kinds of horrific things depending on internal OS implementation details including the layout of libc structs and much more. It's often difficult to determine what the apps are doing wrong and how we could work around it.
@toke @adfichter We've spent an enormous amount of time dealing with this stuff instead of working on improving privacy and security. Adding low-level hardening features for userspace is heavily held back by this since we need to retain near perfect compatibility with horribly written apps doing all kinds of incorrect things. It has substantially slowed down progress on GrapheneOS. Many features have had to be deferred and we have to put a lot of time into resolving rare compatibility issues.
-
@toke @adfichter We've spent an enormous amount of time dealing with this stuff instead of working on improving privacy and security. Adding low-level hardening features for userspace is heavily held back by this since we need to retain near perfect compatibility with horribly written apps doing all kinds of incorrect things. It has substantially slowed down progress on GrapheneOS. Many features have had to be deferred and we have to put a lot of time into resolving rare compatibility issues.
@toke @adfichter We haven't flipped the switch on enabling memory tagging by default for user installed apps since it uncovers an enormous number of memory corruption bugs. That's why that's an opt-in toggle in Settings > Security > Exploit protection instead of the default with reliance on per-app opt-out to deal with it. Memory tagging at least makes nice reports clearly showing it was caught by memory tagging. We could potentially put this into the setup wizard to explain it there.
-
@toke @adfichter We've spent an enormous amount of time dealing with this stuff instead of working on improving privacy and security. Adding low-level hardening features for userspace is heavily held back by this since we need to retain near perfect compatibility with horribly written apps doing all kinds of incorrect things. It has substantially slowed down progress on GrapheneOS. Many features have had to be deferred and we have to put a lot of time into resolving rare compatibility issues.
@GrapheneOS @toke @adfichter it's amazing google even allows this stuff (weird obfuscated security-theatre protection bullshit) in the play store if it constantly breaks on major android version updates
