Hacker News Reader

Comment by nailer | Hacker News Reader

I've heard the same for Windows code signing certs - that's it possible to modify the payload and have the signature still apply.

View on HN

In the Authenticode spec, there is an unauthenticatedAttrbutes structure, the contents of which does not affect the resulting signature.

Dropbox’s installer used it a while ago (maybe still, haven’t checked): https://news.ycombinator.com/item?id=8204454

https://news.ycombinator.com/item?id=8203164

> These attributes are not part of the signedAttributes which is used to actually authenticate the signature

https://learn.microsoft.com/en-us/archive/blogs/ieinternals/...

> unverified data within the PKCS #7 blob itself which will not be taken into account when verifying the Authenticode signature

There's also the padding vulnerability CVE-2013-3900 that still isn't mitigated by default.

Sounds like a useful feature to me.

I mean, aside from bypassing the whole point of having them.

There are plenty of use cases. Like having your code signed, but putting a license key or access tokens or endpoint URLs into the unsigned part. That way you can sign binaries with your heavily guarded key, but still have some web server give people individualized binaries that don't have to ask for information (better UX if you install it once, or a big deal for software meant to be rolled out across many machines).

Of course software can abuse it by loading code from the unsigned portion, but that requires code in the signed portion to be complicit. In that case the signature still does its job of telling you exactly who was responsible for that fuck-up.

We do this where I work, and we HEAVILY verify all information that comes in from the unsigned/unauthenticated parts of the code. Not only types checks, but regex checks, and other validations. And if there's something there that shouldn't be there our program will kill itself. We don't even show any error prompts or anything just incase.

Reply on news.ycombinator.com