đĄ So sieht die Agov Access App bei mir aus, die man in der Schweiz fĂŒr digitale BehördengĂ€nge braucht.
-
@rolandlo @adfichter @GrapheneOS Das war bei mir dieselbe Erfahrung, FIDO2-Stick lief entgegen der Erwartung einwandfrei und ohne Zusatzaufwand unter Linux und wird nÀchstes Jahr zur SteuererklÀrung wieder rausgekramt. Es kann aber trotzdem nicht sein, dass eine Àltere AGOV-Version unter GrapheneOS funktioniert, aber neuere nicht mehr.
@datacyclist @rolandlo @adfichter It's caused by incorrect anti-tampering checks and can be worked around by disabling an important security feature added by GrapheneOS (secure app spawning), which we don't recommend. It's possible to use this app on GrapheneOS already but we plan to come up with a built-in workaround which avoids needing to turn off secure spawning. See https://grapheneos.social/@GrapheneOS/116528377935838679.
FIDO2 and passkeys work well on GrapheneOS so you should also be able to use that approach on it.
-
@adfichter @GrapheneOS die AGOV Access App mit LineageOS gar nicht erst versucht
â
ïžAber zumindest mit Linux und einem FIDO2-SchlĂŒssel erfolgreich, mit viel Durchhaltewillen und Identifikation am Schalter (strikte Reihenfolge der Etappen zu beachten!)
https://help.agov.ch/index.php?c=register&l=de-> diese Anleitung muss definitiv verstÀndlicher und mit den Anleitungen der Kantone harmonisiert werden!
@chrispy It's caused by incorrect anti-tampering checks and can be worked around by disabling an important security feature added by GrapheneOS (secure app spawning), which we don't recommend. It's possible to use this app on GrapheneOS already but we plan to come up with a built-in workaround which avoids needing to turn off secure spawning. See https://grapheneos.social/@GrapheneOS/116528377935838679.
FIDO2 and passkeys work well on GrapheneOS so you should also be able to use that approach on it.
-
@adfichter @GrapheneOS Bei der 2FA App Futurae die gleiche Meldung. Auf einem GrapheneOS Handy ohne Google Dienste kommt die Meldung das die Google Dienste nicht vorhanden sind, die App scheint aber zu funktionieren. Auf einem GrapheneOS Handy mit Google Dienste aktiviert kommt die Meldung dass das Handy gerootet ist scheint aber auch zu funktionieren. TWINT(prepaid) z.B. meldet auch bei jedem Start das die GDienste fehlen, funktioniert aber problemlos.
@DasPom @adfichter GrapheneOS displays a notice if apps use the Play Integrity API and supports blocking using it to work around apps which ban a result showing it's not a stock Google Mobile Services OS but permit not successfully providing a result.
AGOV app has an incorrect anti-tampering check which detects our secure spawning. It's possible to disable that but we don't recommend it. We're going to fix it by eliminating the differences it detects. See https://grapheneos.social/@GrapheneOS/116528377935838679 for details.
-
@unaegeli @jonasgraphie @f @adfichter @GrapheneOS
Mich warnt die UBS-App, dass sie bald nicht mehr funktionieren wird auf meinem GrapheneOS mit gelocktem Bootloader.
Ohjee. Habe selber noch nichts derartiges erlebt.
-
@unaegeli @jonasgraphie @f @adfichter @GrapheneOS
Mich warnt die UBS-App, dass sie bald nicht mehr funktionieren wird auf meinem GrapheneOS mit gelocktem Bootloader.
@stgl AGOV is detecting our secure spawning feature and can be used on GrapheneOS with it disabled. It's an important security feature and doesn't currently have a per-app toggle so we don't recommend disabling it. We've already shipped an improvement hiding the main difference between secure spawning and standard Android Zygote spawning by making the Java call stack match due to misguided anti-tampering checks. We have changes planned to address other cases.
See https://grapheneos.social/@GrapheneOS/116528377935838679.
-
@adfichter The anti-tampering checks done by these are inherently insecure and most are incorrect which leads to compatibility issues with future Android versions, GrapheneOS and even OEM Android forks. The reason we had to adjust the initial call stack for secure spawning to match the standard one is because some apps insecurely try to detect tampering via method hooking by checking the call stack. We can make a similar change for their low-level checks of the data in certain memory blocks too.
@GrapheneOS @adfichter that would be amazing. The Danish MobilePay app (dk.danskebank.mobilepay) also refuses to work on GrapheneOS, and it sounds like it's for the same reason. At least I don't get any notification about the app trying to use the Integrity API, it just says "device modified" after running for a while. I guess maybe it's just caching the state after initial launch and bugging out if it changes? -
@GrapheneOS @adfichter that would be amazing. The Danish MobilePay app (dk.danskebank.mobilepay) also refuses to work on GrapheneOS, and it sounds like it's for the same reason. At least I don't get any notification about the app trying to use the Integrity API, it just says "device modified" after running for a while. I guess maybe it's just caching the state after initial launch and bugging out if it changes?
@toke @adfichter Standard Android spawning uses fork from the Zygote with a bunch of stuff preloaded to share more memory. This breaks ASLR and other probabilistic protections since it's all shared between the Zygote process, system_server, user installed apps and many system components implemented with app_process. Android implements a large portion of userspace with app processes. It's most of the high level base OS. Some are in the regular app sandbox while others are more privileged.
-
@toke @adfichter Standard Android spawning uses fork from the Zygote with a bunch of stuff preloaded to share more memory. This breaks ASLR and other probabilistic protections since it's all shared between the Zygote process, system_server, user installed apps and many system components implemented with app_process. Android implements a large portion of userspace with app processes. It's most of the high level base OS. Some are in the regular app sandbox while others are more privileged.
@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.
-
@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...
