Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 13 Jun 2018 21:05:36 +0530
From: Lets Secure <>
Subject: Third Party Code Signing Vulnerability in Squirrel & Sparkle

Based on the recent disclosure at

The Squirrel
 framework also doesn't perform strict validation to check nested
architecture and revocations & validity of the signer cert and can
essentially result in bypassing the code sign validations.

result = SecStaticCodeCheckValidityWithErrors(staticCode,
kSecCSCheckAllArchitectures, (__bridge SecRequirementRef)self.requirement,

SecStaticCodeCheckValidityWithErros is called without flags -
| kSecCSCheckNestedCode | kSecCSCheckAllArchitectures |

Also, it lacks checks for chain of trust across nested binaries in Fat
i.e. missing this code:
SecRequirementCreateWithString(CFSTR("anchor apple"), kSecCSDefaultFlags,

SecCSFlags flags = (SecCSFlags) (kSecCSDefaultFlags |
result = SecStaticCodeCheckValidityWithErrors(staticCode, flags, NULL,

The flags should have been set with:
SecCSFlags flags = (SecCSFlags) (kSecCSDefaultFlags | kSecCSCheckNestedCode
| kSecCSCheckAllArchitectures | kSecCSEnforceRevocationChecks)

But, that's not the case with Sparkle.

Best Regards!

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.