Re: which temp dir to use?
On Mon, May 25, 2009 at 7:12 PM, Gwynne Raskind wrote: > On May 25, 2009, at 6:52 PM, Michael Ash wrote: >> >> The authentication stuff is pertinent, because the AEWP is an example >> of an API which works by having an unprivileged user process >> communicate with a privileged process that does the work. A technique >> which allows you to compromise a process which uses AEWP demonstrates >> how this compromise can be done with any such setup, even using a >> secure channel (which AEWP does). > > It does? Last I checked, AEWP() used a temp file on disk to pass its > AuthorizationRef to the child process. Pipes, anyone? I need fewer assumptions and more fact-checking, apparently. However, I think this is still "secure", because the AuthorizationRef is initially generated on the privileged side of things and can't be faked. (Hey look, more assumptions.) The end result is a secure channel even if the mechanism to actually transmit the bytes across is not. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
> It does? Last I checked, AEWP() used a temp file on disk to pass its > AuthorizationRef to the child process. Pipes, anyone? Hah. I wonder what temp directory it uses? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On May 25, 2009, at 6:52 PM, Michael Ash wrote: The authentication stuff is pertinent, because the AEWP is an example of an API which works by having an unprivileged user process communicate with a privileged process that does the work. A technique which allows you to compromise a process which uses AEWP demonstrates how this compromise can be done with any such setup, even using a secure channel (which AEWP does). It does? Last I checked, AEWP() used a temp file on disk to pass its AuthorizationRef to the child process. Pipes, anyone? -- Gwynne, Daughter of the Code "This whole world is an asylum for the incurable." ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Mon, May 25, 2009 at 6:18 PM, Kyle Sluder wrote: > On Mon, May 25, 2009 at 3:08 PM, Michael Ash wrote: >> Not at all. It doesn't change my point one whit. If A can command the >> privileged process to do something nasty, then C can do it too. >> (Possibly by breaking into A by one of the many mechanisms available >> and forcing it to make an evil request, possibly by imitating what A >> does.) > > Isn't that exactly what we're talking about? C impersonating A by > swapping its own evil data into the channel A is using? It's a man in > the middle attack. To defend against it, you need to authenticate the > client *and* secure the channel. The authentication part was never > mentioned because it's not pertinent to the flaw we're discussing, > which is a function of using the filesystem to shuttle data around. Right, and since you *can't* authenticate the client beyond "running as user X", securing the channel against other code running as user X is pointless. It is very much worthwhile to protect your communications channel from other users on the system. But there's really not much point in protecting it from other *processes* running as the *same* user, because they have a dozen other ways to break into the conversation if they should so choose. The authentication stuff is pertinent, because the AEWP is an example of an API which works by having an unprivileged user process communicate with a privileged process that does the work. A technique which allows you to compromise a process which uses AEWP demonstrates how this compromise can be done with any such setup, even using a secure channel (which AEWP does). Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Mon, May 25, 2009 at 3:08 PM, Michael Ash wrote: > Not at all. It doesn't change my point one whit. If A can command the > privileged process to do something nasty, then C can do it too. > (Possibly by breaking into A by one of the many mechanisms available > and forcing it to make an evil request, possibly by imitating what A > does.) Isn't that exactly what we're talking about? C impersonating A by swapping its own evil data into the channel A is using? It's a man in the middle attack. To defend against it, you need to authenticate the client *and* secure the channel. The authentication part was never mentioned because it's not pertinent to the flaw we're discussing, which is a function of using the filesystem to shuttle data around. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Mon, May 25, 2009 at 3:50 PM, Jeremy Pereira wrote: > > On 25 May 2009, at 20:23, Michael Ash wrote: > >> On Sun, May 24, 2009 at 7:57 PM, Greg Guerin wrote: >>> >>> Michael Ash wrote: >>> Malevolent process C fails. >>> >>> Or maybe malevolent process C works because it's running with the same >>> uid >>> as unprivileged process A. The sticky-bit on a directory only prevents >>> one >>> uid from interfering with another uid's files. It has no effect if the >>> uids >>> of the processes are the same. >> >> To put it bluntly: so what? > > Have you forgotten about B - a process running with escalated privileges > that A and C are trying to talk to? Not at all. It doesn't change my point one whit. If A can command the privileged process to do something nasty, then C can do it too. (Possibly by breaking into A by one of the many mechanisms available and forcing it to make an evil request, possibly by imitating what A does.) A privileged process which can be commanded by an unprivileged user needs to authenticate the command, not the process giving the command. It's *probably* a good idea to use a more private channel than a file for this kind of thing, but don't think for a second that using such a private channel will suddenly make you secure from another process doing evil, or even that it will make it appreciably more difficult. It would be nice if OS X had a more fine-grained permissions model such that every process you run doesn't get permissions to destroy your files, mess about with your other processes, and do other nasty things, but alas that is not the system we currently have. By way of illustration, a homework assignment: come up with three ways to take an existing program which calls AuthorizationExecuteWithPrivileges and use that existing program to run arbitrary code as root on the user's computer. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On 25 May 2009, at 20:23, Michael Ash wrote: On Sun, May 24, 2009 at 7:57 PM, Greg Guerin wrote: Michael Ash wrote: Malevolent process C fails. Or maybe malevolent process C works because it's running with the same uid as unprivileged process A. The sticky-bit on a directory only prevents one uid from interfering with another uid's files. It has no effect if the uids of the processes are the same. To put it bluntly: so what? Have you forgotten about B - a process running with escalated privileges that A and C are trying to talk to? The UNIX security model fundamentally works at the user level, not the process level. There is essentially nothing in place to protect one process from attack by another. If the adversary is able to run code under your user, then you have already lost. He must be stopped before he gets that far. Trying to protect your application from attack by another application running under the same user is pointless. Yes, you have lost, but not necessarily the owner of the computer and not all the other people that use it. If the attacker has gained root access, however, it's game over for everybody. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/adc%40jeremyp.net This email sent to a...@jeremyp.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Sun, May 24, 2009 at 7:57 PM, Greg Guerin wrote: > Michael Ash wrote: > >> Malevolent process C fails. > > Or maybe malevolent process C works because it's running with the same uid > as unprivileged process A. The sticky-bit on a directory only prevents one > uid from interfering with another uid's files. It has no effect if the uids > of the processes are the same. To put it bluntly: so what? The UNIX security model fundamentally works at the user level, not the process level. There is essentially nothing in place to protect one process from attack by another. If the adversary is able to run code under your user, then you have already lost. He must be stopped before he gets that far. Trying to protect your application from attack by another application running under the same user is pointless. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
Michael Ash wrote: Malevolent process C fails. Or maybe malevolent process C works because it's running with the same uid as unprivileged process A. The sticky-bit on a directory only prevents one uid from interfering with another uid's files. It has no effect if the uids of the processes are the same. Having the same uid would not be unusual if the attack works by creating an unprivileged lurker that does nothing until an attempt is made to communicate with a privileged process using the vulnerable / tmp/ipc mechanism. An unprivileged launch-agent with an innocuous name might even arrange it so launchd is doing the "watch for change at /tmp/ipc" on its behalf. Refer to 'man 5 launchd.plist' and think of devious underhanded ways to use each feature. This would be a local privilege escalation, and it might not be noticed for some time if the trojan that adds the launch-agent performs a useful function. Or even if the trojan didn't perform a useful function, but seduced users into just one trial-run. Even after the trojan is deleted, it can still leave its malicious (yet patient) payload behind. If you think you couldn't possibly succumb to this tactic, when was the last time you used the 'launchctl list' command, and confirmed that every active job was one you wanted and knew about? And what about all the users who have no idea how to use Terminal.app or the 'launchctl' command? Not every attack will be from the front, nor will every traitor instantly reveal its treachery. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Sun, May 24, 2009 at 3:18 PM, Michael Ash wrote: > /tmp has a special permissions bit set called the sticky bit. When set > on directories, the sticky bit modifies the standard UNIX permissions > model and makes it so that the directory's contents can only be > deleted or renamed by the owner of the item in question, of the > directory, or root. In other words, if I write to /tmp/xyz and then > you try to rm /tmp/xyz, your attempt will fail. Give it a try and see. Believe it or not, I did before I replied to the thread. Except this is what I did: # cd /tmp # touch foo # sudo -s # su nobody # rm foo However, that wasn't what actually happened. Had I bothered to run `whoami`, I would have seen this: # cd /tmp # touch foo # whoami kyle # sudo -s # whoami root # su nobody # whoami root # rm foo What I failed to realize is that su will by default execute the user's specified shell (which is /usr/bin/false for nobody). You have to provide -m to override this behavior, and if you do that, it fails. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Sun, May 24, 2009 at 12:52 PM, Kyle Sluder wrote: > 1. Non-privileged process A running as user Alice creates a file > called /tmp/ipc. > 2. A signals to privileged process B, running as root, that the file exists. > 3. Malevolent process C, running as user Eve, notices the file, > unlinks it (which it can do due to the permissions on /tmp) and > creates a new one in its place with its own preferred contents. Malevolent process C fails. /tmp has a special permissions bit set called the sticky bit. When set on directories, the sticky bit modifies the standard UNIX permissions model and makes it so that the directory's contents can only be deleted or renamed by the owner of the item in question, of the directory, or root. In other words, if I write to /tmp/xyz and then you try to rm /tmp/xyz, your attempt will fail. Give it a try and see. Certainly there are risks with using /tmp, but it *can* be done correctly. You need to open the file with O_EXCL to ensure that the file didn't already exist, and you need to open it with permissions set so that nobody else can write to the file. If you do this (and properly handle errors when they happen, obviously) then other non-privileged users can't jump in the middle as you describe. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Sun, May 24, 2009 at 11:28 AM, Dave Keck wrote: > I debated whether I should mention my technique thinking someone might > bring up this precise vulnerability. :) It is possible to use /tmp safely, but you have to be very careful. Just like when doing anything sensitive on the filesystem. > My rationale is based on the fact the BetterAuthorizationSample is > also vulnerable to a similar attack: some malicious code is running in > the background, and at just the right instant replaces the genuine > tool with a malicious one, and the malicious tool gets root > privileges. Granted, our cases are quite different: mine is completely > preventable by using an IPC mechanism that avoids the filesystem, as > you mentioned. But alas, I sided with the "if they want it bad > enough..." line of thinking. That's a rather unfortunate line of thinking. Apple could do everything in the world to lock down the operating system, but if someone can take advantage of a completely unrelated third-party software to perform an attack, I wouldn't be too thrilled. I'm also confused about how one could levy the same attack against BAS. Unless the app is running from /tmp (or another directory writable by an unprivileged user) then it's not going to happen. The attack I described is a consequence of how UNIX applies permissions to directories; the ability to unlink directory entries is not an attribute of the entries themselves, but of the directory. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
> 1. Non-privileged process A running as user Alice creates a file > called /tmp/ipc. > 2. A signals to privileged process B, running as root, that the file exists. > 3. Malevolent process C, running as user Eve, notices the file, > unlinks it (which it can do due to the permissions on /tmp) and > creates a new one in its place with its own preferred contents. > 4. B performs its action on the newly-replaced file contents. I debated whether I should mention my technique thinking someone might bring up this precise vulnerability. :) My rationale is based on the fact the BetterAuthorizationSample is also vulnerable to a similar attack: some malicious code is running in the background, and at just the right instant replaces the genuine tool with a malicious one, and the malicious tool gets root privileges. Granted, our cases are quite different: mine is completely preventable by using an IPC mechanism that avoids the filesystem, as you mentioned. But alas, I sided with the "if they want it bad enough..." line of thinking. David ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Sun, May 24, 2009 at 9:52 AM, Kyle Sluder wrote: > If you *must* use /tmp for some reason (not linking > against Foundation, etc.) use FSFindFolder. Sorry, wasn't clear here. I meant "If you can't use NSTemporaryDirectory", not "If you *must* use /tmp". --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On Sun, May 24, 2009 at 5:58 AM, Dave Keck wrote: > I use /tmp. Works great for me - I use it to save temporary files that > another privileged process then moves to a permanent location. Launchd > uses it too, along with a host of other things. Please don't just toss things in /tmp. Launchd doesn't just toss things in /tmp, it creates directories within /tmp, because that's secure (you can't delete empty directories, and the permissions on the directory are set such that only a specific user can modify the directory). Putting files for inter-process communication in /tmp is not secure. Imagine the following sequence of events: 1. Non-privileged process A running as user Alice creates a file called /tmp/ipc. 2. A signals to privileged process B, running as root, that the file exists. 3. Malevolent process C, running as user Eve, notices the file, unlinks it (which it can do due to the permissions on /tmp) and creates a new one in its place with its own preferred contents. 4. B performs its action on the newly-replaced file contents. Game over. Eve has used a non-privileged account but has taken advantage of Alice's use of a privileged tool. This is even easier if the path in /tmp is hardcoded. If you want to pass things between non-privileged and privileged processes, you have quite a few options that don't even involve the filesystem. If you need persistence or some other feature of the filesystem, use NSTemporaryDirectory because it is far more secure than /tmp. If you *must* use /tmp for some reason (not linking against Foundation, etc.) use FSFindFolder. If you can't even use that, then follow launchd's lead and create user-specific non-empty directories in /tmp. Try to pass file descriptors or pipes around whenever possible rather than pointing to paths in the filesystem. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
Richard Frith-Macdonald wrote: What you want is user specific and application specific I presume (ie you want to store the data your your application, and for the person who is running the application). I guess it's not really temporary (or you wouldn't need a fixed path), but is actually information you would like to keep around, but which is not essential for your application. That sounds a lot like the definition of a cache: user-specific, app- specific, kept around, but not essential. Consider using ~/Library/ Caches/. Worth a read: "Where to Put Application Files": http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFileSystem/Articles/WhereToPutFiles.html -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
I use /tmp. Works great for me - I use it to save temporary files that another privileged process then moves to a permanent location. Launchd uses it too, along with a host of other things. But yeah, where you put your temporary files really depends on the context and who needs to see the them. David ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On 23 May 2009, at 11:43, Nick Rogers wrote: Hi, NSTemporaryDirectory(), returns something like /var/temp/we/weOIDM +mck Whereas I want to store files at a place with a fixed path. So where should I save temp files? and how can I get that path programatically everytime? What you want is user specific and application specific I presume (ie you want to store the data your your application, and for the person who is running the application). I guess it's not really temporary (or you wouldn't need a fixed path), but is actually information you would like to keep around, but which is not essential for your application. The place for that is the standard per-user application support directory, and you get that using the NSSearchPathForDirectoriesInDomains() function specifying the NSApplicationSupportDirectory and NSUserDomainMask Given that directory, you can just append the name of your application and make a subdirectory to hold your files. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: which temp dir to use?
On 23 May 2009, at 12:43, Nick Rogers wrote: Hi, NSTemporaryDirectory(), returns something like /var/temp/we/weOIDM +mck Whereas I want to store files at a place with a fixed path. So where should I save temp files? and how can I get that path programatically everytime? Use the C library function mkstemp() instead. You specify a template for what the name should look like, including the directory, and get an ordinary Unix file descriptor back. Robert ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
