Thanks. On my computer I can't get it to work ??? No idea why, but it has to be something I have or haven't done that makes it invulnerable.

Interesting.

Just for sake of comparison, my Remote Management checkbox is checked, but I also have Allow access for only these users, with none listed. The Computer Settings… pane has only Show status in the menu bar checked.

I wonder if adding users or a password keeps some particular setting toggled, even if the Remote Management box is unchecked.

Also, I use the default bash shell. I don't know if that is relevant, either.

Well I'm on 10.4.11 so it looks different but I have tried a bunch of different settings and I can't get it to work.

This one does appear to be potentially non-trivial. I guess I'll leave Remote Management enabled until the July or August Security Update patches the vulnerability.

Then we'll move on to the next earth-shattering crisis. That'll probably be in OS X iPhone 2.0 somewhere.

I think enabling Remote Management has been found to be ineffective in preventing the privilege escalation. The effect is touchy to begin with and having Remote Management might make it more difficult to trigger, but does not stop it.

For the record, what I've done is turn off the "setuid root" bit via the following command (in a Terminal window):

Just a reminder that if you are among the (as of the time of this posting) representative >80% of visitors to this site that routinely use an "admin" account, all a trojan would have to do is execute 'diskutil repairPermissions /' to restore vulnerability prior to triggering the privilege escalation. Thanks to Apple's lackadaisical attitude toward security in the default configuration, a password isn't required to flip the setuid bit in this way.

Mind you, if you were using an "admin" account, you would have already been susceptible to root privilege escalation due to other vulnerabilities even before the current issue came up...

The fix mentioned in the link provided in the OP unfixes itself if you are actually an ARD user, the first time you launch Remote Desktop.app; it installs a fresh copy of the vulnerability on next launch.

It's for this reason and this reason only that I'll only use AVG Anti-virus on any PC. I automatically uninstall Norton, McAfee, what have you. AVG works great, and it's free as well. Not to mention that it's an excellent product for a free one as well.

Which is also hoping they'll bring it to the Mac if we DO get massive amounts of viruses in the future, sometime.

But hope that never actually happens.

Same here. I tried 2 different 10.4.11 machines.
One gave...
31:55: execution error: ARDAgent got an error: Connection is invalid. (-609)

The other...
31:55: execution error: ARDAgent got an error: AppleEvent timed out (-1712)

Both fairly stock machines: one intel, one ppc.

[no 'problem' doing it in Leopard tho.]

Oooops, my mistake. The latest earth-shattering crisis is to be found in the Ruby scripting language.

http://www.matasano.com/log/1070/upd...lnerabilities/

Apparently discovered by the chief of product security at some lackadaisical software shop... ;)

On my iMac (10.5.3) I get:
...regardless of the setting in the Remote Management pref.

This is an upgraded machine, not a fresh installation.

Does it work for anyone here using Tiger? So far it seems that of the people stating that it works, all are on Leopard.

I just walked my Dad through the "whoami" version of the command on my parents' brand new iMac. It revealed root access without Remote Management enabled, and gave an error (-1708) with Remote Management enabled.

For the record, someone at Best Buy set up the machine (and failed to give them the admin password for the account they set up :mad:), so it wasn't quite virgin, but very close.

New security update today, at least for Tiger, PPC. Also, 10.5.4 is out. Has anyone who's had this work updated, and if so, does it still work?

The 10.5.4 update does not appear to address the ARDAgent / AppleScript privilege escalation. There is no mention of it in the "security content" release notes, and I can't speak for the Tiger update, but at least on my system, the test osascript still works under 10.5.4.

Can someone test again please. The new update says it has fixed this.

When I tested on Friday, the osascript failed to return root in ~500 tries. Before, it never took more than ~20, and usually less than 10 so I assume it has been fixed.

On the other hand, the other privilege escalation vulnerability (the well known admin->root one that has been around since at least Panther) has not.

Don't use an "admin" account for routine use in any version (to date) of OS X.

Think of an admin account as being root with some basic safety measures thrown in, because that's what it really is. Privilege escalation is a feature of admin accounts. Unfortunately, that feature can be used against you. Just as you wouldn't want to log in as root for normal use, you shouldn't want to log in as an admin.

True. To clarify, I should have said "the well known admin->root privilege escalation without a password vulnerability (feature) that has been around since at least Panther".

So from the point of view of malware (sorry to anthropomorphise), an account running as "admin" is running as "root".

I left out the "without a password" part (the most important part). Thanks for pointing that out.