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

[stefanw]

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

[stefanw]

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.

[stefanw]

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!!!

 

This is UNFORGIVABLE. This HAS TO BE FIXED.

 

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

112

# 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

0

 

 

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

I hope you are not owned.

[rhwalker]

It's still a problem in July 2007, almost three years after the original post. EMC obviously wants to invite hacker takeover of Retrospect client machines. Shame. Irresponsible programming and incompetent QA.

DANGER - SERIOUS SECURITY VULNERABILITY

 

Russ

[Mayoff]

We addressed this issue in 2005. The current client software does not have this problem.

[rhwalker]

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:

Code:

---

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$

---

Russ

[Mayoff]

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.

[rhwalker]

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.

 

Thanks.

 

Russ