So what are we securing? One of the big things is data, information, things like credentials, usernames and passwords to websites or other applications or assets on an internal network somewhere. Also privacy. Personal information is very important to keep confidential. Things like real names, email addresses, or geographical location.

It's also important to protect financial information, which is very attractive to an attacker, as well as business information that might belong to a user. Now, the second category of assets refers to things that are intrinsic to a device or a system. The resources. Things like its network access. The bandwidth that a machine has. Or its unique IP address. And these are things that are valuable for botnet activities such as click fraud or sending spam.

Now, attackers are also interested in new devices and their new capabilities. In the '90s when everybody had dial-up modems, you had auto dialers. And as you might have seen in the news, they might be making a comeback on some insecure platforms. Next, attackers might be interested in very large scale attacks, harnessing the computational ability of millions of machines or their storage potential.

So how do attackers work? How do they get into systems? Throughout this presentation, I've categorized the different attack vectors into four different parts. And for each of these, I'll describe the vulnerabilities and the defenses that you can take advantage of. The first is the user interface. What are the paradigms and what are the symbols that users are used to that an attacker can use to trick a user into performing an action against their own interest? What programming errors exist in an application? From the fine print of the CPU instruction set to the high level design of the application.

What errors allow an attacker to take advantage of a program to compromise a user's assets? How is information stored on a system? What happens to this information if that portable device is lost or stolen or resold? And how is information transmitted by your application across the internet? Now, just as there are many ways to write a program and there are many ways to make a program secure, there are very many ways to make errors. And some of these errors translate to security flaws.

Here are some examples. These are vulnerabilities that are not specific to a particular application or a platform. These are generic attacks that we see across the software industry. The user interface level. You have things like Trojan horses. from the mythology of the Trojan War. But in this case, it might be a file that seems innocent but might actually try to compromise a user's system.

Things like phishing attacks on email and spoofing attacks where legitimate applications and websites are impersonated. And the user interface should be friendly, but it should also be secure to defend against these kinds of attacks. For code, you have things like logic flaws, input sanitization errors, and memory mismanagement errors, such as buffer overflows, or calling a function pointer on a stale object.

For storage security vulnerabilities, the physical loss of a device could represent the complete loss of all that information. So what can technology do to make sure that that information is still safe even when their user is no longer in the physical possession of their information? For transport, how is information being transmitted securely? You might be using encryption, but is it secure? Who are you encrypting your data to? Who is receiving it? So let's start talking about some of the defenses that I'm going to cover today.

So for the user interface, on Mac OS, you might already be familiar with quarantine. I'll describe that. And also talk a little bit about authorization and some of the improvements we've made there. The code level. We're doing all kinds of things to make exploitation much more difficult as well as improving our tools to remove low hanging fruit where possible. We also provide sandboxing for damage control.

For storage, we have strong Unix file permissions. And we also have technologies such as key chain, file vault, and data protection to solve some of the most difficult problems with secure data storage. And last, I'll talk about some of the great new things that we're doing for transport security and some of the great innovations that have made their way into Lion and iOS 5.

To put things into context for you, I have two mockups of some applications, an RSS reader and a financial application. The RSS reader will be used to demonstrate some of the flaws at the UI level and the code category of vulnerabilities. Whereas the financial application has some different security needs that lend well to storage and transport security.

So consider an RSS reader. It seems pretty harmless. Doesn't have any passwords. Doesn't necessarily deal with any personal information. In an ideal world, it wouldn't have any security vulnerabilities because it is not a secure application. doesn't offer security. That's not the case at all. An RSS reader actually presents a very rich attack surface because it has support for things like HTML5 and all the rich media that comes along with it. Movie files and movie decoders and audio decoders and image parsers and all kinds of technologies that are now within reach and triggerable. And it's network enabled, so it's receiving untrusted input from unknown sites.

