hiding data/code in Android APK embedded signatures

[FC Stegerman]

* Hans-Christoph Steiner <hans at guardianproject.info> [2023-02-03 07:58]:
> This W3C MiniApp format sounds a lot like JAR signatures, aka APK v1
> signatures.  Although not an ideal format, it is at least well understood
> and explored.

Actually, "between the final entry and the zip's central directory" is
exactly where the APK Signing Block is as well.  So it sounds more
like a v2/v3 signature in that respect.

Though it sounds like it doesn't contain a signature for all the bytes
in the ZIP (apart from the signature itself), but individual
signatures for the files, which is indeed how v1 signatures work.

> As for some background on why APK v2/v3 signatures have this spot to stick
> data in the signing block, the Android team developed a scheme for app
> stores to sign all APKs that they ship.  Then devices can have the public
> key for the app store built into the device, and there can be requirements
> that all installed APKs are also signed by this external key.   This extra
> signature goes into this data space in the APK signature, if I am not
> mistaken.  It has to be external to the signed content because at the time
> it was implemented, Google Play did not have the sources nor the ability to
> sign APKs with the developers' keys.

That explains why there is some space.  Not why there is this much
space, with zero constraints on what can be put in there.

I do understand the need to leave room for new signature schemes (like
the later v3 and v3.1), so I understand not being able to completely
lock down what can be put in there.  But now you can just put anything
in there.

In fact, I just put the entire F-Droid APK into the verity padding
block of another APK; apksigner says it's still verified.

> It is funny because APK v2 was developed because JAR/APKv1 allowed too much
> flexibility to add stuff outside of the signature (e.g. the whole META-INF/
> directory).  But then I guess they realized that they needed some way to add
> external data after all.

Despite all the

  WARNING: META-INF/some/file not protected by signature. Unauthorized
  modifications to this JAR entry will not be detected. Delete or move
  the entry outside of META-INF/.

warnings that apksigner produces, those files are in fact always
listed in the .MF and .SF and thus covered by the v1 signature in my
experience (e.g. when I implemented v1 verification and signing for
apksigtool).

But the v1 signature doesn't cover the space between entries or their
metadata, leaving plenty of space to hide things.

- FC