This W3C MiniApp format sounds a lot like JAR signatures, aka APK v1 signatures. Although not an ideal format, it is at least well understood and explored.
As for some background on why APK v2/v3 signatures have this spot to stick data in the signing block, the Android team developed a scheme for app stores to sign all APKs that they ship. Then devices can have the public key for the app store built into the device, and there can be requirements that all installed APKs are also signed by this external key. This extra signature goes into this data space in the APK signature, if I am not mistaken. It has to be external to the signed content because at the time it was implemented, Google Play did not have the sources nor the ability to sign APKs with the developers' keys.
It is funny because APK v2 was developed because JAR/APKv1 allowed too much flexibility to add stuff outside of the signature (e.g. the whole META-INF/ directory). But then I guess they realized that they needed some way to add external data after all.
I'd love to see a blog post/article version of this conversation somewhere. I think we'd be happy to have it on f-droid.org.
.hc Marc Prud'hommeaux via rb-general:
I recently noticed a similar vulnerability in the W3C MiniApp packaging draft, whereby they embed signatures for the individual zip entries in the (legal) padding between the final entry and the zip's central directory[1]. This seems clever, but it means that only the individual entries, and not the entire artifact, can ever be verified. So any additional data/text/code that might be squirreled away in the inter-zip-entry padding is unverifiable by the signatures. But this vulnerability would be difficult to take advantage of in any practical sense, since the miniapp/webapp host first expands the zip and runs the app from the extracted folder, throwing away the original .zip packaging artifact in the process. And so any hidden information in the artifact would be inaccessible to the program that it contained. But in the context of an Android app, where it sounds like it has runtime access to the original .apk artifact and signing data, this could have more serious implications. How much space is available for abuse in the signing block? Could you embed an entire additional .apk in there? –Marc [1] https://w3c.github.io/miniapp-packaging/#sec-miniapp-digital-signature-requirementsOn Jan 30, 2023, at 23:46, FC Stegerman <f...@obfusk.net> wrote: Hi! We already know that embedded signatures [1] pose a challenge for reproducible builds. And it's not too hard to imagine a program detecting which key it's signed with and changing its behaviour based on that; which I think is inherently unavoidable. But the Android APK Signature Scheme v2/v3 [2] actually allows embedding arbitrary data (or code) in the signing block, meaning that two APKs with the exact same valid signature -- though not a bit-by-bit identical signing block -- can behave differently. I have written about my concerns [3] before, but now I've finally made a PoC [4] for an Android app that reads the APK Signing block of its own APK and extracts a payload to alter its behaviour. Whether the payload is present or not does not affect the validity of the signature. Thus we get two APKs -- with an identical valid v1+v2+v3 signature -- but one says "nothing to see here..." when you run it, whereas the other says e.g. "This is the payload". - FC [1] https://reproducible-builds.org/docs/embedded-signatures/ [2] https://source.android.com/docs/security/features/apksigning [3] https://gitlab.com/fdroid/fdroidserver/-/issues/1056 [4] https://github.com/obfusk/sigblock-code-poc
-- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556
