Alastair's Place

Perhaps part of the security team's problem with this bug is that there is no way for the end user to verify that any authentication dialog is real.

From a security perspective there's not necessarily a lot of difference between this bug and a bug that says "Hey look, I can write an app to pop up a dialog that looks like the auth dialog, and fool you into entering your password." In both cases you are being tricked into giving your password to an unauthorized source.

So they could fix this bug, but the larger bug would remain: end users are still literally unable to verify the authenticity of any authorization dialog. That's not really an excuse for not fixing it, and certainly not an excuse for not documenting it. But I'm just guessing at their reasoning.

Windows NT's solution to that was the ctrl-alt-delete logon -- the login dialog only appears when you hit an untrappable key combination. I don't know what Apple's got up their sleeve for this, but they've certainly known about it for a while. I hope they've got something planned for Leopard.

Indeed, you're right, there isn't a way for end users to verify that an authentication dialog is real. There certainly should be, though.

The Windows NT approach works reasonably well, though it can be a bit wearing pressing “secure attention sequence” keypresses at times. Another approach I quite like is having the Security Server share some secret with the user that it can then display in the dialog box to verify its identity.

FWIW, I think that the fact that you can currently subvert the system's own dialog is still a somewhat bigger hole; it's much easier to use the ready implemented version that will run something for you as root than it is to roll your own.

That's true. Subverting the system dialog is much worse, since a sufficiently savvy user with reason to be suspicious could detect a Trojan putting up a fake dialog (eg, using /bin/ps) but would still get fooled by the fake "real" dialog.

I thought there was an audit process inside Apple these days for processes that run as setuid root. I'm surprised the argv[0] trust problem - which is pretty obvious to anyone who's ever written setuid code - made it through. I'm even more surprised that they still haven't fixed it after two and a half years.

Drew, I'm currenly using OS X 10.4. I certainly hope that they don't hide their wonderful fix for this up their sleeves to only release it in Leopard.

As a possible compliment to fixing the security hole in the system dialog, is there some Apple-Human-Inteface-Guidelines-Compatible way of making the genuine dialog universally identifiable in such a way that a trojan could not reliably replicate it? What I'm thinking of is something along the lines of "skinning", where the user-selected "skin" would only be revealed by the system to its own security server... provide enough variations to make a chance match by a trojan that picks just one unlikely, and it becomes not very worthwhile to try to exploit that hole, while not interfering with the "flow" of user interaction any further than the existing dialog.

This is, of course, just an example of the "secret" alastair's suggested, but hopefully one that could still fit fairly seamlessly into the rest of the system. Even something as simple as an initial user setup option the very first time you sign in: "please pick your security color"... then all authentication dialog boxes use that as the background color in the password field. If you don't see the color you picked, don't enter your password: since it's user-specific and only accessible to the security server, even shared-access machines give a modest level of protection against inside-job fakers.

Yes, this is precisely the kind of thing I had in mind. I like the idea of a colour as it's particularly easy to understand, though you'd have to be careful to take account of colour-blindness when implementing such a thing.

I also think you'd have to have the dialog wait until you'd entered your user ID before showing the colour, as the dialog can also be used to allow a systems administrator to temporarily grant rights to a user for a particular purpose (i.e. it might be the sysadmin entering his or her credentials).

To the best of my knowledge, the authentication dialogs from the system are the only ones that float over top of every other application, even when various applications are switched in and out of the foreground.

I do like the idea of some shared secret, though, as an additional security measure. The color idea -- or perhaps an image -- is similar to some things I've been seeing on secure Web sites recently.

It's certainly true that they float over most other things, but I don't think that it's impossible for other applications to do the same thing. AFAIK it's controlled by the “window level”, which you can set in Cocoa using -setLevel:.