[Big Mac]

Theoretical Exploit Thesis: A virus or trojan horse displays a dialog box that is a visual approximation of the one displayed by SecurityAgent. If the user clicks the details disclosure triangle, it appears that the dialog is requesting rights for a trusted application such as System Preferences. As it is I see serious malicious potential here due to the simple fact that regular people are not technically inclined or security conscious.

Exploit Potential: Users who are presented with SecurityAgent dialog boxes authenticate without giving them much thought. The dialogs are likely seen by most users as annoyances and impediments to getting things accomplished. When an app asks for authentication, most people just proceed to authenticate. Based on this line of thought, a cracker really would not even need to spoof a trusted application, since most people won't care no matter which application is requesting privileges. A recent posting online made me consider authentication security, so now I'm going to pay attention, but I bet even I could have been duped. In addition, if a virus or trojan horse spoofed SecurityAgent in the name of another trusted app and did so with a reasonable visual approximation of the real thing, it seems it would be hard to recognize the fake.

Current Barriers to Exploit: The only barriers I can find to this user exploit are weak, IMO, because they require some technical understanding to utilize. Requiring the user to click the details triangle is a weak barrier because most users simply won't do it. I like the clean look of the dialogs, but as of now critical details are being hidden from users who are nearly oblivious to security concerns anyway. And even if the details are shown, they could still be spoofed as well. The other two barriers are subtle UI cues that most won't pick up on. You could go over to Activity Monitor to verify SecurityAgent is active, but nearly no one will do that. You could also switch to another application to check to see which application is actually presenting that dialog. With only these minimal visual safeguards in place, I don't think the average Mac user would be prepared for malware attacking from this angle.

Suggested Alterations: 1. Make Security Agent's dialog a sheet instead of a dialog box so that its ownership by the requesting app is apparent. 2. Use some type of internal system resource as a visual cue somewhere else on the screen to show that a security request is being made. (I just thought up a great possibility: a special padlock icon superimposed on the Dock icon of the requesting application.) 3. Make the disclosure triangle show details by default.

[Chuckit]

If a program randomly asked for authentication, that by itself would make me suspicious.

[loki74]

I'm with Chuckit on this one... the only time I ever remember having to authenticate is for installing apps and system update. possibly some other stuff, but not enough that I can remember.

However, all things considered, the alterations the OP suggests most definately would not hurt anyone. The sheet idea might not be applicable to all situations, but I think the padlock idea is good. Surely there are some users out there who wouldnt even suspect somethings wrong, even if the authentication request seems random?

...another question to ask is how would the attacker get the fake dialog (virus/trojan) on the system, and cause it to run at a given time? It seems to me that either way, physical access is necessary.

[CharlesS]

Originally Posted by loki74

...another question to ask is how would the attacker get the fake dialog (virus/trojan) on the system, and cause it to run at a given time? It seems to me that either way, physical access is necessary.

Easy, just put RemoveDebugCode.app or some such thing on VersionTracker and people will download it during the interim before VersionTracker figures out that it's a trojan.

The SevenDust/666 worm started out this way - someone uploaded what was supposed to be an optimized graphics accelerator driver to Info-Mac.

Hell, name the thing something related to Repair Permissions and you'll have half this forum infected in about 5 minutes.

[loki74]

hrmm. good point......

I guess were just lucky the incentive to write viruses and sh!t for OSX isnt huge, since less people get hurt.

[Big Mac]

As Charles states, it would be rather easy to get a malicious app on to the average Mac. Simply because we're Mac users doesn't mean our population is immune to social engineering.

[ghporter]

Big Mac, I agree with your thesis and your statement above. It is unfortunate that most Mac users feel bulletproof and godlike because "there are no Mac viruses," while in fact it's only true that there are no Mac viruses in the wild at this time.

I have frequently mentioned that I feel (as a one-time computer security specialist) that it is only a matter of time before someone writes a "killer Mac virus" and looses it on the world. When that happens, a whole lot of "I don't need to even think about viruses" Mac users are going to be hurting.

And as you and CharlesS point out, it would be pretty easy to distribute such a thing without the need for bogus emails or fancy malicious web page code. In my experience, not only are Mac users not immune to social engineering, they're often extremely susceptible to it. "Great new app to unlock your iTunes Music Store purchases!" That's all it would take...

