On Tue, Sep 22, 2020 at 6:24 PM Ken Cunningham <ken.cunningham.web...@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