hiding data/code in Android APK embedded signatures

Wed Feb 1 20:30:35 UTC 2023

On Wed, Feb 01, 2023 at 02:48:15PM -0500, David A. Wheeler wrote:
> 
> 
> > 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.

There is another factor to consider here: utility of the artifact
besides signature check process. And also note that "verify after
download" isn't the only use case. If you use an archive, you _must_
extract that archive before using the thing, regardless of what that is.
If that artifact is relatively big (ISO image?) that may be problematic.
Or at least teach the application to understand yet another format
directly (a file wrapped in an archive).
Since you mentioned PE, consider SecureBoot example. That signature is
relevant if you have SecureBoot enabled. Having a single binary you can
use with or without SecureBoot is much more convenient for (almost?) all
parties involved. This includes tools that handle bootloader
configuration, tools that build such binary, various user instructions
and habits (you don't need two separate processes for "archive with a
signature" and "plain executable"). Those issues apply to both "wrap
original file and a signature in an archive" and "ship detached
signature separately".

You could ask why not wrapping a file in an archive always, regardless
of signature presence, and use that as a file format. But that still
requires unwrapping that file before use, at least for tool that do not
(need to) care about signature - especially already existing tools/use
cases.

So, while embedding a signature into various formats is inconvenient for
reproducible builds and requires custom tools for few other use cases,
there are also a lot of advantages of this approach.

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

Yes, when designing new format, making it easy to sign (maybe by
starting with "archive including the file and a signature") is a good
idea. Maybe even try to have some standard how to do so - so you could
use a single tool to sign/verify different formats. But I don't think
it's feasible/desirable to use it with already established formats.

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

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20230201/2966cca6/attachment.sig>