Wrong confirmation ID

Email
Favorite
Favorited ×
Download
Embed
Private Content
Copy and paste this code into your blog or website Copy Customize… Close
We have emailed the verification/download link to "".
Login to your email and click the link to download the file directly.

To request the link at a different email address, update it here. Close
Validation messages. Success message. Fail message.

Check your bulk/spam folders if you can't find our mail.

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

+ Follow

Designing a Secure Cocoa App

by Graham Lee on Jul 08, 2009

1,395 views

A presentation I delivered to NSConference 2009, on security principles for Cocoa developers to follow.

More…

A presentation I delivered to NSConference 2009, on security principles for Cocoa developers to follow.

Less

2 Embeds 25

http://coderwall.com	21
http://www.slideshare.net	4

Statistics

Favorites: 0
Downloads: 22
Comments: 0
Embed Views: 25
Views on SlideShare: 1,370
Total Views: 1,395

The goal of this presentation is to give you an idea of how security experts think about designing security into applications. A few examples of Mac OS X technologies will be used to indicate how these principles can be applied in real applications. Finally, we’ll look at an example of a vulnerability in an app, so that we can apply the ideas we’ve learned.
Why should I want to talk about security, and why should you want to listen? The press and security researchers like talking about insecure Macs. They don’t care whether the holes are in our apps or in Apple’s; come to that, neither do our customers. If my app is less secure than the competitor’s then that’s a reason to choose the competition; just like UI fit and finish, usability or performance.
First, remember that security is not a one-size-fits-all operation. Something which works in one context may not be appropriate elsewhere.
Questions to ask are of risk: what could go wrong, how likely is it and what would the impact be? Can I live with that? How much am I (or my customers) willing to pay to reduce that risk?
My “Pythagoras theorem”, i.e. my fundamental rule of software security is to think of it like real-world security. Securing an office building by locking _everyone_ out would stop burglars getting in, but it would stop the workers getting in too. Ultimately the user has to be confident that they can get their work done without untoward problems, just as good real-world security provides assurance that law-abiders can go about their business.
So if we want to identify and mitigate threats which pose a risk to our app, we need to know what a threat is. We want to know _who_ is doing something which compromises our app, _what_ they get by doing it (or, conversely, what we lose), and _how_ they get in and acquire that asset.
So if we want to identify and mitigate threats which pose a risk to our app, we need to know what a threat is. We want to know _who_ is doing something which compromises our app, _what_ they get by doing it (or, conversely, what we lose), and _how_ they get in and acquire that asset.
So if we want to identify and mitigate threats which pose a risk to our app, we need to know what a threat is. We want to know _who_ is doing something which compromises our app, _what_ they get by doing it (or, conversely, what we lose), and _how_ they get in and acquire that asset.
So if we want to identify and mitigate threats which pose a risk to our app, we need to know what a threat is. We want to know _who_ is doing something which compromises our app, _what_ they get by doing it (or, conversely, what we lose), and _how_ they get in and acquire that asset.
So if we want to identify and mitigate threats which pose a risk to our app, we need to know what a threat is. We want to know _who_ is doing something which compromises our app, _what_ they get by doing it (or, conversely, what we lose), and _how_ they get in and acquire that asset.
Could be a malicious person, could be someone accidentally exploiting a problem, such as misconfiguring their own application. That’s why I used the term “misuser” instead of “abuser”. They could be known to the customer/user or you or not. Each attacker will have different characteristics.
Example: CanSecWest held the pwn2own competition, where competitors were encouraged to compromise various computers in order to win that computer as a prize. In that arena, the attacker is motivated by personal gain, there is little to no chance of recrimination so they’re likely to take huge risks and it’s also probable that they’d be security experts. That’s quite an edge case though.
Could be a malicious person, could be someone accidentally exploiting a problem, such as misconfiguring their own application. That’s why I used the term “misuser” instead of “abuser”. They could be known to the customer/user or you or not. Each attacker will have different characteristics.
Example: CanSecWest held the pwn2own competition, where competitors were encouraged to compromise various computers in order to win that computer as a prize. In that arena, the attacker is motivated by personal gain, there is little to no chance of recrimination so they’re likely to take huge risks and it’s also probable that they’d be security experts. That’s quite an edge case though.
Could be a malicious person, could be someone accidentally exploiting a problem, such as misconfiguring their own application. That’s why I used the term “misuser” instead of “abuser”. They could be known to the customer/user or you or not. Each attacker will have different characteristics.
Example: CanSecWest held the pwn2own competition, where competitors were encouraged to compromise various computers in order to win that computer as a prize. In that arena, the attacker is motivated by personal gain, there is little to no chance of recrimination so they’re likely to take huge risks and it’s also probable that they’d be security experts. That’s quite an edge case though.
Could be a malicious person, could be someone accidentally exploiting a problem, such as misconfiguring their own application. That’s why I used the term “misuser” instead of “abuser”. They could be known to the customer/user or you or not. Each attacker will have different characteristics.
Example: CanSecWest held the pwn2own competition, where competitors were encouraged to compromise various computers in order to win that computer as a prize. In that arena, the attacker is motivated by personal gain, there is little to no chance of recrimination so they’re likely to take huge risks and it’s also probable that they’d be security experts. That’s quite an edge case though.
Could be a malicious person, could be someone accidentally exploiting a problem, such as misconfiguring their own application. That’s why I used the term “misuser” instead of “abuser”. They could be known to the customer/user or you or not. Each attacker will have different characteristics.
Example: CanSecWest held the pwn2own competition, where competitors were encouraged to compromise various computers in order to win that computer as a prize. In that arena, the attacker is motivated by personal gain, there is little to no chance of recrimination so they’re likely to take huge risks and it’s also probable that they’d be security experts. That’s quite an edge case though.
Could be a malicious person, could be someone accidentally exploiting a problem, such as misconfiguring their own application. That’s why I used the term “misuser” instead of “abuser”. They could be known to the customer/user or you or not. Each attacker will have different characteristics.
Example: CanSecWest held the pwn2own competition, where competitors were encouraged to compromise various computers in order to win that computer as a prize. In that arena, the attacker is motivated by personal gain, there is little to no chance of recrimination so they’re likely to take huge risks and it’s also probable that they’d be security experts. That’s quite an edge case though.
The assets in an application can be tangible data held by the app, such as a password, a user’s identity or some information of financial value. Alternatively they can be intangible; there’s no file on the Sophos webserver which actually contains the company’s reputation, but the reputation could still be damaged by a successful attack on the webserver content.
The asset at risk could also be something which the app has access to but doesn’t actually “own”, such as the network connectivity or CPU time which are often the targets of zombie networks.
The assets in an application can be tangible data held by the app, such as a password, a user’s identity or some information of financial value. Alternatively they can be intangible; there’s no file on the Sophos webserver which actually contains the company’s reputation, but the reputation could still be damaged by a successful attack on the webserver content.
The asset at risk could also be something which the app has access to but doesn’t actually “own”, such as the network connectivity or CPU time which are often the targets of zombie networks.
The assets in an application can be tangible data held by the app, such as a password, a user’s identity or some information of financial value. Alternatively they can be intangible; there’s no file on the Sophos webserver which actually contains the company’s reputation, but the reputation could still be damaged by a successful attack on the webserver content.
The asset at risk could also be something which the app has access to but doesn’t actually “own”, such as the network connectivity or CPU time which are often the targets of zombie networks.
The assets in an application can be tangible data held by the app, such as a password, a user’s identity or some information of financial value. Alternatively they can be intangible; there’s no file on the Sophos webserver which actually contains the company’s reputation, but the reputation could still be damaged by a successful attack on the webserver content.
The asset at risk could also be something which the app has access to but doesn’t actually “own”, such as the network connectivity or CPU time which are often the targets of zombie networks.
The assets in an application can be tangible data held by the app, such as a password, a user’s identity or some information of financial value. Alternatively they can be intangible; there’s no file on the Sophos webserver which actually contains the company’s reputation, but the reputation could still be damaged by a successful attack on the webserver content.
The asset at risk could also be something which the app has access to but doesn’t actually “own”, such as the network connectivity or CPU time which are often the targets of zombie networks.
The assets in an application can be tangible data held by the app, such as a password, a user’s identity or some information of financial value. Alternatively they can be intangible; there’s no file on the Sophos webserver which actually contains the company’s reputation, but the reputation could still be damaged by a successful attack on the webserver content.
The asset at risk could also be something which the app has access to but doesn’t actually “own”, such as the network connectivity or CPU time which are often the targets of zombie networks.
So we can classify the importance of assets - and thus the value in protecting them - along at least three axes:
* how much damage would be done (put another way: how much would it cost) if this asset were to be read by someone who shouldn’t be able to?
* how much damage would be done if the asset were modified in an unexpected fashion?
* how much damage would be done if the asset disappeared, or could not be used for the legitimate use cases?
So we can classify the importance of assets - and thus the value in protecting them - along at least three axes:
* how much damage would be done (put another way: how much would it cost) if this asset were to be read by someone who shouldn’t be able to?
* how much damage would be done if the asset were modified in an unexpected fashion?
* how much damage would be done if the asset disappeared, or could not be used for the legitimate use cases?
So we can classify the importance of assets - and thus the value in protecting them - along at least three axes:
* how much damage would be done (put another way: how much would it cost) if this asset were to be read by someone who shouldn’t be able to?
* how much damage would be done if the asset were modified in an unexpected fashion?
* how much damage would be done if the asset disappeared, or could not be used for the legitimate use cases?
So we can classify the importance of assets - and thus the value in protecting them - along at least three axes:
* how much damage would be done (put another way: how much would it cost) if this asset were to be read by someone who shouldn’t be able to?
* how much damage would be done if the asset were modified in an unexpected fashion?
* how much damage would be done if the asset disappeared, or could not be used for the legitimate use cases?
Filesystem permissions can protect the confidentiality and integrity of persistent assets - up to a point. The super-user gets to trump the permissions model.
Of course, it’s easier to change the permissions or ACLs on a file than it is to protect it against misuse - think carefully about what classes of user will be interacting with your app, and what they should be able to change or read.
Filesystem permissions can protect the confidentiality and integrity of persistent assets - up to a point. The super-user gets to trump the permissions model.
Of course, it’s easier to change the permissions or ACLs on a file than it is to protect it against misuse - think carefully about what classes of user will be interacting with your app, and what they should be able to change or read.
Of course the filesystem permissions can be trumped by the super-user, but it’s not always the case that their superior status should mean they can read a regular user’s data. That’s where encryption comes in. Keychain is actually very easy to use for the usual case of keeping one password for an app to access a single service such as a web application or e-mail account.
Of course the filesystem permissions can be trumped by the super-user, but it’s not always the case that their superior status should mean they can read a regular user’s data. That’s where encryption comes in. Keychain is actually very easy to use for the usual case of keeping one password for an app to access a single service such as a web application or e-mail account.
Of course the filesystem permissions can be trumped by the super-user, but it’s not always the case that their superior status should mean they can read a regular user’s data. That’s where encryption comes in. Keychain is actually very easy to use for the usual case of keeping one password for an app to access a single service such as a web application or e-mail account.
Of course the filesystem permissions can be trumped by the super-user, but it’s not always the case that their superior status should mean they can read a regular user’s data. That’s where encryption comes in. Keychain is actually very easy to use for the usual case of keeping one password for an app to access a single service such as a web application or e-mail account.
Of course the filesystem permissions can be trumped by the super-user, but it’s not always the case that their superior status should mean they can read a regular user’s data. That’s where encryption comes in. Keychain is actually very easy to use for the usual case of keeping one password for an app to access a single service such as a web application or e-mail account.
Of course the filesystem permissions can be trumped by the super-user, but it’s not always the case that their superior status should mean they can read a regular user’s data. That’s where encryption comes in. Keychain is actually very easy to use for the usual case of keeping one password for an app to access a single service such as a web application or e-mail account.
Of course the filesystem permissions can be trumped by the super-user, but it’s not always the case that their superior status should mean they can read a regular user’s data. That’s where encryption comes in. Keychain is actually very easy to use for the usual case of keeping one password for an app to access a single service such as a web application or e-mail account.
The longer a secret is kept in memory, the easier it is for a debugging tool such as gdb or F-Script Anywhere to retrieve it. Keychain allows us to pass around references to the encrypted secret, only retrieving the plain-text at the point where it’s really needed.
The longer a secret is kept in memory, the easier it is for a debugging tool such as gdb or F-Script Anywhere to retrieve it. Keychain allows us to pass around references to the encrypted secret, only retrieving the plain-text at the point where it’s really needed.
The longer a secret is kept in memory, the easier it is for a debugging tool such as gdb or F-Script Anywhere to retrieve it. Keychain allows us to pass around references to the encrypted secret, only retrieving the plain-text at the point where it’s really needed.
So that was how we can protect the confidentiality and integrity (and to some extent, the availability) of filesystem assets. But what about the integrity of our app itself?
So it’s incredibly easy to sign apps with Xcode, but for some reason few apps actually ship signed. Why is that? I think it’s because there’s very minimal UI related to the feature in Leopard, so it’s hard to see that there’s any benefit for the Mac user on the Clapham omnibus. However, look at the iPhone where the code signature is used everywhere, and the administration features on OS X (and Server) which rely on code signatures such as the application controls and the firewall.
So it’s incredibly easy to sign apps with Xcode, but for some reason few apps actually ship signed. Why is that? I think it’s because there’s very minimal UI related to the feature in Leopard, so it’s hard to see that there’s any benefit for the Mac user on the Clapham omnibus. However, look at the iPhone where the code signature is used everywhere, and the administration features on OS X (and Server) which rely on code signatures such as the application controls and the firewall.
So it’s incredibly easy to sign apps with Xcode, but for some reason few apps actually ship signed. Why is that? I think it’s because there’s very minimal UI related to the feature in Leopard, so it’s hard to see that there’s any benefit for the Mac user on the Clapham omnibus. However, look at the iPhone where the code signature is used everywhere, and the administration features on OS X (and Server) which rely on code signatures such as the application controls and the firewall.
So, presumably, I’m going to address availability next.
Launchd offers some very cool and flexible configuration as a service watchdog, so if there’s some service used by your app for which availability is important this should be your first port of call. Note that there were a few bugs on 10.4 and the whole thing was less flexible. 10.3 and before never existed - we have always been at war with Eurasia.
Launchd offers some very cool and flexible configuration as a service watchdog, so if there’s some service used by your app for which availability is important this should be your first port of call. Note that there were a few bugs on 10.4 and the whole thing was less flexible. 10.3 and before never existed - we have always been at war with Eurasia.
Launchd offers some very cool and flexible configuration as a service watchdog, so if there’s some service used by your app for which availability is important this should be your first port of call. Note that there were a few bugs on 10.4 and the whole thing was less flexible. 10.3 and before never existed - we have always been at war with Eurasia.
Launchd offers some very cool and flexible configuration as a service watchdog, so if there’s some service used by your app for which availability is important this should be your first port of call. Note that there were a few bugs on 10.4 and the whole thing was less flexible. 10.3 and before never existed - we have always been at war with Eurasia.
Look at this screenshot of iTunes, and rather than complaining about my taste in music try and think of what the various assets are. Which of the CIA attributes are important in each case? Who might have a stake in protecting them? Who might compromise them?
So once we’ve identified a threat (I didn’t explicitly discuss entry points and routes around the app - those are highly app-specific), we can see what type of damage is done should the threat succeed.
So once we’ve identified a threat (I didn’t explicitly discuss entry points and routes around the app - those are highly app-specific), we can see what type of damage is done should the threat succeed.
So once we’ve identified a threat (I didn’t explicitly discuss entry points and routes around the app - those are highly app-specific), we can see what type of damage is done should the threat succeed.
So once we’ve identified a threat (I didn’t explicitly discuss entry points and routes around the app - those are highly app-specific), we can see what type of damage is done should the threat succeed.
So once we’ve identified a threat (I didn’t explicitly discuss entry points and routes around the app - those are highly app-specific), we can see what type of damage is done should the threat succeed.
So once we’ve identified a threat (I didn’t explicitly discuss entry points and routes around the app - those are highly app-specific), we can see what type of damage is done should the threat succeed.
So once we’ve identified a threat (I didn’t explicitly discuss entry points and routes around the app - those are highly app-specific), we can see what type of damage is done should the threat succeed.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.
Does authorisation services protect us against elevation of privilege attacks? Not directly - note that the rights obtained are passed back to the calling application, which is running as the user who made the request - if the user can make the request they can do whatever was “behind” the right without bothering your app to acquire the right. This is why we must consider “factored” apps - where the auth right is used to invoke a privileged helper, which then retrieves the right from the calling app to verify that it really should perform the privileged task. In this way, the user cannot circumvent the requirement to obtain the right in order to perform the gated task.

