Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: code signing and security flaws

On Jul 17, 2008, at 3:23 PM, Nathan Herring wrote: 
On 7/17/08 3:14 PM, "Damien Sorresso" <email@hidden> wrote:

On Jul 17, 2008, at 1:41 PM, Nathan Herring wrote: 
You _could_ revoke the certificate associated with v1, so that
unless the users also frustrated CRL/OSCP operation, Mac OS X would
not trust the code signing certificate.


This is not the problem code signing is meant to solve. Code signing
will only answer the question "Have these bits been modified since
being signed?" Or more conceptually, code signing assigns a
verifiable, provable identity to a piece of code. That's it.


I concur. I had hoped that the underscores around "could" would have
indicated that I did not especially like that idea.

You also asked "Is this a _good_ thing to do?" Granted I forgot to quote that part, but the answer is an emphatic "No". If you were asking rhetorically, I didn't realize.

Users should *never* correlate trust of a signature with known
security vulnerabilities. And you, as a developer, should not
encourage such an expectation, since it raises a bunch of problems
(which you enumerate in your e-mail), has nothing to do with the
identity of the code and imbues a false sense of security.

You should not revoke a certificate for reasons unrelated to the
security of the certificate itself or the identity of your
organization. If the certificate has not been compromised or you're
not changing CAs or something along those lines, there's no reason to
revoke the certificate.

Fair enough, but you did not respond to the idea of using OCSP extensions to
report good certs with extra extension data that happens to contain
vulnerability-related information.

For context, I'll quote your original paragraph dealing with using OCSP extensions.

Will code signing (or the related attributes & processes) be used to handle these cases across the OS? E.g., an extension to OCSP that, while the certificate still looks "good", the associated code has vulnerabilities. (This is to distinguish someone who hacked ExampleApp v1 vs. that the true ExampleApp v1 has a problem.)


If I'm understanding your proposal correctly, the answer to that should be implicit in my reply. Don't correlate certificate status with the presence of known vulnerabilities.

Once you tag a certificate with vulnerability information, you have to start signing future code with another certificate, because you don't want to sign future versions with certificate tagged with "Hey, you're vulnerable!" And this process will go on and on so long as you keep discovering vulnerabilities. For software with at least one discovered vulnerability per released version, you'd essentially be turning the code's identity into the certificate *itself* rather than something that is *derived from* the certificate. Conceptually, this is a mis- application of code signing certificates.

And while using OCSP to communicate vulnerability information isn't revoking a certificate in the most explicit sense, that is effectively what you're doing. And by doing that, you're tying certificate status to security vulnerabilities.

Your issue is best addressed by a software update mechanism like
Sparkle or a custom-rolled one (it's not that hard to do).

I disagree. Most applications don't force the user to run the software
update mechanism and report whether the update patches security flaws in the
currently running application, and really, by then it may be too late. If
you've had your machine off for six months, and ExampleApp runs as a startup
item, you can be p4ned before you even have a chance to update. If the
system were to validate your code signature and by-the-by gathered
information about your vulnerabilities, it could prohibit or ask the user to
opt-in or even ignore the vulnerability report by OS policy.


Again, this is not the problem code signing or OCSP is supposed to solve. It's tempting to piggy-back it onto the code signing subsystem as a matter of convenience, but that's the wrong approach for reasons I've covered.

Your issue fundamentally deals with deployment of security patches. There are better ways to implement a system like this in your apps. For example, you could have the app or daemon query a server with its version number as part of its initialization (which, if your app is signed, will be reliable) and ask "Should I let the user use me, or did you guys find a security problem?" If it gets back a "No" or cannot connect, do the cautious thing and exit with as helpful an error message as you like.

It's true that such a system would break down if there's a vulnerability in the code that does the check, but again, it's not something that code signing can help you with. Code signing doesn't provide any useful information to input into such a system beyond "This code's signature is valid" or "This code's signature is broken".

I'm not trying to say that this issue doesn't exist or that it's not a problem. I just think you're looking for a solution in the wrong place. A more appropriate solution may be having LaunchServices check for updates on behalf of each application that opts in before exec(2)ing it. The developer could specify keys and comparisons to make (such as "Update if the 'HasVulnerabilities' key from the server is TRUE") in a property list somewhere. It could be as flexible or rigid as needed.

In any case, if you like that idea, I'd file a Radar. If you do, please post the number. :)
--
Damien Sorresso
Mac OS X Update Integration
Apple Inc.
email@hidden

Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/apple-cdsa/email@hidden

This email sent to email@hidden
References: 
 >Re: code signing and security flaws (From: Nathan Herring <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.