Two ways to possibly close an ARDAgent security hole | 24 comments | Create New Account
Quickly uninstall, install, activate, configure, and/or restart components of Apple Remote Desktop without a reboot. Syntax kickstart option(s) The 7 'top level' features can be selected independently, but will always be done in the order: uninstall, install, deactivate, activate, configure, stop, restart.
Click here to return to the 'Two ways to possibly close an ARDAgent security hole' hint |
The following comments are owned by whoever posted them. This site is not responsible for what they say.
This is yet another fix, suggested in the Slashdot thread. Open a Terminal as an admin user and do: This seems to restrict ARDAgent to a standard AppleScript dictionary, which does not include the 'do shell script' command.
I tried this 'fix' on Leopard. No luck. I can still execute the do shell script command.
Two ways to possibly close an ARDAgent security hole
The first possible fix (turning on Remote Management) doesn't work for me, at least not consistently. I'm using 10.5.3. The first time I enabled Remote Management, I'd get:
Nooch:~ leon$ osascript -e 'tell app 'ARDAgent' to do shell script 'whoami';
23:47: execution error: ARDAgent got an error: 'whoami' doesn't understand the do shell script message. (-1708)
Indicating that the problem was mitigated. I then disabled Remote Management, and got the same message. So I found and killed a running ARDAgent process, then the exploit worked again. I re-enabled Remote Management, and the exploit continued to work, so I wouldn't trust this fix to solve the problem.
Nooch:~ leon$ osascript -e 'tell app 'ARDAgent' to do shell script 'whoami';
23:47: execution error: ARDAgent got an error: 'whoami' doesn't understand the do shell script message. (-1708)
Indicating that the problem was mitigated. I then disabled Remote Management, and got the same message. So I found and killed a running ARDAgent process, then the exploit worked again. I re-enabled Remote Management, and the exploit continued to work, so I wouldn't trust this fix to solve the problem.
On my two machines, zipping up ARDAgent then deleting it did NOT disable screensharing. It does disable Remote Management.
Two ways to possibly close an ARDAgent security hole
You could simply clear ARDAgent's setuid bit:
Now I get the result:
sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
Now I get the result:
$ osascript -e 'tell app 'ARDAgent' to do shell script 'whoami'
mike
![How How](/uploads/1/2/6/3/126344123/577556774.jpg)
Two ways to possibly close an ARDAgent security hole
Did this too.
Get my user id as the result when I run the command now.
Before the change, running the sample script resulted in a hang and a AppleEvent timed out. (-1712) error. Weird.
Get my user id as the result when I run the command now.
Before the change, running the sample script resulted in a hang and a AppleEvent timed out. (-1712) error. Weird.
Two ways to possibly close an ARDAgent security hole
<blockquote>Patching it may be tricky, because administrators really do need the ability to run root-enabled scripts remotely and non-interactively...</blockquote>
I see no reason why a patch cannot work. An admin name and password should be required before the Mac will run root-enabled scripts (at the computer or remotely). The Trojan Horse software cannot send the password. All Apple has to do is disallow root access to ARDAgent unless admin name and password are entered.
I see no reason why a patch cannot work. An admin name and password should be required before the Mac will run root-enabled scripts (at the computer or remotely). The Trojan Horse software cannot send the password. All Apple has to do is disallow root access to ARDAgent unless admin name and password are entered.
Two ways to possibly close an ARDAgent security hole
How do you propose to transmit the admin user's password to the client machine over the network?
1) plain text. bad idea
2) encrypted: well, it has to be decrypted and it could be intercepted then.
3) ssh keypairs? this is starting to move in the right direction, but think of the vulnerability if the private key were compromised.
4) kerberos? might work, but most organizations don't run a KDC, although many do.
5) Directory Service integration? This is also a good idea. Don't send any password; just have to somehow prove to the client that the person running the script is in an admin group.
Any way you slice it, it is a hard problem. The main issue is that Apple uses a push architecture, not pull. This means that the admin push a script onto the client rather then the client connecting to a server and pulling the script. If the client pulls the script, only the process that does the checking for tasks needs to have root privs. As long as ARD does a push, it will be vulnerable. In places where security matters (like the US government, where I work) push technologies are generally not allowed for configuration management.
Jut my 2 cents.
1) plain text. bad idea
2) encrypted: well, it has to be decrypted and it could be intercepted then.
3) ssh keypairs? this is starting to move in the right direction, but think of the vulnerability if the private key were compromised.
4) kerberos? might work, but most organizations don't run a KDC, although many do.
5) Directory Service integration? This is also a good idea. Don't send any password; just have to somehow prove to the client that the person running the script is in an admin group.
Any way you slice it, it is a hard problem. The main issue is that Apple uses a push architecture, not pull. This means that the admin push a script onto the client rather then the client connecting to a server and pulling the script. If the client pulls the script, only the process that does the checking for tasks needs to have root privs. As long as ARD does a push, it will be vulnerable. In places where security matters (like the US government, where I work) push technologies are generally not allowed for configuration management.
Jut my 2 cents.
Two ways to possibly close an ARDAgent security hole
Turning on Remote Management is no defense. Take for example this simple AppleScript:
property theUser : '
do shell script 'kill `ps -acx | grep ARDAgent | awk '{print $1}'`'
tell application 'ARDAgent'
set theUser to do shell script 'whoami'
end tell
display alert 'You are: ' & theUser
This can be run as a regular user and you will get root access. Note: you many need to run the script more than once to get the 'root' output.
The simplest way to deal with this vulnerability is to remove the setuid bit from the agent:
sudo chmod -s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
This line of code needs to be run after any updates to make sure the SetUID bit is still set off.
I received a message from Apple Enterprise Support that essentially said Apple engineering is well aware of this whole ARDAgent issue and is working on a solution. Until then, turning off the SetUID bit and having reduced functionality is the best defense.
-Allan Marcus
property theUser : '
do shell script 'kill `ps -acx | grep ARDAgent | awk '{print $1}'`'
tell application 'ARDAgent'
set theUser to do shell script 'whoami'
end tell
display alert 'You are: ' & theUser
This can be run as a regular user and you will get root access. Note: you many need to run the script more than once to get the 'root' output.
The simplest way to deal with this vulnerability is to remove the setuid bit from the agent:
sudo chmod -s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
This line of code needs to be run after any updates to make sure the SetUID bit is still set off.
I received a message from Apple Enterprise Support that essentially said Apple engineering is well aware of this whole ARDAgent issue and is working on a solution. Until then, turning off the SetUID bit and having reduced functionality is the best defense.
-Allan Marcus
Two ways to possibly close an ARDAgent security hole
The one problem with this solution is that Reparing Permissions will change the permissions back to -rwsr-xr-x. The security problem is there again. This will be the case with any solutions that involve changing permissions.
Two ways to possibly close an ARDAgent security hole
you are right but this can be dealt with by locking the file after removing the s-bit: sudo chflags uchg /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
![How To Uninstall Ardagent How To Uninstall Ardagent](/uploads/1/2/6/3/126344123/110137402.png)
Two ways to possibly close an ARDAgent security hole
The most fun way to neutralize this hole was suggested by Jay Beale. It's found at the bottom of this page.
http://rixstep.com/1/20080620,00.shtml
You simply use ARDAgent to neutralize itself.
http://rixstep.com/1/20080620,00.shtml
You simply use ARDAgent to neutralize itself.
Two ways to possibly close an ARDAgent security hole
a repair permissions will simply set the ARDAgent back :-(
Two ways to possibly close an ARDAgent security hole
Its not at all that big of a problem. Apple already sends login/passwords encrypted throught ARD.
Two ways to possibly close an ARDAgent security hole
You have underestimated the impact of this problem. This is the worst security hole I have ever seen in OS X. Imagine the following scenario ...
Hacker writes an application that you install on your computer. The application contains the following bit of code:
osascript -e 'tell app 'ARDAgent' to do shell script 'rm -Rf /';
Your entire hard drive has just been erased.
This security hole allows the script author to do ANYTHING they darn-well please with your machine, including (but not limited to):
- Installing key loggers
- Generating spam
- Using your machine as a proxy server for other illegal activities
It works for me.
If indeed modifying Info.plist works then it's rather crucial to point out the file must be protected from modification afterwards. Make sure the file's owned by root:wheel and cannot be modified by anyone. This isn't pointed out in Kou's article but it's absolutely essential.
Two ways to possibly close an ARDAgent security hole
Correct! Good point. I hope Apple comes up with a solution soon.
pb from the /. article a few days back.
sorry, don't know if they are true or relevant, but may be of use:
1.
A remote terminal session doesn't get you access to the OS X GUI, which is where AppleScript is found.
2.
Here's a non-destructive way to neutralize it.
cd /System/Library/CoreServices/RemoteManagement/
sudo tar -czf ARDAgent.app.gz ARDAgent.app
sudo chmod 600 ARDAgent.app.gz
This simply hides it in an unreadable tarball.
sorry, don't know if they are true or relevant, but may be of use:
1.
A remote terminal session doesn't get you access to the OS X GUI, which is where AppleScript is found.
2.
Here's a non-destructive way to neutralize it.
cd /System/Library/CoreServices/RemoteManagement/
sudo tar -czf ARDAgent.app.gz ARDAgent.app
sudo chmod 600 ARDAgent.app.gz
This simply hides it in an unreadable tarball.
Two ways to possibly close an ARDAgent security hole
Simply prevent ARDAgent from being allowed to run scripts as root...:
% osascript -e 'tell application 'ARDAgent' to do shell script 'whoami'
root
% sudo chmod u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
% osascript -e 'tell application 'ARDAgent' to do shell script 'whoami'
Constantinos
Two ways to possibly close an ARDAgent security hole
until a repair permission is run, then the problem returns.
Two ways to possibly close an ARDAgent security hole
If you don't like to 'play' with Terminal command lines, you will appreciate this simple script to defend yourself against this ARDAgent weakness.
Copy this script in Script Editor and run it; it will ask you to enter your admin password, correct the problem and show you that ARDAgent, from now on, can ONLY run scripts with your regular permissions, not as root as before.
The script :
do shell script 'sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent' with administrator privileges
tell application 'ARDAgent'
set running_as to do shell script 'whoami'
end tell
display dialog 'Running as ' & running_as
Copy this script in Script Editor and run it; it will ask you to enter your admin password, correct the problem and show you that ARDAgent, from now on, can ONLY run scripts with your regular permissions, not as root as before.
The script :
do shell script 'sudo chmod 755 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent' with administrator privileges
tell application 'ARDAgent'
set running_as to do shell script 'whoami'
end tell
display dialog 'Running as ' & running_as
Two ways to possibly close an ARDAgent security hole
The ARDAgent issue seems to be resolved with 2008-005 security update
Two ways to possibly close an ARDAgent security hole
Can anyone confirm that this hole is indeed patched?
I still see the ADRAgent.app error during permissions repair.
Have been trying some fixes following having an online game account hacked and unable to trace how they came to gain access... But, using the provided terminal code - all the terminal commands give me:
'whoami' still results in 'root'
Ran sudo chmod u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
results in 'execution error: ARDAgent got an error: AppleEvent timed out. (-1712)'
Running 10.6.2 w all available apple updates
Thanks to any replies!
Kindest regards,
--J
I still see the ADRAgent.app error during permissions repair.
Have been trying some fixes following having an online game account hacked and unable to trace how they came to gain access... But, using the provided terminal code - all the terminal commands give me:
'whoami' still results in 'root'
Ran sudo chmod u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
results in 'execution error: ARDAgent got an error: AppleEvent timed out. (-1712)'
Running 10.6.2 w all available apple updates
Thanks to any replies!
Kindest regards,
--J
Use kickstart to set Apple Remote Desktop preferences. For example, you can install, uninstall, activate, set up, and restart Apple Remote Desktop components.
Learn how to control a remote Mac with Screen Sharing with the kickstart command-line utility in macOS Mojave 10.14 and later.
Get started
You can find the kickstart tool at:
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart
Type the commands in this article as one line of text. If the text wraps as you enter it, that's fine. Don’t press the Return key until you’ve entered the entire command.
For more information about the kickstart command, use the -help flag:
Sample commands
The commands in this article work with Apple Remote Desktop 3.2 and later.
Here are commands that you can use:
- Restart the ARD Agent and helper:
- Turn on Remote Desktop Sharing, allow access for all users, and enable the menu extra:
- Turn on Remote Desktop Sharing, allow access for specified users:
You must use the -configure, -access, and -privs options in a separate command to specify the set of users and their access privileges. For example, this command is for users with the short names 'teacher' and “student.' It gives them access to observe (but not control) the computer, and to send text messages:
Unlike other kickstart options, you can’t combine the allowAccessFor options with other kickstart options. You must use it as in the last two samples above. You might have to call kickstart more than once to finish a computer’s setup. - Remove access privileges for specified users ('student' in this example):
- Disable ARD Agent and remove access privileges for all users: