Quick heads-up on a new (old?) vulnerability
 

Didn't find any mention of this here yet, so...

Mac OS X Root Escalation Through AppleScript

Truly flabbergasting.

This is like a skript kiddie's wet dream.
All they need to do is "fill in the blank".

-HI-

All the more reason to log out if you'll leave the machine untended, AND, don't allow a reboot without a password. And, BTW, it does work -- I tried it.

Well, it didn't take long for some "skript kiddie" to "fill in the blank":

SecureMac identifies first ARDAgent-based trojan

It makes you wonder though. A lot of antivirus/anti-malware companies are quite shadowy entities. I wonder if they aren't related to the mob somehow:

Two big thugs walk into a small corner store owned by Mom and Pop

Thug1: "This is a dangerous neighbourhood. You really should have some kind of protection. You know, we provide protection for a small monthly fee."

Pop: "We've never had trouble before - I think we're fine without your protection."

Thug2 smashes a few cold cases and knocks over a couple of shelves.

Mom: "You <insert expletive here>!"

Thug1: "Would you care to reconsider? It really is a dangerous neighbourhood!"

And so, Mom and Pop end up shelling out some hard earned money each month for "protection".

Interestingly, a Purdue University Mac admin is reporting that enabling Remote Desktop disables the vulnerability! Apparently, enabling RD kicks in some extra security that prevents the vulnerability from being exploited. Ars version of the story here: http://arstechnica.com/journals/appl...ted-via-trojan

I wonder if that permanently disables the vulnerability, because I can't get it to work, and I've had Remote Desktop enabled many times in the past.

With Remote Management allowed in the Sharing preference pane:

I don't quite understand the error, but am glad to see it. ("whoami" returned a similar error)

MacBook 2.1
C2D 2.16 GHz
10.5.3

Same error here. OS 10.4.11 PPC.

I don't understand what the desired (feared?) result is supposed to be.

When I run it from the Terminal command line, it reports back "root".

Yeah? And?

The point is that this allows other commands than 'whoami' to be run as 'root' and 'root' has full control of the system.
I.e. it provides a way for even a non-admin user to run arbitrary commands with full control of the system - with no password required.
The 'whoami' was just an example command that proves that the command is run as 'root'

If you turn on remote management, does it still work, and if so, does it work after turning remote management off?

By "remote management" you mean the Sharing PrefsPane is checked to share out my computer using ARD? Yeah, it's checked.

::light comes on::

So I should create a file and sudo chown/chmod it to root & u=rwx,g=r,o=r for example and then tell ARD to rm it and see if it does?

Well it would be safer to try to "cat" a file which you don't have permissions to.
so:
touch foo; chmod 600 foo ;sudo chown root foo
creates an unreadable file in the current directory. cat foo without permissions gives cat: foo: Permission denied
and with permissions just an empty line.

You are on the right track.
But note that the permissions on a file are not relevant regarding whether you can delete it via 'rm'. To delete a file, you need only have write permission in the enclosing folder.

And doing something like what is suggested by baf would be better.

I'm beginning to think that you have to be logged in as an admin user for this to work. I've just tried it on my sister-in-law's Macbook (10.4.11) and it doesn't work there either. I don't have her admin password handy.

:( can someone put all this into idiot language for me?

If you can run a shell command as root, you can do anything you like on the system. You can delete files/folders, send emails through the user accounts, turn on file sharing, turn off firewalls, etc.

I'm trying to figure out why it doesn't work on my system or my sister-in-law's. There must be a very easy way of defeating this exploit: I've apparently done it on two systems without knowing!

[IdiotLanguage]
On computers where it works, which seems to have something with the state of remote management to do.
Even a nonadmin user could run any command. If someone tricks you to a hostile website and makes you run an applescript their command would be run as root.
This could e.g. add a new user and start remote access for them .....
[/IdiotLanguage]
And you wouldn't get a question for your admin password.

And any local user could do it directly.
Think school with hundreds of students getting admin privileges......

Well cwtnospam you beat me.
Also same problem here it doesn't work for me either.
In one case I get:
23:47: execution error: ARDAgent got an error: "whoami" doesn't understand the do shell script message. (-1708)
Or with some other settings:
23:47: execution error: ARDAgent got an error: AppleEvent timed out. (-1712)

It worked on my 10.5.3 MacBook as a non-admin user until I enabled Remote Management.

Does it work again if you turn it off?

Yes, it works again.

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.

there was a security update today.. did that fix anything?

Looks like it:
And the system.log notes: