[kresh]

Is there a way for a script to point to a copy of ARDAgent that is conveniently stored on my Time Machine drive? If it can, can I wade through Time Machine and remove this file?
I would hate to go through all this trouble to zip up ARDAgent only to be exploited because I'm keeping an incremental backup of my system!

[macguyvr]

kresh, the short answer is it will be difficult if not impossible. Any files backed up by Time Machine is stored in a Backups.backupdb folder. That folder contains folders with the names of computers being backed up. If you have changed the name of your computer (kresh's computer for example) it will be hard for a hacker to guess that name unless he gains physical access to your computer and is able to boot up into your account.
Besides, the ARDAgent copy in your Time Machine drive is set to be non-executable in its archived state, so you shouldn't have to be worried about having to get into your backup folder to zip all instances of ARDAgent in your Time Machine drive (you can't do that anyway since the default permissions will not give you write access to items inside Backups.backupdb folder).

[wardoggie]

Perhaps "continual nagging" was too strong. I did try to soften it with "mild and understandable". :) I know I get periodic email from ZoneAlarm. I also use free versions of Ad Aware and AVG and get splash screens. And yes, I could probably opt out if I chose to do so. But I haven't bothered yet because I've become so accustomed to deleting unwanted email without reading it.


The point (on which we seem to agree) is that these companies don't release free versions of their software for completely altruistic reasons. It gets their names in front of customers and some of those customers will upgrade to a retail version. The size of the market has to be large enough to support the development and marketing of a dumbed-down free version.


That said, if every mac user felt the need to have some kind of anti-malware software, perhaps our market IS large enough to support free versions. I couldn't say for sure without knowing all of the numbers.

[lkrupp]

"First, Apple needs to provide a very quick fix. "

All well and good except that there appears to be a very large segment of Mac users who don't patch their system in a timely manner if at all. If the rants and complaints in the Apple user discussions forums are indicative of typical behavior then there could be millions of unpatched OS X systems out there. Every time a security update, OS X update, or application update comes out the throngs start reporting that they "had to revert back" to previous versions in order get their systems working again. The reasons may be foolish or misplaced but they are doing it. Some are hesitant to update anything because they actually believe the crap complete strangers report about problems. Heck, a lot are still running Panther apparently. So the point is there could be a large number of Macs that will remain vulnerable even after Apple provides a fix. And those users are the very types that would download something and run it without thinking. After all if they can't keep their systems running properly why would they think twice about clicking on a cute link?

[wardoggie]

lkrupp said:

So the point is there could be a large number of Macs that will remain vulnerable even after Apple provides a fix.

IMO, it's better to release a security update that some choose not to apply than to leave those who would apply it vulnerable to attack.

[kirkmc]

Regarding killing the ARDAgent process when Remote Management is turned on in the Sharing prefs. This is possible because ARDAgent runs under a normal user's account - it seems to be the first user who is logged in. So if this is your user account, you can kill it (or malicious software you run) without a password. This raises another issue: why is a process that is, arguably, on the system level (it applies to all users) running in a user space? This should be a root process so a user cannot kill it easily.

Kirk

[MLO]

What if you do not download untrusted apps and never use remote desktop?

[griffman]

"What if you do not download untrusted apps and never use remote desktop?"

Then your exposure is minimal, as long as you really never download untrusted apps -- including things in email that may come from people you don't know (or may appear to come from someone you know, if that person's machine were somehow compromised.)

-rob.

[kirkmc]

Whether or not you use Remote Desktop changes nothing - that app being present is the security risk. If you don't download things, that's fine, but also make sure never to open attachments, or any kind of files your friends and colleagues send you. While this exploit is currently in Trojans that are apps, there are also other vectors, such as MP3 or PDF files that contain code.

Kirk

[whitedog]

{quote}Since it's possible to kill it, I imagine it's equally possible to make it not restart -- programmatically, all the evil coder would have to do is disable the Remote Access checkbox in the System Prefs. And since you can do that without providing a password, the coder would probably be able to do so as well.{quote}

It's possible to prevent any unauthorized access to the sharing preferences simply by locking them. In that state, an administrator's password would be required to unlock the prefs in order to disable Remote Access. I'm curious to know how this would affect "programming" around the Remote Access solution.

Another question - though this is a potentially serious threat and not to be minimized - have there been any reports of it actually going off "in the wild"? Usually these things don't get much attention from users until they start hurting a significant number of them. We've had so many false alarms in recent years (I still get e-mail from dunces passing on bogus warnings), even from supposedly reliable sources, it should be no surprise that Mac users don't take the matter of security seriously.

Frankly, it will continue to be difficult to get Mac users to take security threats seriously until some actual damage is reported. Up till now, all the threats have been more or less theoretical. Experts have been saying for quite a while that it's only a matter of time before some real attacks occur on the Mac. While this is no doubt true, it's all so vague and problematic that it's easy to ignore.

It also seems self-serving when the warnings come from security software vendors. They've done this so often their credibility has been badly eroded. And, since Apple itself is so closed mouthed on questions of security, we're left to wonder who we can trust to tell us the truth when I real security threat to the Mac arrises.

[n4hhe]

macguyvr said:

n4hhe, yeah, your methods will definitely work to protect against this vulnerability, too, but I'm afraid some Mac users who loathe command lines might have difficulty implementing them. So Rob's method (zipping the ARDAgent) is probably the way to go for most.

For those who will brave Terminal.app, this is a simple 1 line copy-paste. Will prompt for administrator password.

sudo chmod a-sx /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

[ThePorge]

n4hhe said:

For those who will brave Terminal.app, this is a simple 1 line copy-paste. Will prompt for administrator password.
sudo chmod a-sx /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

I'm a bit slow, but I looked up chmod and couldn't figure out what the flags "a-sx" do exactly. Can someone elaborate and also give a line to reverse.

[djdawson]

The "chmod" command allows you to change the various access "modes" of a file, including whether or not it's executable and if so, by whom. You can either do this by specifying the values for the individual bit fields (e.g. "chmod 640 filename"), or use the mnemonic versions for the various options. In the case, "chmod a-sx", the "a" means apply this change for "all" users. The "-" means to remove the permissions to be specified next. The "s" specifies the "SetUID" bit, which is the thing at the core of this security vulnerability, since it allows a program to be run as some other user (the "root" user in this case) The "x" specifies the "executable" permission for the associated file. By removing these two file modes, the ARDAgent program will no longer be "SetUID", so it can only run as the user who starts it, and it will no longer be executable, so no user can run it anyway. The reversal process is to change the "-" to "+" so you can add the permissions back.

HTH

[ThePorge]

djdawson said:

The "chmod" command allows you to change the various access "modes" of a file, including whether or not it's executable and if so, by whom. You can either do this by specifying the values for the individual bit fields (e.g. "chmod 640 filename"), or use the mnemonic versions for the various options. In the case, "chmod a-sx", the "a" means apply this change for "all" users. The "-" means to remove the permissions to be specified next. The "s" specifies the "SetUID" bit, which is the thing at the core of this security vulnerability, since it allows a program to be run as some other user (the "root" user in this case) The "x" specifies the "executable" permission for the associated file. By removing these two file modes, the ARDAgent program will no longer be "SetUID", so it can only run as the user who starts it, and it will no longer be executable, so no user can run it anyway. The reversal process is to change the "-" to "+" so you can add the permissions back.

HTH

Many Tks, I just wanted to know what exactly I was going to do before actually doing it.