Apple ARM binary codesign issue

[Jeffrey Walton]

On Tue, Sep 22, 2020 at 6:24 PM Ken Cunningham
<ken.cunningham.webuse at gmail.com> wrote:
> ...
> I'm trying to imagine how Jeremy might prevent hackers from surreptitiously modifying signed binaries with strip or install_name_tool (which is good) while letting people modify signed binaries with strip or install_name_tool without invalidating the signature  -- I don't immediately see how you can have it both ways. But maybe Jeremy has some trick that works for this I can't think of.

I have not looked at Apple signing in a while, so take this with a
grain of salt...

Apple should be signing assets and resources in the bundle, and not
just the binary. That's called "semantic authentication". See David
Wagner and Bruce Schneier's "Analysis of the SSL 3.0 Protocol" (c.
1996).

Lack of semantic authentication is what Android bug 8219321 was all
about, a.k.a Bluebox's "master key" bug or the "one key to rule them
all." Android patched the 8219321 bug in 2013.

If you modify the binary or assets in the bundle, you should have to
resign the bundle. I don't think there's anything inherently insecure
about (re)signing a bundle after modification. Or nothing comes to
mind (for me).

The standard caveats apply, like the codesign tool should make an
insignificant modification before signing, like adding a whitespace to
an XML file or text file. And codesign tool should calculate the
digest itself, and not sign a precomputed digest. Never trust someone
else's hash. Calculate the hash yourself.

Jeff