Building a secure
Cocoa application
   Graham Lee (@iamleeg)
MOAB - Jan 2007
 OS                  Apple apps                      Other apps




          27%



                     ...
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?


                 Wh...
Assets
Assets
Assets
Assets
Assets
Assets

   credit: freefoto.com
C
I
A
Confidentiality
I
A
Confidentiality
I ntegrity
A
Confidentiality
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)
•SecKeychainFindInternetPasswo...
Keychain

              •Secure storage…
              •…with access control!
              •Really simple API (simpler on...
Keychain

              •Secure storage…
              •…with access control!
              •Really simple API (simpler on...
my secret password




            my secret password




my secret password
Confidentiality
I ntegrity
A vailability
How to sign code
How to sign code




     Erm, that’s it.
Confidentiality
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
  w...
Exercise 1 :-)
Exercise 1 :-)
S
T
R
I
D
E
Spoofing
T
R
I
D
E
Spoofing
Tampering
R
I
D
E
Spoofing
Tampering
Repudiation
I
D
E
Spoofing
Tampering
Repudiation
I nformation leak
D
E
Spoofing
Tampering
Repudiation
I nformation leak
Denial of Service
E
Spoofing
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




                                    	
                  ...
Demo


           c
       a
?
Designing a Secure Cocoa App
Designing a Secure Cocoa App
Designing a Secure Cocoa App
Upcoming SlideShare
Loading in …5
×

Designing a Secure Cocoa App