So this is how an attacker might actually see the RSS reader. They're going to look at the entry points. They're going to look at the application itself and the technologies it builds on. And attackers are going to look for vulnerabilities in the complex interactions between these systems. So, Atom feeds have support for enclosures. And enclosures are part of the specification and they provide for downloading media. Arbitrary files that are stored to a file system.

So files are especially important when considering user interface and a secure user interface. What kind of files can come in? Are there on-site file types? The RSS reader also has a URI handler so that when a user clicks a link, they can immediately bring up this application and it's convenient. But it introduces additional surface for URI parsing vulnerabilities. As well as the feeds themselves, which likely come over HTTP. So any attacker on the network could inject data there. But in addition, RSS feeds aggregate data from many different places. So the HTML code in there is untrusted.

So let's talk a little about user interface attacks. The Trojan horse. What do we do to prevent Trojan horse attacks? There are two technologies, or there are many technologies, but two of them that I'll talk about today are quarantine and authorization. And consider an enclosure that delivers a PDF file. It looks like this.

Many of you have beautiful icons, but this attacker wasn't very creative and they decided to just reuse the icon for PDF files. But it's actually not a PDF. It's a .app. The extension is not shown. So when a user clicks on on this file. They expect preview to open up and display their contents.

But it could actually be a Trojan horse. And quarantine solves this problem by displaying an alert. It shows the exact information for where that file came from and at what time. Quarantine is easy to take advantage of. All you need to do is enable the setting in your Info.plist and automatically you will get some attributes. Your application's name and the bundle ID as well as the time.

And then manually you can set this information. The exact data URL that it came from and the site that it originated from. As well as the type of file it is. Launch services will take care of the rest. When an unsafe file type such as a .app or shell script is downloaded, quarantine will block these kinds of attacks.

Next we have authorization prompts. And this might be a little confusing to you at first because what is the difference between an administrator user and an application running as an admin user? To the system, we have a root user that has full control over the system. And in many places where a core system change is made, such as editing a firewall rule or installing new system-wide applications or services or a kernel driver. The operating system prompts the user for administrator authorization with a password.

And in Lion, we've improved these. We've eliminated many of them where they were unnecessary. This is to prevent users from getting too used to typing in their password unnecessarily. And we've also simplified them and clarified their purpose. All right. So now let's shift gears and talk about code vulnerabilities.

So the URI handler and the feeds actually represent a very wide attack surface and they can trigger many components and many technologies where they can look for parsing errors and all sorts of vulnerabilities. They can look for input validation problems. Such as taking a file name from the URI handler and taking that URI and passing it on the command line and securely. An attacker might try to inject shell meta characters to start executing arbitrary commands.

This could be triggered from An arbitrary website. Or they might look for memory mismanagement errors. For example, one of the image decoders that can be triggered from HTML might have a buffer overflow vulnerability in it. Also going to look for logic flaws. How does the RSS reader interact with the operating system and with things like spotlight? And what oversights did the programmer make or the development team make when building their application? So here's a simple vulnerability. This is a format string flaw. Suppose that the URI handler is taking this information and passing it directly to the NS log API function. This is directly exploitable. An attacker can take advantage of this by giving their own format string specifier.

And luckily this problem is easy to fix. You just add your own format string and don't allow untrusted input as the format string specifier. So an attacker could use the format string vulnerability to disclose arbitrary memory. or gain direct code execution. But not all bugs are this easy to fix or that easy to find.

So what I'll be talking about today are some asymmetric solutions to the problem. You don't have to match your attackers step by step. You don't have to find every vulnerability they might find. You can take advantage of the code hardening mechanisms we have, the exploit mitigation technology we have. That makes exploitation much more difficult.

You can take advantage of the sandboxing features we have for damage control. Let's talk about the Clang static analyzer. There are other sessions this week. What you see with Xcode 4 is even better integration. The Clang static analyzer will automatically find many memory mismanagement errors for you. Thereby also eliminating a good portion of security errors.

Our compiler takes advantage of the open source Fortify source patch. And Fortify source removes really low hanging fruit that is too easy to find. Things like insecure calls to string copy. That does not do bound checking. The way Fortify Source works is that during compilation, I just replaced with more secure alternatives. The compiler can do this automatically where it's easy to do so.

