Would you have been less confused if I'd written... clicked on the "Infect Me" button...? The stuff inside the "..." is an example... different buttons say different things, depending on the application.
Anyway, if you're going to accuse me of "making shit up", I'll bow out. Ciao.
"Yes," is not an action. Actions are verbs or active phrases.
You're looking at the wrong thing.
"Yes" isn't what's on the button. "Yes" is "whatever button approves the action".
There's all kinds of things on the button.
Including "Open" and other "active phrases". The training doesn't depend on the layout or the details of the button. Muscle memory takes over. It happens on the Mac with its much more common (though not universal) "active phrases". That's why some apps are now moving the buttons around, so you can't memorise which one's where and you have to stop and think. That's why on the Mac you don't have dialog boxes popping up when you throw files into the trash, like you do on Windows, because routine "are you sure?" dialogs (no matter how they're worded) get ignored.
Stopping and thinking is the key, not what you're stopping and thinking about.
Ahh, you're talking about the old vulnerabilities, not exploits.
There were example exploits for all three of these cases, and they're not "old vulnerabilities", they're the same vulnerability that's still in the system: Safari's use of LaunchServices to open untrusted documents.
In any case to take the most recent example, it automatically ran a script in the terminal. That script should have been sandboxed
It ran a script in the shell using the Terminal as the mechanism to get to the shell. It did that because Safari used LaunchServices to open the ZIP (which used BOMArchiver) then it used LaunchServices again to open the file. That's three mistakes:
1. It automatically unpacked a document. 2. It automatically opened the content of the document. 3. It used LaunchServices to open it.
If any of these steps had been blocked, there wouldn't have been a way to get Terminal to open the document in the shell. The third step is the one that's common between the exploits I'm talking about.
There is commercial applications that want more permission to do things than users want (like randomly calling home and sending unknown data). And there are traditional worms and viruses that auto-install themselves through some hole in the firewall or service. All of these are executing code that would be a lot better for the user if it was in a sandbox.
If the commercial application is in a sandbox, then all the data that application uses and needs is in the sandbox, which means that things that matter to the user are still exposed to compromise.
And on top of that, now the user has to keep track of which sandbox which applications are in, and manage even more complexity.
You're better off forgetting that scheme, and go straight to an OS with mandatory access control, and give every application a classification group, rather than trying to reverse-engineer one by playing games with jails and discretionary access control.
You're being naive. The internet has grown up and a lot of people have seen how much money there is to be made.
That just means that education requires more effort. Education is still possible, if you use applications that give people a chance to learn. I've used this strategy with great success over the past decade and a half... it really works.
Out of 150 users:
Maybe a dozen have had problems with auto-downloaded files and clicking "open" when they shouldn't. None have done it twice.
Three or four have downloaded and opened files manually.
Two have problems with repeat-approvals. But even thewe two have managed to avoid downloading and opening a file more than once.
Only one of these two has a problem with spyware.
Passing shareware around is no longer the dominant mechanism for distribution. You don't send people applications in mail, you mail or IM them the website. There's no reason for people to engage in any activity that will lead them to get infected without deliberately downloading and unpacking an unsolicited attachment or document.
Macs still would not break the 3% market share barrier.
I do tech support and system administration. I already know 97% of the people out there shuldn't be trusted with anything more complex than a four-function pocket calculator... and on my bad days I suspect they'd be in trouble with more than a piece of soft wool to tie around their counting finger to help them remember which one to count with.
And it does it for.dmg files too, so those could be exploited as easily as.zip or.sit.
So... since, as has been demonstrated elsewhere, you CAN slide exploits in theough DMG files that don't involve Terminal. So... disable "Open Safe Files" and leave it disabled. And do the same thing for Camino, heed the warning Cemino puts under that option: it's NOT something you should be doing.
By the way:
Then, it tries to make.sit or.zip files act like Internet-enabled DMG files -- it extracts the contents and deletes the original archive file.
Why does ANYONE think this is a good idea? The idea of downloading a ZIP file and having it replaced with the contents is utterly abhorrent to me. I archive the applications I download so I have a good copy of the original if I need to reinstall it, and I keep the downloads compressed to save space.
I automatically turned off "Open Safe Files" for security, now I'm glad I avoided the inconvenience of the insecurity as well!
The problem isn't that they can hide, it is that they can overwrite/modify commonly used and trusted applications and user settings.
They don't need to be able to write to/Applications or/Library for that, they can do it all from ~/Library/InputManagers or any number of other locations in the user's own account. Changing the permissions on/Library or/Applications won't change that.
I agree they should have tighter permissions there, but for a single-user system there's really no difference to the exposure from/Applications or ~/Library.
Apple's HIG and most anyone with a clue will tell you that you need to provide buttons that are actions, thus the user has to read them and can't be conditioned to act on reflex.
I didn't say they clicked "OK", I said they clicked "yes". That "yes" could be (and IS) just as often an action (like "Open") as not.
They all involved new executables launching.
No, the first LaunchServices failure was in 2004, and involved the Help viewer. The second, a year later, involved the "x-man-page" URI, which should NEVER have been in the list of URIs that Safari used. The latest one involved Terminal, and could just as easily have used another script-capable application.
ALL these applications and URIs were Apple's, not new applications.
If the average user wants to play a game they need the ability to do that without gambling that it won't compromise their system.
No, they would like that ability, but I can't see any way to give it to them without radically changing the way modern games work. They need network access, they need significant amounts of persistant storage. They need to be able to download and install updates. Taking that away is just not going to happen.
And, historically, the only time that there has been a problem with viruses embedded in games (or any other applications) been in the BBS era, when files were downloaded and uploaded to BBSs and the user was part of the distribution scheme for shareware.
Today, the only apps you get that way that aren't otherwise verified and checksummed are pirated games on peer-to-peer networks, and it's easy enough for the user to avoid that. People who download files from the original author's site don't have that problem. If the file is infected, then they KNOW where it came from.
Get rid of automatic execution paths that can get code injected into them, and reduce the problem to education, and the virus problem will remain, at worst, no worse than it was in the early '90s for people who didn't share files on BBSes... that is, basically non-existent.
The first account you create is an administrator. It can do a number of things without being prompted for a password that regular users cannot. This includes writing to the global Applications and Library folders, which one of the recent pieces of malware (Leap_A) takes advantage of
1. chmod -R g-w/Applications;...
This isn't an "Administrator" problem, this is a "default permissions are too wide open" problem.
2. That's not as significant a problem as it seems, because there's plenty of places an application without write access to/Applications or/Library can hide.
That does not mean a "game" you download from the internet should be granted these privileges by default. New applications should placed in a jail or VM and only granted any of the above privileges after the user is asked.
This is the same "last minute" security that Microsoft has attempted to use for years and failed miserably at. The main thing it does is condition people that when they do stuff on their computer, it brings up annoying dialog prompts all the time, and you need to approve stuff. These "false positives" on Windows happen far too often, and I can't tell you the number of times I've had to repair or re-image somone's computer because they'd automatically clicked "yes" by reflex.
And, in any case, this wouldn't have helped prevent ANY of the three failures of Safari's use of LaunchServices, because none of these attacks involved new applications. The place to prevent automatic attacks is where they're being allowed to start: in "Open Safe Files", in Microsoft's "Active Content" and "Security Zones", in CGI scripts calling system() or passing unescaped strings to SQL. Create safe mechanisms for applications to use with untrusted content and reduce the problem to a human education one.
Because before ActiveX that's what it was, and malware was a fraction of the problem it became even a year later.
When trojans become the most common type of attack users will need more control
When trojans were almost the only type of attack users needed self-control, and the way to create it isn't to bombard them with pointless fire drills... it's to shut down ANY mechanism designed to be "helpful" by auto-executing anything except plugins and helpers designed for security through a secure path.
Things like jails and improved permissions are useful, but by the time they're necessary the battles more than half lost.
You still need to be aware that in Mac OS X the icon associated with a file can be overwritten in other file formats. Just opening a.sit or.dmg file won't run the embedded application (it was the combination of BOMArchiver and Safari that caused that to happen) but the icons you see may not be correct.
In Finder, "show all file extensions" under advanced preferences (this is a pretty important security policy in Windows as well), and don't open files from untrusted sources directly, select "open with" or drag them to an application on the desktop or dock.
An installer that configures an admin user and does not prompt the user to create a regular user account is a security hole.
The Mac OS X "admin" user is a regular user account, it's nothing like "Administrator" on Windows or "root" on UNIX. Unless you SU to a real admin account (which is what you're doing when you type in your password to a security dialog) the OS doesn't give you any more rights than any other user.
Default permissions for new applications that permit them to modify existing applications without warning are a security hole.
The default permissions for new applications give them no more rights than the user running them.
If the OS was attempting to provide mandatory access control rather than discretionary access control, these would be security holes. But as you noted, MAC is vanishingly rare, and there's a good reason for that.
At the moment, I'm running OS X in a Managed user w/all but Terminal enabled 'just in case' I open a dodgy zip
That's silly. If you turn off "Open Safe Files" and switch to something other than BOMArchiver for opening Zip archives then you'll be safe from attacks through other applications that have similar capabilities, AND you won't lose Terminal.
Terminal isn't the problem.
Safari and LaunchServices are the dysfunction siblings that cause the problem. There's not much you can do about LaunchServices, other than avoiding the REAL application that's being exploited (BOMArchiver), but you can keep Safari from hurting you pretty easily.
I'd recommend installing Stuffit Expander but ONLY enable it for "zip", and turn off "Open Safe Files By Default", and quit worrying about the BOM.
Then a few are found when they are exploited in the wild by hackers.
As far as I know the only exploits in the wild involving OS X have been social engineering attacks... trojan horses convincing people to execute programs. These aren't security holes.
There are a few security holes that Apple has been reluctant to fix, maybe this time they'll be convinced to bite the bullet before someone DOES create an automated worm with them.
I think that the main reason OS/X (and *nix for that matter) was considered to be rock-solid is because very few people were taking shots at it.
Apache on UNIX has 3-4 times the webserver market share of IIS.
last time I checked, IIS was still getting twice the number of defaced sites as Apache.
A computer is only as secure as its maintainer.
A computer is only as secure as its maintainer can make it. There are holes in Windows that take heroic measures to completely close, that are closed by default or can't even be created on UNIX-based systems.
Well, it's been almost two years and Apple's still sitting on the fix for the LaunchServices problems.
But then Microsoft's going for TEN years of not fixing their corresponding (and much more serious and harder to fix) design flaw, so Apple's not doing so bad.
So far the only actual damage I'm aware of caused by any of these trojan-horse worms on OS X has been caused by antivirus software incorrectly identifying uninfected files as them.
Similarly, the only cases I know of where malware has actually caused data-loss on Palms or Pocket PCs is where anti-virus software itself caused a problem or led to an overreaction after a false positive.
The most effective anti-virus software we've used on Windows has been Netscape. And we've lost more man-hours to problems caused by AV software than to trojan horses that people using Netscape have been convinced to download and open. IE is a different kettle of security holes, of course...
If Apple's approach to security in Safari was the same as UNIX's, then this would have been fixed two years ago.
You can't secure against user stupidity except by scanning each file that they try to execute for viruses.
You can discourage user errors by giving users time to consider before acting, and by giving applications a safe mechanism for opening helpers.
Opening untrusted documents automatically from a web browser using a mechanism that can potentially run any application on the system is something I've come to expect from Microsoft. It's not something Apple should be doing.
Unfortunately, they seem to be emulating Microsoft this time around. This is the third strike, and they patched the symptoms rather than the hole the last two times.
Although Apple is largely responsible for causing these security flaws, it is hardly something that can be avoided in a modern consumer oriented OS such as Mac OS X.
Yes, it bloody well can.
A key part of this attack should have been closed almost two years ago but Apple 'fixed' the wrong thing.
And they knows there's a problem with LaunchServices, because in Tiger they allow you to override the types of files Safari considers "safe"... unfortunately they still use the LaunchServices database which leaves the "injection" problem intact.
So... Apple can fix these problems. Secure approaches are well known, and have been known for longer than Apple has existed as a company, and they know the problems exist. Why do they leave this hole open? I don't know, possibly because Microsoft does?
So now I am wondering, how necessary is security software if you're not a total moron?
The CHM hole on Windows worked for Mozilla-based browsers.
The first LaunchServices hole on Mac OS X worked for Mozilla-based browsers.
Both of these were caused by an insecure application being automatically passed untrusted content by the browser using a desktop API to find helper applications.
These kinds of attacks do not require user intervention, and can only be prevented by avoiding the Desktop equivalent of system("Infect Me Harder");.
there are OS vulnerabilities and application vulnerabilities.
And this is an OS vulnerability. On Mac OS X, LaunchServices is an OS component. It's the normal way to launch GUI applications, including helper applications from web browsers, like the shell in UNIX is the normal way to run command line applications. In UNIX, though, applications that have security concerns don't (or shouldn't... you do see apps breaking this rule from time to time) call the shell to run applications... they fork() and exec() the desired application directly... because the shell's behaviour isn't controllable or fully predictable.
LaunchServices has many of the same problems. UNFORTUNATELY, there's no general "safe" way to open documents on OS X. It's possible to securely open applications if you know the right application, but it's more complex than just fork/exec, and you have to deal with the difference between old-style Carbon apps and Cocoa appdirs... so Safari and other programs use LaunchServices.
The lack of a "secure applications only" equivalent to LaunchServices is an OS vulnerability. One that must be fixed (alas, Apple didn't fix it the last two times around).
That's half of a solution, but it would still leave the original hole open.
The Finder should implement an icon overlay showing that a file is executable.
That would be useful, but it would still leave the original hole open.
The first time the system runs ANY new executable that has not been run before, it pops up a warning window [...]
That's a REALLY bad idea, and it would still leave the original security hole open.
NEITHER of the other two demonstrated exploits, using URIs rather than file names, would have been prevented by this approach. In fact the second showed up after Apple implemented pretty much that approach for URIs.
It also would not have prevented this attack, because LaunchServices didn't open the executable... the shell did, and there are variations on this attack that don't require the script used in the attack to be executable.
As to why it's a bad idea... well, Microsoft has been trying to use the same "trying to detect whether an attack is underway at the last minute" approach since 1997. All it's done is teach people that the system comes up with stupid dialogs on a regular basis, so you just gotta approve them and go on if you want to keep working.
I've been supporting 150-400 people on Windows for over a decade now, and I've regularly had people come up to me, the same people... over and over again... telling me that they'd clicked on the wrong button in a dialog box and gotten infected. false positives from these kinds of last-minute checks are always going to be so much more numerous than valid alarms that all you're doing is adding noise to the user experience.
The right solution is to keep the attack at arms length and let the user at his own time make the decision. Popping up a routine and routinely approved dialog isn't giving the user time to do the right thing, it's encouraging a snap decision and that's bad user interface design.
1. Turn off "Open Safe Files After Downloading" by default. 2. Create a separate database of "Safe Applications". ONLY use these from web pages viewed in Safari or any other document from applications that deal with untrusted documents. 3. Don't put any kind of installer, disk image mounter, or archive extractor in that database.
Apple had the advantage of seeing what was already happening to Windows when they made their decisions about how OS X would be designed, plus the system it was derived from was pretty robust to begin with.
It's a pity Apple hasn't been paying more attention.
Two years ago, Apple got bit by Safari's blind trust of LaunchServices, at the same time Microsoft got hit by a hole in almost the same application on Windows. Instead of going "oh, maybe Safari shouldn't use the same database for finding helpers as desktop applications do", they went "oh, maybe the helper app database should try and guess if it's being used by an exploit".
That's the same kind of decision Microsoft made in the '90s when they came up with "Active Content" and "Security Zones", and it didn't work for them then. Microsoft isn't likely to back out of that, but, damn, Apple should have noticed what a big blunder that was.
Switching to an API that Microsoft controls and can create incompatible extensions for, instead of one where the company that controls it is at least TRYING to maintain compatibility. That sounds like a winning approach.
If it was even primarily market share the number of worms, viruses, and other malware for Windows should have been higher through the '90s, and followed a continual upward curve against a matching downward curve for Macs. but that didn't happen... instead, after 1997 there was a sudden massive surge in Windows worms and other exploits. This surge is correlated with and caused by the introduction of what was then called "Active Desktop".
Buffer overflows and the occasional string injection, these can be found on any browser and any OS, and can be quickly fixed without breaking working code. Social engineering attacks, these used to be the majority of worms... before Active Desktop if you were savvy to them keeping your eyes open was pretty much enough. Trojan horses, viruses hiding in innocent downloads, they became increasingly rare as the Web meant that people weren't passing shareware around on BBSes and maintaining "upload quotas" to keep their downloads working. Peer-to-peer brings that kind of thing back, but it's no longer the main distribution mechanism for shareware.
So, really, we should have relatively fewer virus problems now. People are getting more familiar with computers, and few people are caught out more than once by a worm hiding in an email message if they have a chance to think about the attachment, if they download it and then open it in their own time.
But something happened.
Back in the early '90s there was this joke going around the net about a virus that was so clever it would run if you just READ an email message! Everyone knew it was a joke, because NOBODY would be so stupid as to write an email program that let you do that, or if they did they'd back out of that as quick as the "WIZARD" hole was backed out of sendmail.
then came Active Desktop, Active X, Active Content, a web browser and an email program that both used a display technology that was designed to download and run software without user intervention. I was horrified. I didn't know exactly what was going to happen, but I expected something nasty. And boy were my expectations fulfilled. Dozens, then hundreds, then thousands of of attacks, and Microsoft didn't back it out! And it's still in there, and still used by spyware and viruses to sneak into people's machines without the user actively doing anything... at the most they may have to click a button on a dialog box that looks pretty much like the ones that come up regularly and have to be clicked away...
The fundamental problem, the thing that makes Windows so terribly attractive to virus writers, is that it's got this big "infect me harder" capability built in to the core of the OS that you can't remove or even fully disable.
This is so much easier than even the weaker versions of the same problem in Safari and Firefox are trivial by comparison. If the UNIX (Linux&OSX) desktop market share was 50% instead of 5% you'd still have orders of magnitude more viruses on Windows than Macs... because it's so much easier a target. Even if you turned off ALL the internal security and ran as "root" with no password, the "Security Zones" hole is so much deeper and harder to close that there's still no contest.
Slashdot Mirror
Would you have been less confused if I'd written ... clicked on the "Infect Me" button...? The stuff inside the "..." is an example... different buttons say different things, depending on the application.
Anyway, if you're going to accuse me of "making shit up", I'll bow out. Ciao.
"Yes," is not an action. Actions are verbs or active phrases.
You're looking at the wrong thing.
"Yes" isn't what's on the button. "Yes" is "whatever button approves the action".
There's all kinds of things on the button.
Including "Open" and other "active phrases". The training doesn't depend on the layout or the details of the button. Muscle memory takes over. It happens on the Mac with its much more common (though not universal) "active phrases". That's why some apps are now moving the buttons around, so you can't memorise which one's where and you have to stop and think. That's why on the Mac you don't have dialog boxes popping up when you throw files into the trash, like you do on Windows, because routine "are you sure?" dialogs (no matter how they're worded) get ignored.
Stopping and thinking is the key, not what you're stopping and thinking about.
Ahh, you're talking about the old vulnerabilities, not exploits.
There were example exploits for all three of these cases, and they're not "old vulnerabilities", they're the same vulnerability that's still in the system: Safari's use of LaunchServices to open untrusted documents.
In any case to take the most recent example, it automatically ran a script in the terminal. That script should have been sandboxed
It ran a script in the shell using the Terminal as the mechanism to get to the shell. It did that because Safari used LaunchServices to open the ZIP (which used BOMArchiver) then it used LaunchServices again to open the file. That's three mistakes:
1. It automatically unpacked a document.
2. It automatically opened the content of the document.
3. It used LaunchServices to open it.
If any of these steps had been blocked, there wouldn't have been a way to get Terminal to open the document in the shell. The third step is the one that's common between the exploits I'm talking about.
There is commercial applications that want more permission to do things than users want (like randomly calling home and sending unknown data). And there are traditional worms and viruses that auto-install themselves through some hole in the firewall or service. All of these are executing code that would be a lot better for the user if it was in a sandbox.
If the commercial application is in a sandbox, then all the data that application uses and needs is in the sandbox, which means that things that matter to the user are still exposed to compromise.
And on top of that, now the user has to keep track of which sandbox which applications are in, and manage even more complexity.
You're better off forgetting that scheme, and go straight to an OS with mandatory access control, and give every application a classification group, rather than trying to reverse-engineer one by playing games with jails and discretionary access control.
You're being naive. The internet has grown up and a lot of people have seen how much money there is to be made.
That just means that education requires more effort. Education is still possible, if you use applications that give people a chance to learn. I've used this strategy with great success over the past decade and a half... it really works.
Out of 150 users:
Maybe a dozen have had problems with auto-downloaded files and clicking "open" when they shouldn't. None have done it twice.
Three or four have downloaded and opened files manually.
Two have problems with repeat-approvals. But even thewe two have managed to avoid downloading and opening a file more than once.
Only one of these two has a problem with spyware.
Passing shareware around is no longer the dominant mechanism for distribution. You don't send people applications in mail, you mail or IM them the website. There's no reason for people to engage in any activity that will lead them to get infected without deliberately downloading and unpacking an unsolicited attachment or document.
EXCEPT that the p
Macs still would not break the 3% market share barrier.
I do tech support and system administration. I already know 97% of the people out there shuldn't be trusted with anything more complex than a four-function pocket calculator... and on my bad days I suspect they'd be in trouble with more than a piece of soft wool to tie around their counting finger to help them remember which one to count with.
You don't have to reinforce the idea any further.
(though... have you checked lately?)
And it does it for .dmg files too, so those could be exploited as easily as .zip or .sit.
.sit or .zip files act like Internet-enabled DMG files -- it extracts the contents and deletes the original archive file.
So... since, as has been demonstrated elsewhere, you CAN slide exploits in theough DMG files that don't involve Terminal. So... disable "Open Safe Files" and leave it disabled. And do the same thing for Camino, heed the warning Cemino puts under that option: it's NOT something you should be doing.
By the way:
Then, it tries to make
Why does ANYONE think this is a good idea? The idea of downloading a ZIP file and having it replaced with the contents is utterly abhorrent to me. I archive the applications I download so I have a good copy of the original if I need to reinstall it, and I keep the downloads compressed to save space.
I automatically turned off "Open Safe Files" for security, now I'm glad I avoided the inconvenience of the insecurity as well!
The problem isn't that they can hide, it is that they can overwrite/modify commonly used and trusted applications and user settings.
/Applications or /Library for that, they can do it all from ~/Library/InputManagers or any number of other locations in the user's own account. Changing the permissions on /Library or /Applications won't change that.
/Applications or ~/Library.
They don't need to be able to write to
I agree they should have tighter permissions there, but for a single-user system there's really no difference to the exposure from
Apple's HIG and most anyone with a clue will tell you that you need to provide buttons that are actions, thus the user has to read them and can't be conditioned to act on reflex.
I didn't say they clicked "OK", I said they clicked "yes". That "yes" could be (and IS) just as often an action (like "Open") as not.
They all involved new executables launching.
No, the first LaunchServices failure was in 2004, and involved the Help viewer. The second, a year later, involved the "x-man-page" URI, which should NEVER have been in the list of URIs that Safari used. The latest one involved Terminal, and could just as easily have used another script-capable application.
ALL these applications and URIs were Apple's, not new applications.
If the average user wants to play a game they need the ability to do that without gambling that it won't compromise their system.
No, they would like that ability, but I can't see any way to give it to them without radically changing the way modern games work. They need network access, they need significant amounts of persistant storage. They need to be able to download and install updates. Taking that away is just not going to happen.
And, historically, the only time that there has been a problem with viruses embedded in games (or any other applications) been in the BBS era, when files were downloaded and uploaded to BBSs and the user was part of the distribution scheme for shareware.
Today, the only apps you get that way that aren't otherwise verified and checksummed are pirated games on peer-to-peer networks, and it's easy enough for the user to avoid that. People who download files from the original author's site don't have that problem. If the file is infected, then they KNOW where it came from.
Get rid of automatic execution paths that can get code injected into them, and reduce the problem to education, and the virus problem will remain, at worst, no worse than it was in the early '90s for people who didn't share files on BBSes... that is, basically non-existent.
Previously, you could compile the source for either PPC or x86. Does the source listed under PPC not compile for x86 ?
As near as I can tell from the article, no.
The first account you create is an administrator. It can do a number of things without being prompted for a password that regular users cannot. This includes writing to the global Applications and Library folders, which one of the recent pieces of malware (Leap_A) takes advantage of
/Applications; ...
/Applications or /Library can hide.
1. chmod -R g-w
This isn't an "Administrator" problem, this is a "default permissions are too wide open" problem.
2. That's not as significant a problem as it seems, because there's plenty of places an application without write access to
That does not mean a "game" you download from the internet should be granted these privileges by default. New applications should placed in a jail or VM and only granted any of the above privileges after the user is asked.
This is the same "last minute" security that Microsoft has attempted to use for years and failed miserably at. The main thing it does is condition people that when they do stuff on their computer, it brings up annoying dialog prompts all the time, and you need to approve stuff. These "false positives" on Windows happen far too often, and I can't tell you the number of times I've had to repair or re-image somone's computer because they'd automatically clicked "yes" by reflex.
And, in any case, this wouldn't have helped prevent ANY of the three failures of Safari's use of LaunchServices, because none of these attacks involved new applications. The place to prevent automatic attacks is where they're being allowed to start: in "Open Safe Files", in Microsoft's "Active Content" and "Security Zones", in CGI scripts calling system() or passing unescaped strings to SQL. Create safe mechanisms for applications to use with untrusted content and reduce the problem to a human education one.
Because before ActiveX that's what it was, and malware was a fraction of the problem it became even a year later.
When trojans become the most common type of attack users will need more control
When trojans were almost the only type of attack users needed self-control, and the way to create it isn't to bombard them with pointless fire drills... it's to shut down ANY mechanism designed to be "helpful" by auto-executing anything except plugins and helpers designed for security through a secure path.
Things like jails and improved permissions are useful, but by the time they're necessary the battles more than half lost.
You still need to be aware that in Mac OS X the icon associated with a file can be overwritten in other file formats. Just opening a .sit or .dmg file won't run the embedded application (it was the combination of BOMArchiver and Safari that caused that to happen) but the icons you see may not be correct.
In Finder, "show all file extensions" under advanced preferences (this is a pretty important security policy in Windows as well), and don't open files from untrusted sources directly, select "open with" or drag them to an application on the desktop or dock.
Can't you just set the permissions on mshtml.dll to deny?
Not without installing dozens of freeware and shareware apps to replace the bits of the OS that don't work because they depend on the HTML control.
What I want is to not have to break stuff to get normal levels of security.
An installer that configures an admin user and does not prompt the user to create a regular user account is a security hole.
The Mac OS X "admin" user is a regular user account, it's nothing like "Administrator" on Windows or "root" on UNIX. Unless you SU to a real admin account (which is what you're doing when you type in your password to a security dialog) the OS doesn't give you any more rights than any other user.
Default permissions for new applications that permit them to modify existing applications without warning are a security hole.
The default permissions for new applications give them no more rights than the user running them.
If the OS was attempting to provide mandatory access control rather than discretionary access control, these would be security holes. But as you noted, MAC is vanishingly rare, and there's a good reason for that.
At the moment, I'm running OS X in a Managed user w/all but Terminal enabled 'just in case' I open a dodgy zip
That's silly. If you turn off "Open Safe Files" and switch to something other than BOMArchiver for opening Zip archives then you'll be safe from attacks through other applications that have similar capabilities, AND you won't lose Terminal.
Terminal isn't the problem.
Safari and LaunchServices are the dysfunction siblings that cause the problem. There's not much you can do about LaunchServices, other than avoiding the REAL application that's being exploited (BOMArchiver), but you can keep Safari from hurting you pretty easily.
I'd recommend installing Stuffit Expander but ONLY enable it for "zip", and turn off "Open Safe Files By Default", and quit worrying about the BOM.
Then a few are found when they are exploited in the wild by hackers.
As far as I know the only exploits in the wild involving OS X have been social engineering attacks... trojan horses convincing people to execute programs. These aren't security holes.
There are a few security holes that Apple has been reluctant to fix, maybe this time they'll be convinced to bite the bullet before someone DOES create an automated worm with them.
I think that the main reason OS/X (and *nix for that matter) was considered to be rock-solid is because very few people were taking shots at it.
Apache on UNIX has 3-4 times the webserver market share of IIS.
last time I checked, IIS was still getting twice the number of defaced sites as Apache.
A computer is only as secure as its maintainer.
A computer is only as secure as its maintainer can make it. There are holes in Windows that take heroic measures to completely close, that are closed by default or can't even be created on UNIX-based systems.
Well, it's been almost two years and Apple's still sitting on the fix for the LaunchServices problems.
But then Microsoft's going for TEN years of not fixing their corresponding (and much more serious and harder to fix) design flaw, so Apple's not doing so bad.
How many Mac users today run anti-virus software?
The naive ones.
So far the only actual damage I'm aware of caused by any of these trojan-horse worms on OS X has been caused by antivirus software incorrectly identifying uninfected files as them.
Similarly, the only cases I know of where malware has actually caused data-loss on Palms or Pocket PCs is where anti-virus software itself caused a problem or led to an overreaction after a false positive.
The most effective anti-virus software we've used on Windows has been Netscape. And we've lost more man-hours to problems caused by AV software than to trojan horses that people using Netscape have been convinced to download and open. IE is a different kettle of security holes, of course...
If Apple's approach to security in Safari was the same as UNIX's, then this would have been fixed two years ago.
You can't secure against user stupidity except by scanning each file that they try to execute for viruses.
You can discourage user errors by giving users time to consider before acting, and by giving applications a safe mechanism for opening helpers.
Opening untrusted documents automatically from a web browser using a mechanism that can potentially run any application on the system is something I've come to expect from Microsoft. It's not something Apple should be doing.
Unfortunately, they seem to be emulating Microsoft this time around. This is the third strike, and they patched the symptoms rather than the hole the last two times.
Although Apple is largely responsible for causing these security flaws, it is hardly something that can be avoided in a modern consumer oriented OS such as Mac OS X.
Yes, it bloody well can.
A key part of this attack should have been closed almost two years ago but Apple 'fixed' the wrong thing.
And they knows there's a problem with LaunchServices, because in Tiger they allow you to override the types of files Safari considers "safe"... unfortunately they still use the LaunchServices database which leaves the "injection" problem intact.
So... Apple can fix these problems. Secure approaches are well known, and have been known for longer than Apple has existed as a company, and they know the problems exist. Why do they leave this hole open? I don't know, possibly because Microsoft does?
So now I am wondering, how necessary is security software if you're not a total moron?
The CHM hole on Windows worked for Mozilla-based browsers.
The first LaunchServices hole on Mac OS X worked for Mozilla-based browsers.
Both of these were caused by an insecure application being automatically passed untrusted content by the browser using a desktop API to find helper applications.
These kinds of attacks do not require user intervention, and can only be prevented by avoiding the Desktop equivalent of system("Infect Me Harder");.
Yes, the first LaunchServices hole on Mac OS X hit Firefox as well as Safari.
there are OS vulnerabilities and application vulnerabilities.
... you do see apps breaking this rule from time to time) call the shell to run applications... they fork() and exec() the desired application directly... because the shell's behaviour isn't controllable or fully predictable.
And this is an OS vulnerability. On Mac OS X, LaunchServices is an OS component. It's the normal way to launch GUI applications, including helper applications from web browsers, like the shell in UNIX is the normal way to run command line applications. In UNIX, though, applications that have security concerns don't (or shouldn't
LaunchServices has many of the same problems. UNFORTUNATELY, there's no general "safe" way to open documents on OS X. It's possible to securely open applications if you know the right application, but it's more complex than just fork/exec, and you have to deal with the difference between old-style Carbon apps and Cocoa appdirs... so Safari and other programs use LaunchServices.
The lack of a "secure applications only" equivalent to LaunchServices is an OS vulnerability. One that must be fixed (alas, Apple didn't fix it the last two times around).
Mac OS X has no vectors for attack except social engineering.
And LaunchServices.
Safari doesn't open ANYTHING executable, period.
That's half of a solution, but it would still leave the original hole open.
The Finder should implement an icon overlay showing that a file is executable.
That would be useful, but it would still leave the original hole open.
The first time the system runs ANY new executable that has not been run before, it pops up a warning window [...]
That's a REALLY bad idea, and it would still leave the original security hole open.
NEITHER of the other two demonstrated exploits, using URIs rather than file names, would have been prevented by this approach. In fact the second showed up after Apple implemented pretty much that approach for URIs.
It also would not have prevented this attack, because LaunchServices didn't open the executable... the shell did, and there are variations on this attack that don't require the script used in the attack to be executable.
As to why it's a bad idea... well, Microsoft has been trying to use the same "trying to detect whether an attack is underway at the last minute" approach since 1997. All it's done is teach people that the system comes up with stupid dialogs on a regular basis, so you just gotta approve them and go on if you want to keep working.
I've been supporting 150-400 people on Windows for over a decade now, and I've regularly had people come up to me, the same people... over and over again... telling me that they'd clicked on the wrong button in a dialog box and gotten infected. false positives from these kinds of last-minute checks are always going to be so much more numerous than valid alarms that all you're doing is adding noise to the user experience.
The right solution is to keep the attack at arms length and let the user at his own time make the decision. Popping up a routine and routinely approved dialog isn't giving the user time to do the right thing, it's encouraging a snap decision and that's bad user interface design.
1. Turn off "Open Safe Files After Downloading" by default.
2. Create a separate database of "Safe Applications". ONLY use these from web pages viewed in Safari or any other document from applications that deal with untrusted documents.
3. Don't put any kind of installer, disk image mounter, or archive extractor in that database.
But of these three, #2 is the most important.
Apple had the advantage of seeing what was already happening to Windows when they made their decisions about how OS X would be designed, plus the system it was derived from was pretty robust to begin with.
It's a pity Apple hasn't been paying more attention.
Two years ago, Apple got bit by Safari's blind trust of LaunchServices, at the same time Microsoft got hit by a hole in almost the same application on Windows. Instead of going "oh, maybe Safari shouldn't use the same database for finding helpers as desktop applications do", they went "oh, maybe the helper app database should try and guess if it's being used by an exploit".
That's the same kind of decision Microsoft made in the '90s when they came up with "Active Content" and "Security Zones", and it didn't work for them then. Microsoft isn't likely to back out of that, but, damn, Apple should have noticed what a big blunder that was.
At least they should have backed out of it the first time it came up.
Ah, right, that worked so well for Java.
Switching to an API that Microsoft controls and can create incompatible extensions for, instead of one where the company that controls it is at least TRYING to maintain compatibility. That sounds like a winning approach.
If it was even primarily market share the number of worms, viruses, and other malware for Windows should have been higher through the '90s, and followed a continual upward curve against a matching downward curve for Macs. but that didn't happen... instead, after 1997 there was a sudden massive surge in Windows worms and other exploits. This surge is correlated with and caused by the introduction of what was then called "Active Desktop".
Buffer overflows and the occasional string injection, these can be found on any browser and any OS, and can be quickly fixed without breaking working code. Social engineering attacks, these used to be the majority of worms... before Active Desktop if you were savvy to them keeping your eyes open was pretty much enough. Trojan horses, viruses hiding in innocent downloads, they became increasingly rare as the Web meant that people weren't passing shareware around on BBSes and maintaining "upload quotas" to keep their downloads working. Peer-to-peer brings that kind of thing back, but it's no longer the main distribution mechanism for shareware.
So, really, we should have relatively fewer virus problems now. People are getting more familiar with computers, and few people are caught out more than once by a worm hiding in an email message if they have a chance to think about the attachment, if they download it and then open it in their own time.
But something happened.
Back in the early '90s there was this joke going around the net about a virus that was so clever it would run if you just READ an email message! Everyone knew it was a joke, because NOBODY would be so stupid as to write an email program that let you do that, or if they did they'd back out of that as quick as the "WIZARD" hole was backed out of sendmail.
then came Active Desktop, Active X, Active Content, a web browser and an email program that both used a display technology that was designed to download and run software without user intervention. I was horrified. I didn't know exactly what was going to happen, but I expected something nasty. And boy were my expectations fulfilled. Dozens, then hundreds, then thousands of of attacks, and Microsoft didn't back it out! And it's still in there, and still used by spyware and viruses to sneak into people's machines without the user actively doing anything... at the most they may have to click a button on a dialog box that looks pretty much like the ones that come up regularly and have to be clicked away...
The fundamental problem, the thing that makes Windows so terribly attractive to virus writers, is that it's got this big "infect me harder" capability built in to the core of the OS that you can't remove or even fully disable.
This is so much easier than even the weaker versions of the same problem in Safari and Firefox are trivial by comparison. If the UNIX (Linux&OSX) desktop market share was 50% instead of 5% you'd still have orders of magnitude more viruses on Windows than Macs... because it's so much easier a target. Even if you turned off ALL the internal security and ran as "root" with no password, the "Security Zones" hole is so much deeper and harder to close that there's still no contest.