awwggondzur, so what is a *KNOWN* buffer overflow present for over a year imply to you, that they're fast on handling security issues?

jonbwfc1, ~/Applications doesn't give you any protection, as that is normally writable. Applications should be placed in an area that can't be modified. chmoding ~/Applications is probably good enough for the most part.

Robert, a known buffer overflow that hasn't been successfuly exploited for a year (i.e. hasn't been outside of the lab) gives me the right to say that Apple is adequate on security issues. The only measure of this "adequateness" is the number of security issues spreading in the wild. And by this measure Apple's record is opposite of being abysmal.

Whenever hackers' pressure on Mac OS X will increase (I keep hearing this kind of statement for at least 3 years now) it won't happen overnight. And I believe that to remain adequate in security measures Apple will tighten its timeframe of patching the holes. Until then speaking of Apple's security in "much more dangerous future" that's yet to come is nothing more than baseless speculation.

This is how Unix permissions works. The user whos copies the file owns the file. It's always been this way. I supposed ideally you would want all the applications owned by root if you don't want unauthorized applications modifying them. In any case, this really isn't anything new or particularly scary. Apple calling it an "enhancement" is not accurate at all.

If you have the admin password of a machine, you own it. In all meanings of the word. Period. There is nothing that you cannot do on a typical Mac OS X installation if you have an admin password. Absolutely nothing.

You want root? Simple -- "sudo -s" -- root shell. From there you can do anything you want. You can do far more damaging things than replace an application that then takes over the logged in users permissions. Like set the sticky but on that replaced application such that it runs as root.

Robert Myers is totally correct on this, and everyone else apart from Adrian has completely missed the point. In short:

- User A installs an app which resides in /Applications. It's now owned by him.

- User A runs malware that replaces said App WITHOUT needing any password at all.

- No one knows the app has been compromised.

- Users B, C, D, etc who also run this App are now in deep trouble.

Those of you who think this is correct behavior driven by sudo are also wrong. sudo doesn't do this by default. Try it yourselves from the Terminal of an account with sudo root access:

$ cd somewhere/you/have/files/to/copy $ sudo mkdir /Applications/mytest $ sudo cp * /Applications/mytest

Now look at what you've created:

$ ls -ld /Applications/mytest $ ls -l /Applications/mytest

The mytest directory, and the files inside it are owned by root with a group of admin. This is the correct behaviour.

Clean this up after with:

$ sudo rm -rf /Applications/mytest

[ Note: Type that slowly and make sure you type it correctly before hitting Enter. Root recursive deletes can be dangerous if you make mistakes, like hitting enter before you intended to finish typing or insert rogue spaces ]

What Apple are really saying then when they say they've "enhanced" this, is that they've changed the behaviour of sudo when called from Finder, away from its default to something of their own design. They've not thought this through properly and there's serious potential here for a malware peddler to slip a trojan in under the radar.

For example, as it stands right now, all my /Applications/Internet/Firefox.app/* files are owned by me. What's to stop me downloading and running a rogue application that installs its own Firefox plugins without me being any the wiser, and compromising any online transactions I do using Firefox?

Apple need to proactively address this and not ignore it, before both they and their customers get a bloody nose.

Maybe if this gets out to a wider audience, say the bugtraq security advisory mailing this, then Apple with pay more attention.

Hm, seems that Macnn likes to join up lines that begin with a $. Treat all those $ lines as separate lines and separate commands.

Said standard user would still need an admin username and password to put it in the Applications folder in the first place. If they've got that, they've got root power, and this whole thing is moot.

No, the whole thing is NOT moot. Besides what adrian has pointed out (which isn't surprising that most users don't understand), you make the assumption that the user knew the admin password.

Take this account: Fred gets new application. Needs to install it on his system. He doesn't have said password. So he calls Bob, who comes over, enters the information (after verifying the app is a valid app, like Firefox) and enters the information for Fred. So Fred doesn't have the admin password.

As to why it sets ownership to the user of the user who authenticated (and not the user they are authenticating as), well, that's just how sudo works. (The authentication box is a graphical representation of the sudo process.)

But then wouldn't this indicate that the sudo process or the authentication process has changed since it's previous incarnations? I'd like to know why this hasn't been brought up by other security professionals and developers who've seen this on the big list of changes in OS X.

I mean, it was on the big list of changes, wasn't it? Apple wouldn't make a big change like this without documenting it, would they?

personally, I don't (and don't see why a user should be) installing apps in /Applications. All the apps I download go in ~/Applications instead. If I can't install an app to there, unless I *know* it's a valid app, I don't install it. Apps which insist on being installed in /Applications I'm generally very suspicious of.

installing in ~/Applications is great only if you're the only user of the computer, but actually has the issue that the apps can change themselves whenever they feel like it, which means they are less secure then putting them in /Applications. In /Applications, they're secure from changes because they're SUPPOSED to be owned by an admin.

Putting them in ~/Applications is pretty much tantamount to saying "I don't want to be bothered with OS X security that people praise as being so great, so I'm going to bypass it".

This would work as intended if users run as users and the admin account is left as an admin account. I know that's now how people are using OS X and it's not even how Apple helps people setup OS X, but it would be much more secure if it was.

In other words, create an admin account. You know the name and the password.

Create a user account. Your name and your password.

When you need to install something into a secure location, you type in the admin name and password.

Later when malware trys to do something, it will still require an admin name and password (because it will be running with a users credentials). That gives the user time to think, "why is this app asking for admin privileges?"

This really is how OS X should be setup and it would be much more secure than it already is.

deal, you misunderstand the problem. Everything you say is how it should work (and, yes, I do run as a non-admin user) to keep things nice and secure.

However, the Leopard flaw being mentioned, the package in the /Applications folder ends up with the user account having permissions, not the admin account. Thus, the malware can still access the file WITHOUT the username/password prompt.