Apple Software Security…Thinking Different

By Patrick Toomey

Last year Charlie Miller presented some fuzzing results on OS X, including fuzzing PDF files through OS X’s Preview application. Out of 2.8 million PDF files Preview crashed approximately 160,000 times. Obviously one can’t state anything categorical about the exploitability of these, but it does speak to a general code quality issue within Apple. Similarly, the security community has rightfully chastised Apple for their implementation of ASLR, DEP, etc. These stories, along with those of recent OS X specific malware, have gotten a fair bit of attention in the security community, with most everyone agreeing that Apple is going to have to do better. However, should we have really expected anything different?  As with any software company Apple has their priorities and apparently they didn’t think cleanly handling arbitrarily fuzzed PDF files and ASLR were going to sell more Macs. Microsoft took the same approach (prioritizing features/user experience over security) for many years before they were forced to swallow a big heaping spoonful of medicine. It could even be argued that taking the opposite approach (valuing security over user convenience/experience) isn’t the right answer either. That is not to say that the reason Linux never took off on the desktop is because they were too focused on security. But, Linux has often placed a high degree of value on the technical underpinnings of the platform rather than rallying behind user experience (this is obviously changing a bit with the likes of Canonical). The take away is that each of these platforms has a target audience and none of them are doing anything altruistic and/or evil, they are simply each catering to a different market.

So, with the upcoming release of Mac OS X Lion, I got to thinking about where Apple is going from a security perspective.  With many companies you can easily predict what they will do because you can just point to the five things that other people are doing better, and the obvious next step is for them to do those things better as well.  But, that isn’t generally Apple’s style.  Years ago Apple had their “Think Different” campaign. While obviously marketing speak, there is an air of truth to it. Apple has never been afraid of doing things differently, running the risk of upsetting users, breaking backward compatibility, or violating common wisdom. Sometimes this way of thinking works out well for them and other times it is pure hubris and doesn’t pan out. But, I do believe they don’t make decisions lightly. As such, as much as many security people think Apple is simply blasé about security, I actually think they have had a strategy for some time now and it is definitely different than the rest.

One of the main roadblocks I’ve seen in the software security space is that very often the advice that is given out is “do better”. While contemporary protections like ASLR, DEP, etc have upped the ante of successful exploitation, it isn’t as if they are a cure all. So, in the end, we still advise developers to do better. All of the above mentioned protections take the perspective of trying to prevent memory corruption from letting an attacker execute code in the context of the user. But, what if an attacker does get code executing in the context of the user? Windows, Linux, and even Apple have thought about this issue as well, and each has their own approach. Linux has SELinux, AppArmor, and other such Linux security modules that let a developer get extremely fine grained with regard to the permissions set available to a given process. Windows has a similar idea with their “low integrity” process model as well as misc things you can do with “access tokens”, “securable objects”, etc.  And then we have Apple, who developed a model very similar to AppArmor called Seatbelt (though it hasn’t historically been widely used or exposed to developers). So, what’s the issue, these all seem like pretty good ideas, so why isn’t everyone using them?  Well, it’s all about the marketing.

So, what do I mean by marketing? I am mostly definitely not talking about a Mac vs. PC style campaign where Mac touts the benefits of Seatbelt over Windows’ approach to using process integrity.  No, I am speaking more of the marketing around selling their solution to developers.  Historically the only people incentivized to use these extra protections were developers that really wanted to do better. As an example, Chrome obviously has in incentive to do better, as one of their core tenants is around security. They want to be known as the secure browser, and as a result, they have gone through non-trivial effort to create a security architecture for their browser that is second to none. But, what is the incentive for the average developer to go through this much effort/bother?  Similar arguments can be made on the Linux side of the house, as there is really very little incentive for the average developer to care about and subsequently bother with these mechanisms, as security is very likely not going to be the thing that makes or breaks a project’s success.  However, from Apple’s perspective, over time if developer’s simply fail to do better, then it is Apple’s brand that is watered down.  So, what is Apple doing?  They are doing it their own way.

Sure, Apple will probably improve their ASLR as well as improve a number of other current deficiencies so that they eventually measure up to the likes of Microsoft and Linux (hopefully this is all coming in Lion).  But, that is all table stakes at this point.  What is Apple going to do that is inherently different than either Microsoft or Linux?  For, that we only need to look at the App Store model.  Apple found a goldmine in marketshare/mindshare with the iOS App Store. When Apple first released their iOS App Store much of the tech community rejected the idea of such a closed platform. However, as time has shown, there is a huge percentage of the population that is 100% OK with such a platform and there are benefits to such a platform from a security perspective. All iOS applications are jailed ala Seatbelt, preventing one application from touching any other application’s data. Also, each application passes through Apple as the gatekeeper. So, if/when an application is found to be doing something suspicious Apple has the capability to pull the App from users’ phones. Sure, there are parts of this that sound way too Orwellian, but there is absolutely value in this model for a large subset of users.

If we look at the growth of the iOS App Store you will notice one very important thing. Apple never told developers  to secure their applications. No, instead they presented developers with a proposition. They basically offered developers the following: If you are willing to trade off a bit of flexibility in your application, we will mange much of the marketing and distribution for your application. Essentially, if you were willing to make a few concessions, you might walk away with a decent paycheck. So, what were those concessions? Well, you can’t write an application that requires root, you can’t read/write to arbitrary locations on the filesystem, you can’t use undocumented and/or private APIs, you must let apple review your application to ensure you haven’t violated any of these concessions, as well as a few others rules.  The net result is that apple marketed their way to a more secure platform (it was a win for developers wanting to make money and it was a win for users who wanted a great user experience to buy applications)

So, what does this have to do with the Mac? Well, Apple released the Mac App Store not long ago. Just as with the iOS App Store, there are some concessions developers must make if they want to make it in the store. These concessions are very similar to those in the iOS App Store. The next version of OS X touts “application sandboxing” as a new feature (probably based off of Seatbelt). I nearly guarantee that in order for an application to make it into the Mac App Store it is going to have to be built in such a way it could be sandboxed (i.e. no root, no low-level filesystem access, etc). So, again, Apple is creating an incentive for doing better without having to idly sit by the sidelines hoping that developers do better all by themselves.  While not a mind-blowing concept, it is different.  This is what Apple is all about; they pull together some reasonably good piece of technology, though it is likely not revolutionary, and then play to their core strength…selling the idea to their customer.  In this case they created a product that is enticing to both developers and users, with the result being a great user experience, and one that just happens to have the nice side effect of helping developers do better.

One thought on “Apple Software Security…Thinking Different

  1. Hey Patrick, thakns again for an awesome post and your insight. I do agree with you – totally.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s