Post B61kraWUmSiOsSbRNg by GrapheneOS@grapheneos.social
(DIR) More posts by GrapheneOS@grapheneos.social
(DIR) Post #B61kpQvLV0yMWjCOVk by adfichter@infosec.exchange
0 likes, 0 repeats
😡 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;))
(DIR) Post #B61kpREqKWZJVCJxtw by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@adfichter 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.
(DIR) Post #B61kpRVVKZtcKs7Gs4 by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61kpRicXoO6zYFkJc by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@adfichter Our secure spawning feature was never expected to cause any compatibility issues. We aren't aware of any legitimate compatibility issues as opposed to apps doing incorrect anti-tampering checks which make incorrect assumptions about non-stable OS implementation details. Due to these incorrect checks, these apps frequently break with new major Android OS releases. They often don't address it during Android's Developer Preview or Beta testing but rather weeks after the Stable release.
(DIR) Post #B61kpUmd9MNUUr9UTw by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@adfichter Various banking apps used to ban GrapheneOS because the secure spawning feature had a different initial Java call stack. We addressed this by making the call stack match for secure spawning which fixed most of the compatibility issues. There are still minor differences which are possible for apps to detect if they're checking implementation details such as low-level system properties, the address space layout or how much is initially preloaded. We plan to work around all of that too.
(DIR) Post #B61kpVkXYcIfUfBKrY by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@adfichter For now, you can disable secure spawning if you need to use this app on GrapheneOS. Turning it off disables it for every system process implemented with app_process including system_server and various privileged components such as the main Bluetooth process. We could provide a more granular way to disable it. We didn't anticipate anti-tampering checks causing compatibility issues and the toggle was only added as a way to test memory usage and app spawning time without it enabled.
(DIR) Post #B61kpWqFUsScserPOq by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krYHB8RH5uNQBEG by toke@social.kernel.org
0 likes, 0 repeats
@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?
(DIR) Post #B61krYR6XXDMPA46hU by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krYeDklhr3qCa92 by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krYnRCV4xWQVwVk by toke@social.kernel.org
0 likes, 0 repeats
@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 :)
(DIR) Post #B61krYxiaHIo2JK9XE by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krZ5s5xpARb8fFA by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krZGVSQKaya79ou by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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...
(DIR) Post #B61krZSuiIFvb3v49w by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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 overflowsWe fixed it for today's release.
(DIR) Post #B61krZgjstJaHwO6i0 by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krZpbLwP6jQXBWS by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krZySozUdAugGKu by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61kra7KI2a9cOpL9M by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61kraFpmPO62mo8PY by toke@social.kernel.org
0 likes, 0 repeats
@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!
(DIR) Post #B61kraOhFSTcUGxDE0 by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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...
(DIR) Post #B61kraWUmSiOsSbRNg by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61kraiu2KdjUwPLii by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61krar3Y1A5uEDrQe by toke@social.kernel.org
0 likes, 0 repeats
@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.
(DIR) Post #B61krb0GzkXCMoXDnM by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61ktQSBBr02E5SbTs by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61ktQhmFrTb0Sl3nE by GrapheneOS@grapheneos.social
0 likes, 0 repeats
@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.
(DIR) Post #B61ktQynEb5TrEieJc by Rairii@labyrinth.zone
0 likes, 0 repeats
@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
(DIR) Post #B62BsMIvpROppYqnI0 by engideer@tech.lgbt
1 likes, 0 repeats
@Rairii @GrapheneOS @adfichter @toke In general; doing shit like checking the memory layout of libc structs should be an instant ban criteria in the PlayStore. That's basically malware territory