Alastair’s Place

Software development, Cocoa, Objective-C, life. Stuff like that.

OS X Authentication Dialogs Can Lie(!)

Some time ago now, in fact in November of 2003, I reported to Apple that it was possible to make the authentication dialog lie about which program was asking for authorisation to do something. This is filed as rdar://3486235, for any Apple employees watching.

Here’s an amusing demonstration:


(the program that did this was definitely not called “Steve Jobs”)

Very funny, but quite scary because it means it’s much too easy to trick an end-user into giving a potentially malicious program root privileges. Apple have been widely—and, to my mind, rather unfairly—lambasted for their attitude towards security holes, but in this case I’m sorry to report that the critics are quite correct. I’m sure they’ll fix this now I’ve published it on the Internet, but I really shouldn’t have had to do this; it should have been fixed back in 2003 when it was first reported.

Update: Allan Odgaard has quite rightly pointed out that even with this fixed, it is currently possible for a third-party program to replicate the look and UI of the system authentication dialog. This is true and is another problem that should really be addressed; reserving a particular key combination and making it always go to the system rather than user apps is one way around that issue (that's what Windows does, for instance). Another, perhaps better approach might be to have the Security Server share some secret with the user, and present that in the authentication dialog to prove that it really is the Security Server and not some bogus process.

The problem is that the dialog that appears gets the name of the calling program from argv[0], which as everyone knows is under the control of the calling program’s parent process. So, for instance, if you write something like this:

#include <unistd.h>

int main (void)
  execl ("/usr/libexec/authopen",
  return 0;

which asks the special authopen program to give the calling process a file handle for /dev/rdisk0, what you’ll find is that it displays a dialog box like this

Authentication dialog

and in case you think that opening up the detail area will save you from getting caught out by a potentially malicious use of this bug, take a look at this:

Authentication dialog with expanded detail

Now, that definitely wasn’t Disk Utility asking for authorisation. It was the program whose source code is shown above. And if you authenticate, that program gets a file handle for /dev/rdisk0, which is clearly a huge security problem as it effectively gives it access to all of your data. Equally, it could use its own helper tool (rather than authopen) and simply ask for root privileges for whatever malicious purpose it had in mind. But this demonstrates the problem quite ably.

Ordinarily I don’t approve of people publishing security holes, because it puts end-users at risk, but this one makes it too easy to trick a user into giving away privileged access to his or her machine, and Apple still haven’t fixed it, over two years after it was reported. It’s also a sufficiently common issue that the comp.unix.programmer frequently asked questions document actually mentions that “it is possible to invoke programs with arbitrary values of argv[0]”, so the fact that you can set argv[0] to whatever you like is hardly an unknown feature, nor is it likely that the black hats don’t already know about this.