Next, we have stack protectors. And stack protectors are also inserted by the compiler through a transformation pass in LLVM. And the stack protectors make exploiting buffer overflows more difficult by inserting a secret value on the stack that protects the return address and the save frame pointer from being overwritten. Next, we have a number of new exploit mitigation technologies. So sometimes code injection can be really easy. All an attacker has to do is figure out a way to get their data somewhere in executable memory.

For a long time we've had a non-executable stack, but on 32-bit processes in Snow Leopard, we've had an executable heap and an executable data section. This made it easy for an attacker to exploit 32-bit applications. Whereas on 64-bit applications on Mac OS, these were non-executable. So an attacker could not easily inject code here.

As well on iOS, the code signing policy. Make sure that that is not executable. So it's also more difficult for an attacker. And in Lion, we've made this better. Now data in the heap are no longer executable. So an attacker cannot inject code easily. Not every security solution is perfect and this can still be bypassed with return oriented programming.

Return oriented programming is all about reusing existing code that's already in the address space of the program for performing arbitrary actions. And return oriented programming specifically refers to reusing the epilogues of functions to perform arbitrary computations. But you could also just reuse existing libraries and existing API calls. Here you have an example of one of the first iPhone exploits that took advantage of vulnerability in TIFF that was discovered by Tyvus Ormandy.

And although you had no way to inject code, you could just build up stack frames that reuse the existing API calls to perform actions. One way to mitigate this is address based layout randomization. What you will see across our platforms is that we have address based layout randomization. This was introduced in iOS 4.3. It is in line. This makes remote exploitation more difficult for an attacker. They don't know where the data structures are. They don't know where their input is. They don't know which functions to call. without an information leak.

So to get these features on, all you have to do is build online. It's not an SDK setting. It doesn't matter which APIs you're building for. Just the toolkits that are online, I mean the tool chain, will take care of this. The linker adds headers to the Mac OS header in the binary.

That sets these settings. So now when you build online, 32-bit applications by default will be built as position-independent executables so they can get address-based layout randomization. It's also true for non-executable data. You also get some additional heap hardening and the stack protectors. And if you want, you can enable stack protectors for all functions, not just character buffers, functions with character buffers, by passing the fstackprotector all flag.

So if you want to check to see if you're not sure if you're getting this feature, you can do so using O tool. And you can check the macro header using this and you want to look for the pie flag. And that's it. You have address-based layout randomization.

So let's talk about sandboxing. So sandboxing is a very powerful construct for damage control. So if an attacker is able to find an exploit and get code running in an application, you can provide damage control so that they can't break out into other applications or get users' data.

And you see this on iOS, where a compromise on an application doesn't necessarily compromise all the user's data and other applications. And you saw this on Leopard with Seatbelt. And we have a number of built-in profiles there. So you could put your application in a sandbox and remove its ability to access the Internet.

So you could run code from arbitrary places, not worry about its ability to connect out. Or you could use the pure computation sandbox, which is really tight. So an application in the sandbox can't touch the user's files, can't talk to the network, can't talk to IOCAD or other resources.

But we made this even better. And in Lion, we're introducing the App Sandbox. The app's sandbox is designed for security, but it's also easy to take advantage of. It's also been designed to really work with users to give them a clear idea of how their data is flowing through the system and going in between applications. So that they can feel safer when using your applications. In addition, we provide fine-grained access control with entitlements that allow you to specify exactly what resources your application should have.

There are two sessions today in this room. This is a two-part session actually and it's at 2:00 p.m. The first part will be the introduction to the app sandbox. The second part will be about the app sandbox and the Mac App Store. You can learn about the new requirements for your applications. So let me tell you a little bit more about sandboxing.

The concept is that if an attack comes in and compromises your application, not all of the resources that that application could have access to previously are immediately compromised. You can isolate your application from the system to prevent the compromise of all these other components, the user's files, network access, communication with drivers.