1,099
-1

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,099
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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&amp;#x2019;ll look at an example of a vulnerability in an app, so that we can apply the ideas we&amp;#x2019;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&amp;#x2019;t care whether the holes are in our apps or in Apple&amp;#x2019;s; come to that, neither do our customers. If my app is less secure than the competitor&amp;#x2019;s then that&amp;#x2019;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 &amp;#x201C;Pythagoras theorem&amp;#x201D;, 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&amp;#x2019;s why I used the term &amp;#x201C;misuser&amp;#x201D; instead of &amp;#x201C;abuser&amp;#x201D;. 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&amp;#x2019;re likely to take huge risks and it&amp;#x2019;s also probable that they&amp;#x2019;d be security experts. That&amp;#x2019;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&amp;#x2019;s why I used the term &amp;#x201C;misuser&amp;#x201D; instead of &amp;#x201C;abuser&amp;#x201D;. 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&amp;#x2019;re likely to take huge risks and it&amp;#x2019;s also probable that they&amp;#x2019;d be security experts. That&amp;#x2019;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&amp;#x2019;s why I used the term &amp;#x201C;misuser&amp;#x201D; instead of &amp;#x201C;abuser&amp;#x201D;. 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&amp;#x2019;re likely to take huge risks and it&amp;#x2019;s also probable that they&amp;#x2019;d be security experts. That&amp;#x2019;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&amp;#x2019;s why I used the term &amp;#x201C;misuser&amp;#x201D; instead of &amp;#x201C;abuser&amp;#x201D;. 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&amp;#x2019;re likely to take huge risks and it&amp;#x2019;s also probable that they&amp;#x2019;d be security experts. That&amp;#x2019;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&amp;#x2019;s why I used the term &amp;#x201C;misuser&amp;#x201D; instead of &amp;#x201C;abuser&amp;#x201D;. 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&amp;#x2019;re likely to take huge risks and it&amp;#x2019;s also probable that they&amp;#x2019;d be security experts. That&amp;#x2019;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&amp;#x2019;s why I used the term &amp;#x201C;misuser&amp;#x201D; instead of &amp;#x201C;abuser&amp;#x201D;. 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&amp;#x2019;re likely to take huge risks and it&amp;#x2019;s also probable that they&amp;#x2019;d be security experts. That&amp;#x2019;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&amp;#x2019;s identity or some information of financial value. Alternatively they can be intangible; there&amp;#x2019;s no file on the Sophos webserver which actually contains the company&amp;#x2019;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&amp;#x2019;t actually &amp;#x201C;own&amp;#x201D;, 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&amp;#x2019;s identity or some information of financial value. Alternatively they can be intangible; there&amp;#x2019;s no file on the Sophos webserver which actually contains the company&amp;#x2019;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&amp;#x2019;t actually &amp;#x201C;own&amp;#x201D;, 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&amp;#x2019;s identity or some information of financial value. Alternatively they can be intangible; there&amp;#x2019;s no file on the Sophos webserver which actually contains the company&amp;#x2019;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&amp;#x2019;t actually &amp;#x201C;own&amp;#x201D;, 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&amp;#x2019;s identity or some information of financial value. Alternatively they can be intangible; there&amp;#x2019;s no file on the Sophos webserver which actually contains the company&amp;#x2019;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&amp;#x2019;t actually &amp;#x201C;own&amp;#x201D;, 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&amp;#x2019;s identity or some information of financial value. Alternatively they can be intangible; there&amp;#x2019;s no file on the Sophos webserver which actually contains the company&amp;#x2019;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&amp;#x2019;t actually &amp;#x201C;own&amp;#x201D;, 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&amp;#x2019;s identity or some information of financial value. Alternatively they can be intangible; there&amp;#x2019;s no file on the Sophos webserver which actually contains the company&amp;#x2019;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&amp;#x2019;t actually &amp;#x201C;own&amp;#x201D;, 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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;s not always the case that their superior status should mean they can read a regular user&amp;#x2019;s data. That&amp;#x2019;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&amp;#x2019;s not always the case that their superior status should mean they can read a regular user&amp;#x2019;s data. That&amp;#x2019;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&amp;#x2019;s not always the case that their superior status should mean they can read a regular user&amp;#x2019;s data. That&amp;#x2019;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&amp;#x2019;s not always the case that their superior status should mean they can read a regular user&amp;#x2019;s data. That&amp;#x2019;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&amp;#x2019;s not always the case that their superior status should mean they can read a regular user&amp;#x2019;s data. That&amp;#x2019;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&amp;#x2019;s not always the case that their superior status should mean they can read a regular user&amp;#x2019;s data. That&amp;#x2019;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&amp;#x2019;s not always the case that their superior status should mean they can read a regular user&amp;#x2019;s data. That&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;s incredibly easy to sign apps with Xcode, but for some reason few apps actually ship signed. Why is that? I think it&amp;#x2019;s because there&amp;#x2019;s very minimal UI related to the feature in Leopard, so it&amp;#x2019;s hard to see that there&amp;#x2019;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&amp;#x2019;s incredibly easy to sign apps with Xcode, but for some reason few apps actually ship signed. Why is that? I think it&amp;#x2019;s because there&amp;#x2019;s very minimal UI related to the feature in Leopard, so it&amp;#x2019;s hard to see that there&amp;#x2019;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&amp;#x2019;s incredibly easy to sign apps with Xcode, but for some reason few apps actually ship signed. Why is that? I think it&amp;#x2019;s because there&amp;#x2019;s very minimal UI related to the feature in Leopard, so it&amp;#x2019;s hard to see that there&amp;#x2019;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&amp;#x2019;m going to address availability next.
  • Launchd offers some very cool and flexible configuration as a service watchdog, so if there&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;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&amp;#x2019;ve identified a threat (I didn&amp;#x2019;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&amp;#x2019;ve identified a threat (I didn&amp;#x2019;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&amp;#x2019;ve identified a threat (I didn&amp;#x2019;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&amp;#x2019;ve identified a threat (I didn&amp;#x2019;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&amp;#x2019;ve identified a threat (I didn&amp;#x2019;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&amp;#x2019;ve identified a threat (I didn&amp;#x2019;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&amp;#x2019;ve identified a threat (I didn&amp;#x2019;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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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 &amp;#x201C;behind&amp;#x201D; the right without bothering your app to acquire the right. This is why we must consider &amp;#x201C;factored&amp;#x201D; 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

    1. 1. Building a secure Cocoa application Graham Lee (@iamleeg)
    2. 2. MOAB - Jan 2007 OS Apple apps Other apps 27% 47% 27% Source - http://projects.info-pull.com/moab/
    3. 3. Principles c2 a2 b 2
    4. 4. What is a threat?
    5. 5. What is a threat?
    6. 6. What is a threat?
    7. 7. What is a threat?
    8. 8. Who is the misuser?
    9. 9. Who is the misuser?
    10. 10. Who is the misuser? What’s my motivation??
    11. 11. Who is the misuser? What’s my motivation?? How risk- averse am I?
    12. 12. Who is the misuser? What’s my motivation?? How risk- averse am I? What skills and resources can I use?
    13. 13. Assets
    14. 14. Assets
    15. 15. Assets
    16. 16. Assets
    17. 17. Assets
    18. 18. Assets credit: freefoto.com
    19. 19. C I A
    20. 20. Confidentiality I A
    21. 21. Confidentiality I ntegrity A
    22. 22. Confidentiality I ntegrity A vailability
    23. 23. I’m sorry, Dave…
    24. 24. I’m sorry, Dave… • We remember -rwxrwxrwx
    25. 25. I’m sorry, Dave… • We remember -rwxrwxrwx • What about “group:everyone deny delete”?
    26. 26. Keychain
    27. 27. Keychain •Secure storage…
    28. 28. Keychain •Secure storage… •…with access control!
    29. 29. Keychain •Secure storage… •…with access control! •Really simple API (simpler on iPhone :P)
    30. 30. Keychain •Secure storage… •…with access control! •Really simple API (simpler on iPhone :P) •SecKeychainFindInternetPassword()
    31. 31. Keychain •Secure storage… •…with access control! •Really simple API (simpler on iPhone :P) •SecKeychainFindInternetPassword() •Even protects against “cold boot”* *http://citp.princeton.edu/memory/
    32. 32. 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/
    33. 33. my secret password my secret password my secret password
    34. 34. Confidentiality I ntegrity A vailability
    35. 35. How to sign code
    36. 36. How to sign code Erm, that’s it.
    37. 37. Confidentiality I ntegrity A vailability
    38. 38. launchd
    39. 39. launchd • pretty sweet (on 10.5)
    40. 40. launchd • pretty sweet (on 10.5) • somewhat sweet on 10.4
    41. 41. launchd • pretty sweet (on 10.5) • somewhat sweet on 10.4 • 10.3 still exists?!?
    42. 42. 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)
    43. 43. Exercise 1 :-)
    44. 44. Exercise 1 :-)
    45. 45. S T R I D E
    46. 46. Spoofing T R I D E
    47. 47. Spoofing Tampering R I D E
    48. 48. Spoofing Tampering Repudiation I D E
    49. 49. Spoofing Tampering Repudiation I nformation leak D E
    50. 50. Spoofing Tampering Repudiation I nformation leak Denial of Service E
    51. 51. Spoofing Tampering Repudiation I nformation leak Denial of Service E levation of Privilege
    52. 52. Authorisation Services
    53. 53. Authorisation Services SFAuthorizationView
    54. 54. Authorisation Services SFAuthorizationView
    55. 55. Authorisation Services SFAuthorizationView
    56. 56. 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>
    57. 57. Demo c a
    58. 58. ?
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×