Designing a Secure Cocoa App — Presentation Transcript

Building a secure Cocoa application Graham Lee (@iamleeg)
MOAB - Jan 2007 OS Apple apps Other apps 27% 47% 27% Source - http://projects.info-pull.com/moab/
Principles c2 a2 b 2
What is a threat?
What is a threat?
What is a threat?
What is a threat?
Who is the misuser?
Who is the misuser?
Who is the misuser? What’s my motivation??
Who is the misuser? What’s my motivation?? How risk- averse am I?
Who is the misuser? What’s my motivation?? How risk- averse am I? What skills and resources can I use?
Assets
Assets
Assets
Assets
Assets
Assets credit: freefoto.com
C I A
Conﬁdentiality I A
Conﬁdentiality I ntegrity A
Conﬁdentiality I ntegrity A vailability
I’m sorry, Dave…
I’m sorry, Dave… • We remember -rwxrwxrwx
I’m sorry, Dave… • We remember -rwxrwxrwx • What about “group:everyone deny delete”?
Keychain
Keychain •Secure storage…
Keychain •Secure storage… •…with access control!
Keychain •Secure storage… •…with access control! •Really simple API (simpler on iPhone :P)
Keychain •Secure storage… •…with access control! •Really simple API (simpler on iPhone :P) •SecKeychainFindInternetPassword()
Keychain •Secure storage… •…with access control! •Really simple API (simpler on iPhone :P) •SecKeychainFindInternetPassword() •Even protects against “cold boot”* *http://citp.princeton.edu/memory/
Keychain •Secure storage… •…with access control! •Really simple API (simpler on iPhone :P) •SecKeychainFindInternetPassword() •Even protects against “cold boot”* •…if used carefully *http://citp.princeton.edu/memory/
my secret password my secret password my secret password
Conﬁdentiality I ntegrity A vailability
How to sign code
How to sign code Erm, that’s it.
Conﬁdentiality I ntegrity A vailability
launchd
launchd • pretty sweet (on 10.5)
launchd • pretty sweet (on 10.5) • somewhat sweet on 10.4
launchd • pretty sweet (on 10.5) • somewhat sweet on 10.4 • 10.3 still exists?!?
launchd • pretty sweet (on 10.5) • somewhat sweet on 10.4 • 10.3 still exists?!? • check out <key>KeepAlive</key> for watchdog-related goodness, in launchd.plist(5)
Exercise 1 :-)
Exercise 1 :-)
S T R I D E
Spooﬁng T R I D E
Spooﬁng Tampering R I D E
Spooﬁng Tampering Repudiation I D E
Spooﬁng Tampering Repudiation I nformation leak D E
Spooﬁng Tampering Repudiation I nformation leak Denial of Service E
Spooﬁng Tampering Repudiation I nformation leak Denial of Service E levation of Privilege
Authorisation Services
Authorisation Services SFAuthorizationView
Authorisation Services SFAuthorizationView
Authorisation Services SFAuthorizationView
Authorisation Services SFAuthorizationView <key>system.preferences.accounts </key> <dict> AuthorizationRights <key>allow-root</key> <true/> <key>class</key> <string>user</string> <key>comment</key> <string> </string> <key>group</key> <string>admin</string> <key>shared</key> <false/> </dict>
Demo c a
?

Designing a Secure Cocoa App

by Graham Lee on Jul 08, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 25

Statistics

Designing a Secure Cocoa App — Presentation Transcript