You can even take this a step further. You can build your application in such a way that has privilege separation and the more security critical components, the ones that deal with users' data and users' files, are isolated from the more vulnerable components that have to do a lot of file parsing and a lot of data parsing and work with a lot of untrusted input. And you can even isolate these from the network components.

So the app sandbox provides great damage control by limiting the effect of an attack on the user system. We also have entitlements. And entitlements, if you're familiar with them from iOS, Are things that you add to your application. Online? There's a new spin on them. So all these capabilities that your application should have are off by default and default deny is a great concept in security. You want to give your application the minimal set of privileges that it needs to get its job done. So if there's a compromise, all the potential resources that it could compromise are not also accessible.

So you opt in and you pick the capabilities that you want. And here are just some examples of The types of entitlements that are out there. Things like making a connection to another machine Writing to users download folder where they might store a lot of their new files and new data.

Things like a user-initiated read. So when a user decides to give your application a file, they can just use the file dialogs. You don't necessarily have to give your application full access to all of the user's files. Just the files that they want to give your application at that time. Things like accessing the camera or accessing printers.

All right, now let's shift gears and talk about the financial application, which has a very different set of problems. Financial application has credentials for a bank account somewhere or some sort of server. And also deals with very sensitive information that needs to transfer and store securely. So let's talk about some storage vulnerabilities. Again, things like physical theft. If a device is misplaced, lost, or stolen, that user might be anxious about what happened to all that stuff that they had on there.

On the desktop, things like file permissions. Is the user's data being protected from other users on the system if it's a shared portable, for example? Back to the financial application. The attacker is going to be interested in things like user names and passwords to that bank account or those bank statements. Any information they can get about the person.

The attacker is not going to go around hunting for users of your application. But They're going to be looking for this kind of information on a device they get. So what do we have? So we have strong Unix file permissions. I'll talk about that a little bit later. And we have technologies like Keychain, FileVault, and Data Protection.

Keychain solves a lot of problems with password management. How should passwords be migrated across an install? On the desktop, Keychain can protect a user's login items, their user names, their emails, their passwords with one password. It makes it easier for a user to manage all of their different credentials. Keychain is also available on iOS.

In Panther, we introduced FileVault which allowed users to encrypt their data in an encrypted volume. This only applied to their home directory. So in Lion, we have the all new file vault which provides full disk encryption. So the full volume is encrypted. So other things like system messages and global configuration settings or the applications they have installed can now also be secured by a user's password in case their portable is lost.

On iOS we have data protection. So data protection mitigates other vulnerabilities on the passcode lock. So if a device is stolen and the user has a passcode set, that protects their data. But in case there's a vulnerability that can compromise that, data protection takes everything a step further and protects the files on that device using the user's passcode and the lock state of that device. And there are a few different protection classes. And data protection was introduced in iOS 4. We made some improvements there.

So by default, there's nothing. And you should avoid this. In the first protection class is NS file protection complete. And you want to always use this when you're dealing with personal information. The way it works is that whenever a device is passcode locked, data in this protection class is not accessible. as well as keychain entries that are in this data protection class. They're only accessible when the user enters their passcode and they're actively using their device.

This alludes to some new stuff. We'll get to it in a second. And then we have this data protection class that was available for the keychain after first unlock. Many of the vulnerabilities that are out there for a passcode bypass rely on rebooting the device. So this protection class, Is a solution for applications that might need to function even out of passcode lock but still need data protection.

After the first time a user enters their passcode, data in this protection class will be available. But not until then. Here are some use cases for data protection. You should be using this anywhere where a user might put their personal information. Anywhere where you might have a scratch pad, where a user might decide to store a password, even temporarily.

It should be in this protection class. To prevent any information leaks, as well as information from social networking websites. In addition, you should be taking advantage of key chain. Anywhere where you're working with credentials, user names and passwords and e-mail addresses. You should be putting them in the tightest protection class you can.

