Mac & i: What about the WebKit rendering engine, do they keep that one up-to-date in Safari?
CM: I think they do okay with this. Consider the problems with having your browser based on WebKit. Other projects, like Chrome and Android are using it. So when a bug is reported to the WebKit developers, ideally, the open source project, Chrome, Android, Safari, Mobile Safari would all push patches the same day. Of course this never happens. So for example, when a WebKit bug is patched in OS X, it is probably sitting in Mobile Safari until the next iPhone update comes along, or vice versa. If they don't patch OS X and iPhone in unison, which they don't, as well as with other open source projects, there are usually known bugs in the browsers.
DDZ: It is a similar situation to the Linux distributions and the Linux kernel "vanilla" source. All development occurs on the open source project (including security fixes), and the commercial projects pull from that as appropriate for their release schedule. Commercial projects are concerned about support and stability, so they can't have the level of code churn that the open source projects have.
Mac & i: ...but still, this dependence on the WebKit project gives attackers some days to weeks to exploit potentially critical vulnerabilities in Safari, doesn't it?
CM: Using WebKit isn't bad in itself. Apple just needs to release patches for it as they become available in the open source repository. So far, they haven't been able to do this consistently, or at least haven't cared to do so.
DDZ: That is true. The WebKit project tries to keep the security fixes under wraps until they are released, but inevitably Chrome, Safari, iOS, and whoever else uses WebKit will not have a synchronised security update schedule. Chrome tends to lead the pack, so Safari and iOS will inevitably trail behind somewhat. From the beginning, Chrome built the capability for seamless and frequent updates into the browser, so they can push out updates very easily. It is likely an order of magnitude harder to push out a Safari update and likely an order of magnitude harder to push out an iOS update. In both software and network engineering, it is wise to build in a way that facilitates frequent updates from the very beginning.
Mac & i: Apple launched its Mac App Store in January. Do you think this will boost security? Developers will have to sign their applications, I suppose.
CM: Well, it may provide some malware protection for end users. This isn't really a problem but could become one. Having a central location for applications that is monitored in some way by Apple makes it harder for malware authors to get their code out if users start only using the Mac App Store for downloads.
DDZ: So far, the largest malware threats to Mac users have been through trojan horses in downloaded (usually pirated) software or web sites that tricked users into installing malicious video codecs. Improving the authenticity of 3rd party software on the Mac and making it easier to download authentic software will have a definite security benefit. Also, since the code signing used by iOS also exists in Mac OS X, signed 3rd party software may allow Apple to enable code signing enforcement in Mac OS X. Code signing enforcement is the single most effective security defense technology on iOS.
Mac & i: Will OS X 10.7, Lion, solve some of the shortcomings of Snow Leopard, like those of ASLR and DEP you mentioned? Will there be other known security benefits?
CM: That's the million dollar question to which only Apple knows the answer. We'll all have to wait like everyone else to see. I hope so!
DDZ: Since Apple has a strict NDA on their pre-release operating systems, I make sure to stay away from them so that I don't mess up and leak my knowledge of an upcoming feature :). My security feature wishlist for Lion would be real ASLR and iOS-like code signing enforcement.
(Since this interview took place, Apple has invited Miller and Dai Zovi to examine the security of Mac OS X 10.7)