I like suggestion #3 best of all. It would take less work to implement, be explicit enough for the user to figure out exactly what's asking for authentication, and provide enough extra information for troubleshooting and tracking. There's only one problem with all of the suggestions: what if the app requesting authentication is "UnlockITMS.app?" SURE! Unlock those songs for me! Another level of authentication, from the application side, is needed too.

[TETENAL]

Originally Posted by ghporter

Big Mac, I agree with your thesis and your statement above. It is unfortunate that most Mac users feel bulletproof and godlike because "there are no Mac viruses," while in fact it's only true that there are no Mac viruses in the wild at this time.

This scenoria is not a virus scenario, it's a trojan horse scenario. Nobody ever claimed the Mac is immune to trojans.

I like suggestion #3 best of all. It would take less work to implement, be explicit enough for the user to figure out exactly what's asking for authentication, and provide enough extra information for troubleshooting and tracking.

It's possible to replicate the collapsed authentification dialog, so it's possible to also replicate the expanded authentification dialog with (false) details informations. You don't even need to do this. Many applicatoins (like VISE-installers) use their own dialogs to ask for an admin password and people are willingly giving it away.

[steve626]

One advantage of the Mac OS X is that most "harmful" things require an administrator password (I have heard of exceptions to this but I think most or all have been closed off by the recent Security Updates). A non-administrator can basically destroy his/her own files (which can be restored from backups), but I think they will have a hard time harming the system itself.

I also have a non-statistical data point on the psychological aspect, namely my wife, who knows nothing about viruses, hackers or anything about computers frankly, except that she uses our old iMac G3 and she expects it to be working and flawless at all times. I performed a Quicktime update the other day and later when she opened Mail it requested permission to access her keychain (as often happens the first time after system or security updates) and she refused to type anything further until I was summoned down to inspect this "suspicious message."

