Identifying the Jamf Pro server set in CasperCheck using an Extension Attribute

As part of my Jamf Pro testing process, I will often set up a VM using a production setup workflow then enroll that newly-setup VM into my test Jamf Pro server. However, as part of my production workflow setup, I will usually install my CasperCheck self-repair solution in order to make sure the machine stays enrolled with my Jamf Pro server.

Unfortunately, this can lead to the following chain of events:

1. Test VM is enrolled in the test Jamf Pro server
2. CasperCheck runs on its pre-set schedule and detects that it is not enrolled with the Jamf Pro server specified in the script.
3. CasperCheck runs its repair functions and enrolls the test VM in the production server.
4. I wonder why my test VM isn’t talking to the test Jamf Pro server.
5. I check the CasperCheck log, grumble when I notice that CasperCheck has done its job, and then install the test server’s CasperCheck script on the test VM.
6. Reboot the test VM to trigger the test server’s CasperCheck script to enroll the test VM into the test server again.

This situation happened infrequently enough in the past that I usually just dealt with it on an individual basis, but I finally decided to fix it by writing a Jamf Pro Extension Attribute to help me identify which Jamf Pro server was specified in the installed copy of CasperCheck . For more details, see below the jump.

Race condition vulnerability fixed in CasperCheck

Recently, I was alerted by Todd Houle that his infosec folks had identified an vulnerability with CasperCheck that should be addressed.

The problem:

CasperCheck downloads a QuickAdd installer from a web server inside a .zip file and initially stores it in the /tmp directory. All users on the system have access to /tmp, so it was possible for an malicious unprivileged user to leverage a race condition to replace the downloaded .zip file with another .zip file with the same name.

Assuming that the replaced .zip file was valid and passed the check for being a valid .zip file, CasperCheck would then expand the contents of the replaced .zip file into the /var/root/quickadd directory. Assuming that the malicious unprivileged user had their own installer package stored inside the replaced .zip file, the next time that CasperCheck would determine that it needs to install the Casper agent via its cached QuickAdd installer, it would instead install that installer package in place of the expected QuickAdd package.

The fix:

The vulnerability assumes that the QuickAdd package is being downloaded to a place where an unprivileged user can access it, so the implemented fix to this problem is to download it to a place where only root has access. Todd fixed the issue by changing the designated download location to the following:

From: /tmp/quickadd.zip
To: $quickadd_dir/quickadd.zip, where the value of $quickadd_dir is /var/root/quickadd

Moving the download location to /var/root/quickadd means that the download is going to a location inside the root account’s home directory. Only root has write access to its home directory, which stops an account which doesn’t have root privileges from being able to swap out the .zip file.

Changes to CasperCheck:

Fortunately, the changes needed to implement this fix are minor and are in two places:

The quickadd_zip variable has changed:

From: /tmp/quickadd.zip
To: $quickadd_dir/quickadd.zip, where the value of $quickadd_dir is /var/root/quickadd

 

The update_quickadd function has been updated, to move the following actions to be first:

• The creation of the /var/root/quickadd directory, if that directory is not already present
• The removal of existing files from the /var/root/quickadd directory

 

 

I’ve posted an updated CasperCheck script with the described changes to the following location:

https://github.com/rtrouton/CasperCheck/blob/master/script/caspercheck.sh

If you’re a CasperCheck user, I recommend updating to the latest version at your earliest convenience.

The changes to the script can be seen here:

https://github.com/rtrouton/CasperCheck/commit/35e4e1d6ba9f363b894b36535b151637eb70602e

 

Hat tip: Thanks to Todd to alerting me to this issue and providing help to fix it.

Updated CasperCheck now available

JAMF announced today that, due to changes that are coming in OS X 10.11, Casper’s jamf binary will be moving its location in a future release of Casper. For those not familiar with Casper, the jamf binary is the agent software which Casper installs on Macs in order to manage them.

---

Update – 7-30-2015: JAMF clarified that the new location is going to be /usr/local/bin/jamf, instead of /usr/local/jamf as I originally understood it to be. I’m updating this post and CasperCheck with the new path information.

---

Current location:

/usr/sbin/jamf

Future location:

/usr/local/bin/jamf

From today’s announcement, it also appears that the jamf binary will not be moving on all versions of OS X:

Mac OS X 10.5.x – 10.6: The jamf binary will be staying in /usr/sbin/
Mac OS X 10.7.x and later: The jamf binary will be moving to /usr/local/bin

Now that this information is public, I’m releasing an update to CasperCheck that should be able to handle checking for the Casper agent in both its current and its future locations. For more information, see below the jump.

CasperCheck – an auto-repair process for Casper agents

One of the issues that I occasionally run into in my shop is that sometimes the Casper agent on individual Macs stops working properly. They stop checking in with the Casper server, or check in but can’t run policies anymore. I’ve set up smart groups on my Casper server to help me identify these machines, but actually fixing them has not been an automated process.

While at the JAMF Nation User Conference in October 2013, I was fortunate enough to hear Mike Dodge and Ajay Chand talk about the challenges they faced at Facebook with keeping Casper agents working in an environment where users are encouraged to break down any obstacle that gets in their way (sometimes, the obstacles in question were perceived to include the Casper agent.) As part of their talk, they mentioned they had a scripted way to verify that the Casper agent was running properly and automatically fix it if it wasn’t. This was a capability that I wanted to include in my own environment, so I asked them if this was going to be available at some point. They said it would be, so I waited to see what would be released.

At this point, the story fast forwards to March 2014, where the Facebook team was able to release their code to GitHub and I was able to take a look and see what they had done. I saw that I could adapt some of their work, but I would need to do additional work on my end to develop a solution that not only worked in my environment, but would be relatively straightforward to adapt to work in others’.

After a lot of work and testing, I’m happy to announce the release of CasperCheck. This is a script-driven solution that will do the following:

A. Check to see if a Casper-managed Mac’s network connection is live

B. If the network is working, check to see if the machine is on a network where the Mac’s Casper JSS is accessible.

C. If both of the conditions above are true, check to see if the Casper agent on the machine can contact the JSS and run a policy.

D. If the Casper agent on the machine cannot run a policy, the appropriate functions run and repair the Casper agent on the machine.

For more details, see below the jump.