Are ARDAgent permissions really safe?
Solution 1:
tl;dr There does not seem to be anything unusual, or inherently unsafe, with your ARDAgent executable or its permissions. Your proposed fix will in fact make your system a tiny bit safer but might do more harm than good. It’s probably not worth it.
With chmod a-x, the gain in security would be really small; a software update might simply reset the flag, leaving you with a false sense of security; you’ll definitely break ARD; you might also forget to re-enable SIP, or even break future system updates.
What has happened
Let’s first summarize what has happened with respect to ARDAgent in the past.
Back in 2008, the OSA libraries (a part of Mac OS X) had a root privilege escalation issue (CVE-2008-2830), which would allow attackers to execute arbitrary AppleScript using a privileged app.
One popular way to demonstrate CVE-2008-2830 was to use the ARDAgent app as a confused deputy to execute arbitrary AppleScript code with elevated privileges.
That exploit was possible because ARDAgent used the OSA libraries (containing the bug at that time) and because it is designed to run with superuser rights.
The SUID warning message by Disk Utility is very likely caused by a minor oversight introduced with OS X 10.5. The SUID warning used to bother Mac users as early as 2007; first reports appeared on the day 10.5 was released, and CVE-2008-2830 had not even surfaced. So I don’t think the warning has anything to do with the bug, the exploit, or with Apple’s subsequent patch.
At present, CVE-2008-2830 has been fixed for almost a decade. I haven’t seen reports since on any other vulnerability involving ARDAgent.
Your threat model
All that history aside, let’s move on to clarify the threat scenario you most likely have in mind; feel free to edit your question in case I’m wrong.
For the sake of threat modeling, let’s assume that ARDAgent 3.9.2 (the version that ships with El Capitan) has another unrelated vulnerability, one that is not publicly known as of today but might be discovered and exploited by an attacker.
In the worst case, that vulnerability would be a remote code execution (RCE) issue; an attacker might then be able to exploit the bug over the network to gain code execution (due to the bug) and superuser privileges (due to the setuid bit) in one go. This is a somewhat realistic threat.
If the attacker already has local code execution with normal privileges, escalation can probably be achieved by the same means.
We’re not interested in an attacker that already has superuser privileges in the first place; such an attacker would have complete control over the entire system already, and would not gain anything by attacking ARDAgent.
Risk mitigation
If you run chmod a-x against the executable as per your suggestion (which is only possible with SIP disabled), the attacker loses: launchd will no longer run the agent, and the local attacker won’t either. You have successfully reduced the attack surface – albeit only by a small fraction.
Impact of the fix
On macOS, there are many processes with superuser privileges, be it with or without setuid. The fact that there was a bug in ARDAgent one decade ago does not make it inherently any less secure than the other programs. On average, other processes are just as likely as ARDAgent to have an undiscovered critical vulnerability.
You will lose Apple’s remote desktop features (if you have them enabled). You might also run into a random future macOS update failing because the flags might have become part of a pre-update signature assertion (not unlike the SUID warning a decade ago, but this time Apple might choose to make it an error). Chances are you’ll have forgotten your fix by then so you’d have to reinstall.
Even if the system updates work, they might simply reset the execution bit when shipping the next version of ARDAgent, leaving you with a false sense of security.
There’s also the risk of forgetting to re-enable SIP (which will introduce much more risk than you have just mitigated). And lastly, there’s a small risk of making an inconspicuous little mistake while chmodding, for example rwsrw-rw- – which means every user gains no less than root privileges for free.
Alternatives
A few suggestions to mitigate risk in a safer way:
Reduce the attack surface by disabling services you do not need. While this might not always protect against escalation attacks (an attacker with local code execution might just launch the agent directly), it will help prevent RCE.
Re-enable SIP if it’s disabled, and leave it enabled.
Search for, and remove, non-system files owned by root that have setuid/setgid bits set without good reason. If you absolutely need to leave the bits enabled, make sure the files are never group- or world-writable.