We have two new protection classes available in iOS 5. These are meant to solve some of the trickier points with background applications. The first of these is complete unless open. The way it works is you put your file in this protection class and you will be able to access it until you close the file handle. This is useful if you need to complete a large transaction such as a large mail download.

And when you close the file handle, this will get moved into the NSProtectionComplete class. The next one we have is after first unlock as well for files. And this is useful for streaming services and notifications. These are really the use cases. They're intended for background applications. And for the most part, you should be using protection complete.

Next, let's talk about file permissions. So, temporary directories are especially tricky on a multiuser system. You have to be very careful and watch out for things like race conditions. Opening a file, doing a stat, or doing a stat and then opening a file is not secure. In between that stat and that open, an attacker could have switched something out.

In addition, you have to be very careful with file permissions. When you leave global configuration settings on a system, you want to make sure that they're not world writable and that they're in the appropriate

So another thing that you'll notice in Lion is that we've tied in file system permissions. So /, /applications/utilities, and /library are no longer writable by the group admin.

This was done to tighten some potential vulnerabilities that were being created by some third party installers where global configuration settings or system daemons were being installed into these places and then running with full root system privileges. And this created the potential for privilege escalation from the admin group ID to root. And there are some exceptions. Any role directories that are already there remain the same as well as caches.

So let's talk about the other side of this financial application. Transport. It needs to securely transmit information to a server and securely retrieve information. Here are some of the goals of transport security. You want to make sure that that data cannot be observed by a passive attacker. You don't want to send plain text credentials as well as any personal information playing over the wire.

You also want to make sure that your protocol is resistant against more active attacks, such as man-in-the-middle attacks, where somebody might be impersonating the server that your client thinks is talking to or vice versa. and protocols have all kinds of nuances on them. Additional things such as replay attacks. Many of these problems are solved for you by many of the APIs available in security framework. And on Mac OS X secure transport. These are integrated in the core system APIs.

So CF Network supports HTTPS as well as NSURL open. In Mac OS X and Lion we have some great innovations here with transforms. So transforms are a new way of doing data flow programming. And these were created as a result of improvements to our crypto APIs on Lion. There's been a convergence between iOS and Mac OS X and some of the common crypto subsystems are now available. And the APIs to access them take advantage of transforms. And it makes it easier, faster, and with less code to do secure cryptography and secure transport correctly. In addition, some data structures have been affected.

In iOS 5, we've introduced secure transport, which was previously only available on Mac OS X. So before it was difficult to do secure transport with transports layer security with TLS over an arbitrary protocol that wasn't HTTP. So you had to rely on things like CF network and NSUR open to use HTTPS. But in some ways that was limited. Now you can take advantage of secure transport on iOS 5 and it has full support for TLS 1.1, TLS 1.2, and DTLS for diagrams, for UDP.

So for user interface security, make sure you take advantage of quarantine on the desktop. Because user interface attacks are in some ways the easiest and lowest bar for an attacker, but they're also some of the most complex problems to solve. But you can make it difficult for an attacker to take advantage of these things with quarantine. We have a number of code hardening mechanisms as well as exploit mitigation technologies built in now into Lion and iOS that you can take advantage of.

Sandbox. The app provides excellent solutions to some of the hardest computer security problems we solve. Of giving a user full control over how their data interacts with different applications on their system. and providing an easy way to build security under the hood. In addition, we have good technology that solves some very difficult storage problems such as what happens to information in the case of data loss, physical theft, as well as API such as keychain. And users can take advantage of file vault. So they don't have to worry about their information on their portable if they lose their laptop. We have data protection for protecting files on portable devices.

And for transport security, we have some great new APIs available online, as well as iOS 5 now. So you can do secure communication without compromising users' information. Here are some references that you can check out the website. You have a secure coding overview and introduction. Secure coding practices as well as references for working with quarantine. And here are the sessions that you should really see for some of the in-depth topics on the things I've mentioned today. The app sandbox sessions will tell you in great detail how the sandbox works and how you can take advantage of it. Thank you.