hiding data/code in Android APK embedded signatures

David A. Wheeler dwheeler at dwheeler.com
Wed Feb 1 19:48:15 UTC 2023



> On Feb 1, 2023, at 2:07 PM, FC Stegerman <flx at obfusk.net> wrote:
> 
> * "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.

That's true any time you want to download a *single* file that contains
both signatures and the thing being signed.

One solution is to not bundle them at all, which is fine by me. Any proposed
article should stress that.

However, many people *do* want to bundle the signatures and the things
being signed into a single downloadable unit. In that case, we have 2 choices:

1. Use a normal archive format. To me this is the better option.
 Unarchiving programs must *already* have mechanisms
that counter such attacks. Also, downloads typically already verify
the distributing origin (using https),
reducing the risks that the archive have such obvious direct attacks.

2. "Hide" the signatures into many different complex formats like ELF or PE,
and then figure out how to extract them. These other formats are typically
as complex as archive formats, you have to write code for every different
format, *and* the tools designed to exact data from them
typically assume that they are *not* under attack.

I think choice 1 is the better choice if you're going to combine them into 1 download.


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

From a security POV, I agree that having a *separate* download of
the signature(s) would be better, as long as they're actually downloaded and
verified. If you provide the signatures, AND they are downloaded
and checked, then problem solved.

However, those are less convenient. People downloading manually usually
down't download & check signatures. Even if it's automated, it's easy for those writing
the tools to skip the signature verification (because they have to take extra
steps to get the signatures), and thus there's a risk to not verifying signatures.

Since many people *WILL* demand that there be a single downloadable
file that includes signatures, it'd better to explain how to do it in a way
that's less vulnerable.

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

I don't know of any existing widely-used archive format with these properties.
In practice, everyone uses ZIP or TAR. I can only start with the current state.
I doubt a new archive format would get a lot of traction
(but I'd be happy to be proven wrong).

--- David A. Wheeler



More information about the rb-general mailing list