hiding data/code in Android APK embedded signatures

FC Stegerman flx at obfusk.net
Wed Feb 1 19:07:01 UTC 2023


* "David A. Wheeler" <dwheeler at dwheeler.com> [2023-02-01 17:20]:
> > Agreed.  And I often wish Android had used detached signatures.  Though
> > detached signatures would have made distributing APKs more challenging:
> > a single file is much more convenient for end users.
> 
> Sure, but the solution is trivial.
> 
> Create something that you want signed ("item A").
> Sign it as many times as you want ("item signature-of-A-1, signature-of-A-2, etc.").
> Now wrap them up in another archive ("archive of item A, signature-of-A-1,
> signature-of-A-2, etc.").
> 
> Now you have a "convenient single file download", where the signatures
> can be trivially used & checked. But, since the "item being signed" is
> clearly separable *without* having to understand the details of its format,
> it's easy to add new signatures, ensure that the signatures are valid,
> reproduce the item being signed, and so on.

Unfortunately, you've left out the details of the archive format here,
when they are actually quite important.

You now need to unpack an archive (e.g. a .zip or .tar) before you can
verify the signature, leaving you potentially vulnerable to any
vulnerabilities (e.g. symlink, path traversal, zip bomb) in your
zip/tar implementation, before you have a chance to verify that the
signed thing came from a trusted source.

> If you have to understand the nuances of the ELF or PE format to determine
> if a signature is valid, you've already failed.

Agreed.  But I would argue you have already failed when you need to
rely on the security of (your system's implementation of) the ZIP or
TAR format before you can even determine if a signature is valid as
well.

This is not an unsolvable problem, but I don't think we can rely on
just any form of "another archive" here.  IMO it must be an extremely
simple and easily auditable format without any unnecessary features
and complexity -- not simply a common one like ZIP or TAR -- to be
considered suitable for this use case.

- FC


More information about the rb-general mailing list