hiding data/code in Android APK embedded signatures

[David A. Wheeler]

I recommend that the reproducible-builds website have a short article
*specifically* recommending how signatures, OmniBOR data, & similar metadata should be shared.

In short, do *NOT* embed such data (especially signatures) in complex formats like ELF or PE.
Instead, create an archive with the "item being signed" combined with the signatures
and similar metadata. That way, the combined data can be sent as one unit
(making it easy to transmit), but then the metadata like signatures can be easily
separate *without* needing to know/process complex specialized formats like ELF or PE.

OmniBOR data isn't quite so bad, but there's a trade-off.
Embedding OmniBOR data in the executable risks making
it harder to reproduce the results, because very small changes that wouldn't normally
change the final results *will* now change the final results if the OmniBOR data
is embedded in the item being built reproducibly.

Then refer people to that article's URL, so people can start steering the ship that way.

At least one person I've talked to claims that reproducible builds are a security vulnerability,
because he assumes that signatures must be embedded within executables.
That's wrong, but making it clear to others why it's wrong would be helpful.

Is there agreement on adding such a page?

--- David A. Wheeler

> On Feb 1, 2023, at 12:12 PM, Marc Prud'hommeaux via rb-general <rb-general at lists.reproducible-builds.org> wrote:
> 
> 
> 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
>> 
> 
>