My daughter (age 13) on the other hand does have administrator privileges on the computer she uses, and I worry a little about that but kids do remember simple rules, such as "never enter your administrator password except to log in" and she does consult me whenever her password is requested. There is more vulnerability with an administator user, but again, periodic backups and the built in safety measures of the Mac OS are a pretty good combination. She never installs anything without showing me first. The contrast with PCs is really pretty amazing -- the spyware and virus situation for them is pretty overwhelming (have a look at last month's PC Word). My daughter's friends have to take their PCs to a repair shop every month or two to be cleaned of this stuff, even though they try to keep up to date (daily) on patches and so forth. This happens just from going around the internet.

[ghporter]

Originally Posted by TETENAL

This scenoria is not a virus scenario, it's a trojan horse scenario. Nobody ever claimed the Mac is immune to trojans.

Unfortunately, to the vast majority of ANY kind of computer user, the difference between a virus and a trojan is moot. Most Mac users still feel bulletproof. Sad but true.

Originally Posted by TETENAL

It's possible to replicate the collapsed authentification dialog, so it's possible to also replicate the expanded authentification dialog with (false) details informations. You don't even need to do this. Many applicatoins (like VISE-installers) use their own dialogs to ask for an admin password and people are willingly giving it away.

This is a major part of the social engineering point-Mac users don't think critically about what may or may not need admin priveledges, so they give their password willy-nilly to anything that asks for it. Not enough people think about computer security to start with, and we Mac users are a trusting lot.

[loki74]

Originally Posted by ghporter

This is a major part of the social engineering point-Mac users don't think critically about what may or may not need admin priveledges, so they give their password willy-nilly to anything that asks for it. Not enough people think about computer security to start with, and we Mac users are a trusting lot.

This is why I say were lucky that there isn't much motivation to attack OSX. It's not that we're bulletproof, simply that there are less people shooting at us. And of course, the danger in that is that when someone does start shooting, we may be caught off guard.

In my layman's opinion, there is very little developers can do to protect their users from social engineering. Some tricks are very subtle and hard to catch, ie the stuation proposed by the OP. In cases like this, I suppose developers could try to make the trick easier to catch, ie the solutions proposed by the OP.

...but if you ask me--ultimately, it comes down to the user.

[TETENAL]

Originally Posted by ghporter

Unfortunately, to the vast majority of ANY kind of computer user, the difference between a virus and a trojan is moot.

You should know better though. What Big Mac described is by no means some vulnerability that it is particular to the Mac. It is simple a trojan that uses some social engineering to lure a password from the user. That is possible on any platform and there is no current technology that could avoid this. The vulnerability is not in the machine, it's in the man it operates. You could probably just use a telephone and people would give away their passwords.

This is a major part of the social engineering point-Mac users don't think critically about what may or may not need admin priveledges, so they give their password willy-nilly to anything that asks for it.

That's not limited to Mac users. I have seen Windows users who clicked away warning dialogs before they finished drawing.

[Big Mac]

Originally Posted by TETENAL

You should know better though. What Big Mac described is by no means some vulnerability that it is particular to the Mac. It is simple a trojan that uses some social engineering to lure a password from the user. That is possible on any platform and there is no current technology that could avoid this. The vulnerability is not in the machine, it's in the man it operates. You could probably just use a telephone and people would give away their passwords.That's not limited to Mac users. I have seen Windows users who clicked away warning dialogs before they finished drawing.

You're right, Tetenal, this type of vulnerability is specific to Mac users - social engineering can happen on any platform. ghporter's pointing out that Mac users have an insular attitude toward security because they have not been plagued by problems like PC users have. The thing is, I think I have identified a very real potential exploit that could prove terribly dangerous in the future if Apple does not take additional measures to protect users. The possible remedies I have suggested do not completely solve the problem, but they would go a long way to reducing the threat.

[TETENAL]

Originally Posted by Big Mac

The possible remedies I have suggested do not completely solve the problem, but they would go a long way to reducing the threat.

The suggestions you made make no difference at all.

Originally Posted by Big Mac

Suggested Alterations: 1. Make Security Agent's dialog a sheet instead of a dialog box so that its ownership by the requesting app is apparent.

If a trojan can display a faked authentification dialog, it can just as well display a faked authentification sheet.

Originally Posted by Big Mac

2. Use some type of internal system resource as a visual cue somewhere else on the screen to show that a security request is being made. (I just thought up a great possibility: a special padlock icon superimposed on the Dock icon of the requesting application.)

Applications can add what they want to their dock icons (see Mail for example). So trojans can add a padlock themselves when faking an authentification dialog.

Originally Posted by Big Mac

3. Make the disclosure triangle show details by default.

Trojans can show faked details by default as well.

[loki74]

Originally Posted by TETENAL

The suggestions you made make no difference at all.
If a trojan can display a faked authentification dialog, it can just as well display a faked authentification sheet.Applications can add what they want to their dock icons (see Mail for example). So trojans can add a padlock themselves when faking an authentification dialog.Trojans can show faked details by default as well.

Umm... I believe the trojan in the OP's scenario tries to make it look like another app is requesting authentication. As far as I know, one app cannot attach sheets or badge dock icons of another app. (I could be wrong. But either way I imagine doing this would be quite difficult)

Alternatively, the trojan could pretend to be an app and fake a request for authentication, but this would be much more difficult, as the attacker would have to mimick the entire app. They'd have to match the icon exactly, match the user's current prefs exactly...

IMO, the OP's suggestions are useful in that they make the attacker need to jump through more hoops.

[Big Mac]

loki completely understood and reinforced my point, so this reply is basically unnecessary. Nonetheless. . .

Originally Posted by TETENAL

The suggestions you made make no difference at all.
If a trojan can display a faked authentification dialog, it can just as well display a faked authentification sheet.Applications can add what they want to their dock icons (see Mail for example). So trojans can add a padlock themselves when faking an authentification dialog.Trojans can show faked details by default as well.

The trojan can display a spoofed authentication sheet, but that's so much better than displaying a spoofed authentication dialog box. With the sheet attached to the parent window, there's far less ambiguity about which application is requesting privileges. In addition, in order to spoof an authentication sheet, a malicious coder has to also spoof the normal window elements of the application it is mimicking. Less work needs to go into a spoofed dialog box, since it is not directly connected to a parent window. Sheets were invented to reduce user confusion over the ownership of dialog boxes, so does not it make perfect sense to use them in this case?

Secondly, sure applications can add whatever they want to their Dock icons, but you're missing the two-fold intent of my suggestion. For a trojan to display a spoofed padlock in the Dock, said trojan must show an icon there to being with - not many trojans are going to do that. Beyond that, if Apple were to code a nifty little animated padlock for Dock icons similar to the padlocks in windows that require authentication, it would be rather hard to reproduce that icon. (If the trojan is spoofing a trusted application, it's going to have to use the trusted application's icon and then manufacture a superimposed padlock thereon.) Moreover, as loki pointed out, malware is not going to be able to change the Dock icons of other applications, unless it can surreptitiously inject code.

At this point you could respond that the trojan author may as well not go to the trouble of spoofing Security Agent, since doing so would require more work than just using SecurityAgent like any regular application. And you would be mostly right - the objective here is to make it difficult to deceive users into thinking they're giving privileges to trusted apps through fake SecurityAgent dialogs. As loki stated, I want prospective trojan writers to jump through many more hoops in order to try to fool the user. Finally, my last suggestion - to show the full details of the authentication request by default - makes even more sense. If a trojan is going to forgo spoofing SecurityAgent and instead use it directly, then the full details definitely matter: Not only will they be much more trustworthy, they will also reveal exactly wherefrom the request is coming. In this scenario, if the app claims to be System Preferences and even spoofs visual features well, the details will show said app to be on your desktop. Wow, I really didn't expect this reply would grow to such lengths. Am I coming in loud and clear?

[CharlesS]

AFAIK, that wouldn't be possible with the current implementation. The auth panel is owned by the SecurityAgent application, not the application that invoked SecurityAgent, and it's not possible, as far as I know, to attach a sheet to another program's window.

Originally Posted by Big Mac

Beyond that, if Apple were to code a nifty little animated padlock for Dock icons similar to the padlocks in windows that require authentication, it would be rather hard to reproduce that icon. (If the trojan is spoofing a trusted application, it's going to have to use the trusted application's icon and then manufacture a superimposed padlock thereon.)

Actually, that's not that hard to do at all. NSImage has a bunch of compositing methods that make badging icons pretty easy.

[Big Mac]

I did consider that limitation, Charles, but I suspect Apple could devise a solution so that it could be a sheet. The cause for this assumption is the observation that currently, when a SecurityAgent dialog is shown, it is a modal dialog box that not only blocks regular interaction with the requesting application but also stops its event loop/event dispatch so that the requesting application beach balls. The SecurityAgent dialog box is also tied to its parent window to the extent that it is hidden from view if the window is looked at in Exposé mode. That means there is a special relationship between SecurityAgent and the requesting application; SecurityAgent is not simply passing messages to the requester. Open and Save dialogs are system services that usually appear as sheets, so why not SecurityAgent? I have not examined how SecurityAgent is invoked, but if it's through an API I don't see why it can't behave as other system services do. Anyway you would know better than I about the programming details, so I don't mean to contradict you - I just think it's possible.

Originally Posted by CharlesS

Actually, that's not that hard to do at all. NSImage has a bunch of compositing methods that make badging icons pretty easy.

Okay, that's interesting to know. I think the icon badge upon calling SecurityAgent would still be a good idea because applications using SecurityAgent would get it for free while those spoofing SecurityAgent would have to implement it themselves.

Here's another suggestion: Disallow authentication for applications launched from the desktop.

[tooki]

Well here's a question: What good does it do an app to collect the authentication info? I thought that to gain access, it has to go through SecurityAgent -- I thought the authentication credentials can't be passed to SecurityAgent.

I mean, I guess you could use it to run AppleScript or something...

tooki

[Sarc]

a spoof dialog that gets the admin password and then uses it to run a shell script for instance.

[CharlesS]

Originally Posted by Big Mac

I did consider that limitation, Charles, but I suspect Apple could devise a solution so that it could be a sheet. The cause for this assumption is the observation that currently, when a SecurityAgent dialog is shown, it is a modal dialog box that not only blocks regular interaction with the requesting application but also stops its event loop/event dispatch so that the requesting application beach balls. The SecurityAgent dialog box is also tied to its parent window to the extent that it is hidden from view if the window is looked at in Exposé mode. That means there is a special relationship between SecurityAgent and the requesting application; SecurityAgent is not simply passing messages to the requester.

The application is using a system API from the Security framework to ask for permission to launch a task as root. Those APIs fire up SecurityAgent and ask it to get that permission from the user, and block until it's done. So it's not really that special of a relationship - the program is just waiting until the authentication has been done by SecurityAgent.

Open and Save dialogs are system services that usually appear as sheets, so why not SecurityAgent? I have not examined how SecurityAgent is invoked, but if it's through an API I don't see why it can't behave as other system services do. Anyway you would know better than I about the programming details, so I don't mean to contradict you - I just think it's possible.

The thing is that the Open and Save dialogs come from the Carbon or Cocoa framework, but are still run inside the application itself. If you wanted to put up a Save dialog as a sheet in a Cocoa app (and you weren't using NSDocument, which would do all this stuff for you automatically), you'd ask the system for one by calling +[NSSavePanel savePanel], then you'd display it as a sheet by calling -[NSSavePanel beginSheetForDirectory:file:modalForWindow:modalDe legate:didEndSelector:contextInfo:]. All within the app. In contrast, SecurityAgent is a whole separate process, and anything it does is necessarily separate from your app.

Okay, that's interesting to know. I think the icon badge upon calling SecurityAgent would still be a good idea because applications using SecurityAgent would get it for free while those spoofing SecurityAgent would have to implement it themselves.

But that same logic would make your whole thesis moot, since applications using SecurityAgent would get the authentication panel for free, whereas those spoofing SecurityAgent would have to implement that panel themselves. And badging the icon is really a minor task - it would not take the trojan writer much time at all to implement. Spoofing the whole dialog box would probably be more involved (although still not that difficult!).

Here's another suggestion: Disallow authentication for applications launched from the desktop.

That would break just about every installer other than the standard .pkg installer (VISE, homebrewed installers, etc.) that a user downloads and tries to run from the Desktop. Now, you might argue that this is a good thing because VISE sucks but still it would be a real pain for users who didn't understand the rationale behind this. Besides, an app doesn't need admin privileges to move itself somewhere else besides the Desktop, like the home folder (or even the Applications folder if you're logged in as an admin), and then relaunch itself from there.

Originally Posted by tooki

Well here's a question: What good does it do an app to collect the authentication info? I thought that to gain access, it has to go through SecurityAgent -- I thought the authentication credentials can't be passed to SecurityAgent.

sudo.

[Big Mac]

Thank you for explicating the API situation.

Originally Posted by CharlesS

But that same logic would make your whole thesis moot, since applications using SecurityAgent would get the authentication panel for free, whereas those spoofing SecurityAgent would have to implement that panel themselves. And badging the icon is really a minor task - it would not take the trojan writer much time at all to implement. Spoofing the whole dialog box would probably be more involved (although still not that difficult!).

Right, I acknowledged that with these proposed changes it would be easier for malware authors just to use SecurityAgent like normal applications do rather than spoof it. But that's the whole point - we want to make it difficult enough to replicate SecurityAgent's UI features that it will take too much of an investment in time to imitate it. By forcing trojans to try to obtain legitimate authorization, the security model is strengthened. And then by having full details displayed by default, it will be that much easier to recognize a false request.

[CharlesS]

Originally Posted by Big Mac

Thank you for explicating the API situation.

Right, I acknowledged that with these proposed changes it would be easier for malware authors just to use SecurityAgent like normal applications do rather than spoof it. But that's the whole point - we want to make it difficult enough to replicate SecurityAgent's UI features that it will take too much of an investment in time to imitate it. By forcing trojans to try to obtain legitimate authorization, the security model is strengthened. And then by having full details displayed by default, it will be that much easier to recognize a false request.

Okay, just keep in mind that badging an icon is not going to be an investment of time by any stretch of the imagination.

[sniffer]

That way you'll have to boot up and let the program run before you can authorize it. I think the current model is better. It halts the program if it doesn't have the right privileges, even if it's a shady background program or System Preferences, you'll get a standard privileges box. You can't predict the format if every second developer brings their own sheets.

[Big Mac]

Originally Posted by sniffer

That way you'll have to boot up and let the program run before you can authorize it. I think the current model is better. It halts the program if it doesn't have the right privileges, even if it's a shady background program or System Preferences, you'll get a standard privileges box. You can't predict the format if every second developer brings their own sheets.

I don't know what you mean, sniffer. You do launch programs and let them run before they ask for authentication. But you're right that we definitely don't want each developer using custom sheets for authentication. I am just asking if the SecurityAgent dialog box could be turned into a sheet so that it's obvious which app is making the request. If there is no way to make it a sheet within the current model, as Charles indicates, or if making it a sheet would compromise security, then it's not a viable suggestion. The whole point is, currently the ownership of SecurityAgent dialogs is relatively ambiguous, and we can clearly envision how the situation could be exploited in the future.

[Millennium]

The exploit you mention is a real possibility. There is a way to prevent it, however, and it's actually one which the US government requires for one of its security classifications (either C2 or C1; I forget which).

If you've ever seen Windows NT (or its descendants: 2K, XP, or 2k3) properly configured, then you'll notice that you have to press CTRL-ALT-DELETE before they can input the password. This key sequence is what's known as a non-maskable interrupt. Programs cannot intercept it and perform their own stuff; only the operating system can do that. If a program asked a user to press that key sequence and the user did it, then the machine will go into the Task Manager, not the password dialog, and this would cue to the user that something was wrong.

Of course, XP allows this feature to be turned off, and doesn't actually require it by default nowadays, so it's useless for most. However, OSX could do something similar with another keystroke sequence, like Cmd-Opt-Escape or Cmd-Ctrl-Eject or possibly something else. If it did this, then you wouldn't be able to fake the password dialog, because you couldn't trap the key sequence. Apple could even make the key sequence so that outside of the Security Manager dialog it displays a dialog saying "If an application just asked you to press these keys, do not supply it with any passwords". This would be a much better cue than what Windows has, as it would tell the user in no uncertain terms that something was wrong.

[jasong]

Great, except what happens if a dialog asks for your password and doesn't tell you to hit the key sequence. I imagine a large proportion of people will enter their password anyway. It's one to institute this kind of system in a security situation where the users are trained and controlled, it's quite another to try and make this work at home.

[Big Mac]

Originally Posted by Millennium

The exploit you mention is a real possibility. There is a way to prevent it, however, and it's actually one which the US government requires for one of its security classifications (either C2 or C1; I forget which).

If you've ever seen Windows NT (or its descendants: 2K, XP, or 2k3) properly configured, then you'll notice that you have to press CTRL-ALT-DELETE before they can input the password. This key sequence is what's known as a non-maskable interrupt. Programs cannot intercept it and perform their own stuff; only the operating system can do that. If a program asked a user to press that key sequence and the user did it, then the machine will go into the Task Manager, not the password dialog, and this would cue to the user that something was wrong.

Of course, XP allows this feature to be turned off, and doesn't actually require it by default nowadays, so it's useless for most. However, OSX could do something similar with another keystroke sequence, like Cmd-Opt-Escape or Cmd-Ctrl-Eject or possibly something else. If it did this, then you wouldn't be able to fake the password dialog, because you couldn't trap the key sequence. Apple could even make the key sequence so that outside of the Security Manager dialog it displays a dialog saying "If an application just asked you to press these keys, do not supply it with any passwords". This would be a much better cue than what Windows has, as it would tell the user in no uncertain terms that something was wrong.

Thank you for the info, Millennium. Sounds pretty great. I briefly thought about the way NT/2000 uses control+alt+delete but discarded it as a suggestion because I think it would be too jarring for most Mac users, if required by default. Heck, so many members of MacNN complain about having to authenticate in the current manner - just imagine the outcry over this arrangement. But, if I understand correctly, the way authentication would work is the current SecurityAgent dialog box would instruct the user to perform a keystroke that would invoke an NMI, then the user would enter his or her password, click okay and be returned to the regular workspace? It would be great if Apple offered that higher level of security, but I'm pretty sure it would have to be turned off by default to not thoroughly confuse the average user. You know, OS X really should have a "keyboard NMI" and low-level activity monitor interface anyway, for those rare cases when escaping Quartz is necessary.

Originally Posted by jasong

Great, except what happens if a dialog asks for your password and doesn't tell you to hit the key sequence. I imagine a large proportion of people will enter their password anyway. It's one to institute this kind of system in a security situation where the users are trained and controlled, it's quite another to try and make this work at home.

Users could easily be tricked into doing just that - after all, some detestable installers bypass SecurityAgent altogether. But in general users should be taught to trust the standard authentication interface and suspect all others. Millennium's suggestion would be the strongest option available, but I still think the regular authentication routine should be on by default and strengthened in the ways we've outlined.

[CharlesS]

Yeah, unfortunately this is one of the areas where Microsoft actually has a pretty decent solution. A non-escapable key sequence like that is probably one of the only ways to really protect against this.

[IamBob]

It is possible to put up sheets/dialogs (and generally run whatever code you want) *inside* other running programs. There's no need to fake System Preferences when you can get your code loaded into it with a plugin. We've been over this before but I still haven't seen it done.

All it would take is to get the user to run something, once. Make a cutsy game, a System Utility, whatever - it could even be attached to "crack-installers" for expensive software (bug the pirates, anyone..?).

From there you can install your plugin in their user account (even if you can't get /Library yet). Have your bundle load into System Preferences (again, 'for instance') where it waits for the user to select, say, Network..your code pops up the authentication dialog(/theoretical sheet) and the user just follows along so <they think> they can modify stuff. Even if they notice something fishy along the way they'll most likely have already submitted the name/pass if they've haven't gotten the admin who may/may not provide it.

Present the dialog at the right time and mimic it well enough and you'll get some machines. Even from the experienced crowd, I bet.

[loki74]

Well really, there isn't any way to make this type of exploit impossible. Social engineering will, in my opinion, never be totally defeated.

At any rate, to IamBob--you make it sound pretty simple to put a sheet into System Preferences. How difficult is it compared to just making a fake dialog as in the OPs original scenario? If it is any more difficult or requires any more knowledge, I think that this partial solution may be worth implementing. Since we can't make the exploit impossible, we may as well do our best to make it as difficult as we can.

=========

I would agree also that a key sequence would be a nice feature, but should be optional to the user. I know that may sound silly, but frankly, I wouldn't want to have to make a keystroke before each login etc unless I knew that such an exploit was floating around.

[Chuckit]

Putting a sheet into System Preferences would not be significantly more difficult than putting up a dialog — you have to have your program running in one case, while you have to have your prefpane loaded by System Preferences in the other case. Those are the only major roadblocks to either route, and I'd say they're about equal.

[Big Mac]

Originally Posted by CharlesS

Yeah, unfortunately this is one of the areas where Microsoft actually has a pretty decent solution. A non-escapable key sequence like that is probably one of the only ways to really protect against this.

M$ has a good solution, but it's worthless to most Windows users because the OS is set to be insecure by default. And with our luck Apple would copy that aspect of Windows.

[ghporter]

Originally Posted by Big Mac

M$ has a good solution, but it's worthless to most Windows users because the OS is set to be insecure by default. And with our luck Apple would copy that aspect of Windows.

Too true! Windows XP defaults to being "friendly" and not requiring a login at all. Further, by default every new user is an admin!!!!! You have to actively change the new user to a "limited user" if you use the "user friendly" user manager tool. And even though Computer Management gives you a lot more flexibility and power, it is less "friendly" and takes a bit of thought to manage. It would be very good for the whole world if MS managed to actually think about real world deployment of consumer computers and built the defaults to be secure instead of friendly. I don't want friendly. I want a system that is hard to make insecure. Fortunately, by default OS X is fairly secure and it's pretty easy to make more secure if the user wants to. Unfortunately, most Mac users want friendly...

[mduell]

Originally Posted by tooki

Well here's a question: What good does it do an app to collect the authentication info? I thought that to gain access, it has to go through SecurityAgent -- I thought the authentication credentials can't be passed to SecurityAgent.

I mean, I guess you could use it to run AppleScript or something...

Delete other users data?
Most people seem to fear malware destroying their system; in my opinion destroying the users data is much worse. And you don't need any additional privileges to delete the contents of your home directory.

Social engineering is the easiest way in; talk to Mitnick about that one.

[Tesseract]

Originally Posted by mduell

Delete other users data?
Most people seem to fear malware destroying their system; in my opinion destroying the users data is much worse. And you don't need any additional privileges to delete the contents of your home directory.

Agreed. The "the system must be protected but who cares what a user does to her own data" mentality made sense back when reinstalling an OS meant taking down a mainframe or mini for days/weeks, and there wasn't malware floating around on a public Internet.

Now, I can reinstall my OS and apps pretty easily if necessary. I care a lot more about the data in my home directory, and the Unix permissions scheme will not protect that from a virus, trojan, or whatever.