Jump to content

OS X client 6.0.108 installed pitond setuid root and world-writable!

Recommended Posts

Hi all --


I've just recently started planning an upgrade to Mac 6.0 Server (as the 5.1 has been so solid for so long) and the first thing I examined was the Mac client, version 6.0.108.


Much to my horror, on two different machines running 10.3.5 and the Retrospect client 5.1.109 the installation of client 6.0.108 gave me the pitond file with mode 4777 - in other words, setuid root and writable by user, group and **world**. In fact, the entire /Applications/Retrospect Client.app was world-writable.


I think this is a bad situation; set-uid files should *never* be writable, expecially not by any user or process on the system.


Has anyone else seen this? Have I missed a technote somewhere? I'd be interested to know who else has world-writable permisisons on their client.


Try this in Terminal:

find /Applications/Retrospect\ Client.app -perm -4000 -ls


...and see if you get


-rwsrwxrwx 1 root wheel /Applications/Retrospect Client.app/Contents/Resources/pitond


Thanks, all!


-- Stefan W

Link to comment
Share on other sites

  • 1 year later...

I'm surprised nobody has commented on my post from more than a year ago. I hate to think about the number of machines out there that are vulnerable to a local root-privilege escalation because the Retrospect client installer is still so dumb as to make "pitond" setuid-root *and* world-write.


Recently I installed the latest client 6.0.110 on a Mac OX 10.4 machine, and *still* makes everything in

/Applications/Retrospect Client.app world-write, including the setuid binary.


Folks, this is a VERY BAD thing. I don't care what the platform is - in a Unix environment files (ESPECIALLY executables!) should never be world-write.


Please, until EMC / Dantz listens up and fixes this glaring security issue, do this or something similar on your Retrospect client machines:


% sudo find /Applications -perm -002 -exec chmod o-w {} \;


After that, if you do:

% find /Applications -perm -002 -ls

...you should get no results.

Link to comment
Share on other sites

  • 7 months later...

Simply amazing. It's happened again. What the hell is going on here? (A blatant disregard for basic Unix security, and nobody reading my posts, is apparently what is going on.)


On a client machine running 6.1.107 that had been audited for world-writable binaries & libraries (finding none), I performed an update to client version 6.1.130. Now I have world-writable files again, and the setuid root "pitond" is world-writable again!!!




To find the offending setuid-root binary, do this:


# find /Applications -perm -002 -perm -4000 -ls

1696283 960 -rwsrwxrwx 1 root 503 490336 Apr 6 16:18 /Applications/Retrospect Client.app/Contents/Resources/pitond


Then fix it with this:

# find /Applications -perm -002 -perm -4000 -exec chmod a-w {} \;


...so it looks like:

# ls -l "/Applications/Retrospect Client.app/Contents/Resources/pitond"

-r-sr-xr-x 1 root 503 490336 Apr 6 16:18 /Applications/Retrospect Client.app/Contents/Resources/pitond


However, this still leaves 112 other files & directories writable by anyone on the system. As I already mentioned, this is A Very Bad Thing in any Unix 101 class - but someone in EMC/Dantz can't figure this out.


# find '/Applications/Retrospect Client.app/' -perm -002 | wc -l


# find /Applications -perm -002 -ls | tail -4

1696282 16 -rwxrwxrwx 1 root 503 4439 Apr 6 16:17 /Applications/Retrospect Client.app/Contents/Resources/Japanese.lproj/prefPanel.nib/objects.nib

1696284 96 -rwxrwxrwx 1 root 503 47436 Apr 6 16:17 /Applications/Retrospect Client.app/Contents/Resources/RetroClient.icns

1696285 1240 -rwxrwxrwx 1 root 503 632196 Apr 6 16:18 /Applications/Retrospect Client.app/Contents/Resources/retropds.22

1696286 752 -rwxrwxrwx 1 root 503 381204 Apr 6 16:18 /Applications/Retrospect Client.app/Contents/Resources/retropds.24



Here's the final fix:


# find '/Applications/Retrospect Client.app/' -perm -002 -exec chmod og-w {} \;


...so you have nothing world-writable:

# find '/Applications/Retrospect Client.app/' -perm -002 | wc -l




Good luck to anyone using Retrospect on multi-user machines who doesn't find this!

I hope you are not owned.

Link to comment
Share on other sites

  • 1 year later...
  • 4 months later...

My testing earlier in 2007 and again yesterday and today shows that installation of the 6.1.130 client, using the RCU file on the Mac OS X client update that is presently downloadable from EMC and for all prior versions of the client, and installing using "update" from Retrospect Workgroup 6.1.138 released yesterday, still leaves the pitond permissions world-writable setuid root:


g3imac:~ admin$ ls -l /Applications/Retrospect\ Client.app/Contents/Resources/pitond

-rwsrwxrwx 1 root 503 490336 Apr 6 2006 /Applications/Retrospect Client.app/Contents/Resources/pitond

g3imac:~ admin$


Link to comment
Share on other sites

To make sure the client is installed with the latest permissions, please do an uninstall and install with the latest client version. We will look into ways to apply these security changes in a future .rcu package.


For many security conscious customers, the RCU process has never worked because Anti-Virus software prevents the client from being updated over the network without user intervention. For those users, they are already doing local installs when a new client is released. Being that this security issue was fixed in the main installer several years ago, I suspect most users have already corrected the problem.

Link to comment
Share on other sites

Ok, thanks for the clarification on the install process. Further testing shows that, if you manually change the pitond permissions (e.g., sudo chmod o-w pitond) for the client so that the exploit is not available, the RCU update will not make pitond world writable again. The uninstall/install process seems to work, too.





Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...