hiding data/code in Android APK embedded signatures

[Marc Prud'hommeaux]

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-requirements


> On Jan 30, 2023, at 23:46, FC Stegerman <flx at 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
>