đĄ So sieht die Agov Access App bei mir aus, die man in der Schweiz fĂŒr digitale BehördengĂ€nge braucht.
-
@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 -
So sieht die Agov Access App bei mir aus, die man in der Schweiz fĂŒr digitale BehördengĂ€nge braucht. Und ja, es macht mich hĂ€ssig...Gestern an der interessanten Konferenz TRANSFORM zu Digital Public Infrastructure haben Bundeskanzlei, BAG-Vertreter:innen betont wie wichtig es sei, dass der Staat wie bei der Eisenbahn eine digitale hoheitliche Infrastruktur schafft (auch wenn sie von Privaten gebaut wird).
Digital ist das natĂŒrlich etwas schwieriger zu ĂŒbersetzen, wegen Datenhaltung, Hardware, Software und technologischen AbhĂ€ngigkeiten. Dennoch: der Big Tech-Zwang bei der Agov Access App ist eine absolute Frechheit. Nur fĂŒr iOs und Android.
Zwar gelobt die Bundeskanzlei Besserung und will diese verfĂŒgbar machen fĂŒr alternative Betriebssysteme. Ob die eID am 1.12.2026 fĂŒr Nicht-iOS/Nicht-Android-Usern zur VerfĂŒgung stehen wird, das steht noch in den Sternen.
Es kann nicht sein dass man von digitaler öffentlicher Infrastruktur redet, jedoch alle Einwohner:innen dieses Landes nötigt das Big Tech-Duopol (von den man sich ja ironischerweise allgemein emanzipieren will) zu installieren.
@GrapheneOS One more app to add for your "Wall of Shame".
Mein Text dazu folgt am Montag.
(morgen kommt was zu Ăberwachung und VĂPF 2.0, kleiner Teaser;))
@adfichter @GrapheneOS I reached out to the agency providing the solution and to my surprise I got a nice reply that they acknowledge the need to support GrapheneOS and that they added it to the backlog of the company developing the app! They couldn't commit to a timeline, however.
Feel free to DM me if you want more details. -
@adfichter @GrapheneOS I reached out to the agency providing the solution and to my surprise I got a nice reply that they acknowledge the need to support GrapheneOS and that they added it to the backlog of the company developing the app! They couldn't commit to a timeline, however.
Feel free to DM me if you want more details.@ridedontslide @adfichter We can likely work around the issue ourselves. We know it's caused by the app being incompatible with our secure spawning feature and we already know the main issue with these anti-tampering SDKs which is causing compatibility issues. We need to figure out how to work around it. There's a high chance working around the issue we know about will solve it. It's possible to disable secure spawning to use the app but we don't recommend that.
GrapheneOS (@GrapheneOS@grapheneos.social)
@adfichter@infosec.exchange This app works on GrapheneOS with the exploit protection compatibility mode disabled and secure spawning disabled. The app does incorrect anti-tampering checks which are incompatible with our secure spawning feature due to it causing small differences in the address space and properties checked by their anti-tampering. The exploit protection compatibility mode has to force enable secure spawning to disable hardened_malloc and the 48-bit address space so it has to be disabled.
GrapheneOS Mastodon (grapheneos.social)
-
@adfichter Disabling secure spawning reverts to the standard Android Zygote-based spawning model where apps start as clones of the Zygote address space and memory. The Zygote spawning model reduces security by sharing the same state for probabilistic exploit protections including hardware memory tagging (MTE), ASLR, heap canaries, heap randomization and more. Android has a workaround to avoid weakening the security of stack canaries (SSP) but the rest can't really be worked around for it.
@GrapheneOS thanks a lot for all the answers. I will wait for the new version which should work on GrapheneOS. What are the risks by disable secure spawning?
-
R relay@relay.infosec.exchange shared this topic
