Hacker News Reader

Comment by timbre | Hacker News Reader

I'm surprised you can sign an executable, then modify it while preserving the validity of the signature, as I always though this is exactly what code signing is meant to prevent. Can anyone who knows more about this than me (a low bar!) explain whether this is a flaw in the signing mechanism or is actually okay?

View on HN

Neat. Just tried downloading an installer and figured out that it's using the unauthenticatedAttributes structure of the Authenticode signature.

These attributes are not part of the signedAttributes which is used to actually authenticate the signature. A quick dump of the asn.1 structure of the authenticode signature block from my installer shows that right after the timestamp extension is a new object with a private OID (presumably assigned to dropbox for this purpose) that includes a unique string.

6519 11: OBJECT IDENTIFIER '1 3 6 1 4 1 42921 1 2 1' 6532 1049: SET { 6536 1045: UTF8String : 'Dropbox-Installer-Id:DBPREAUTH::msie::xxxx..........................................'

Interesting hack, kudos!

From the article: "Our custom tool allows us to create an unverified section of the binary in a way that is compliant with the Authenticode spec. We make the tag buffer an unverified section so that the tag buffer can change without having to re-sign the binary."

So they sign 90% of the executable, but 10% of it is unsigned.

More importantly, what good is a code-signed executable when that executable can simply download a payload from the internet like this Dropbox installer does? Code signing seems like a feel-good mechanism for users. Yeah, we guarantee that the executable that you downloaded was signed by a legitimate entity but once you run it, good luck. This type of "meta installer" seems ripe for exploitation. Unscrupulous entities create a legit signed app that later downloads a malicious payload; legitimate distributors might also find themselves to be the target of attackers who want to alter that downloadable payload.

I think the point of code signing is to ensure that the program was really written by Dropbox, so _if_ you trust Dropbox you should trust the program. That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

>That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

Only a fool would, after their actions of the past year, still believe this company has good intentions or that their payload system hasn't already been totally compromised (with their cooperation, no less).

Signing doesn't imply you are "legit", at least not much - it requires ID verification but in the absence of any hard rules about what's acceptable that's only useful in the most egregious cases, and anyway you can still run unsigned binaries.

Signing is mostly useful to help reduce anti-virus false positives. AV systems learn binary reputations just like spam filters do. It doesn't matter if the app goes off and downloads another program for this purpose - that's an implementation detail that doesn't impact whether the app is malicious or not.

Reply on news.ycombinator.com