Possible privilege escalation with group writable directories

[macports@…]

I noticed most of the directories in /opt/local are writable by the group 'admin': the local administrators, from a standard MacPorts DMG install (OS X 10.5). This means I can delete and add (and therefore replace) files in those directories, also things that will be run as root at some point (the prime example the 'port' binary itself), without having to authenticate with my login password... which is what you need to do everywhere else when possible root execution is involved.

So this means any process being run as my non-root account could indirectly execute arbitrary code as root without me elevating the privileges explicitly, unless I constantly check if the port command (or some other binary I'd use as root and installed from MacPorts) hasn't been tampered with. Effectively, this destroys the entire purpose to run as a restricted account by default.

I don't see this group writable permission being really necessary, since the files only get updated by root when port is run and no-one else would need to write in these directpries (especially not in the bin or lib directories). Requiring everything to go through sudo to do anything inside /opt/local would fix this issue.

[jmpp@…]

I'll look into this. I don't personally recall having some directories group-writable in a default MacPorts installation, so if you could give me an example I'd appreciate it! Also, what's the link to the dmg that you used?

-jmpp

[mww@…]

Basically this is correct: There is no need for e.g. ${prefix}, ${prefix}/bin, .. to be group-writable;

Nevertheless this gives you no privilege escalation, as on Mac OS X all users that do have administrator rights are in the 'admin' group -- and no one else. IF you manually add someone to the admin group AND revoke his/her rights to use sudo THEN there could be a privilege escalation, yes. This case seems rather unrealistic on OS X, but this should be fixed though.

[macports@…]

I've used this file from the downloads section:

​http://svn.macosforge.org/repository/macports/downloads/MacPorts-1.5.0/MacPorts-1.5.0-10.5.dmg

I erased my entire MacPorts installation and started over, this time with an installation log. Almost all directories (including /opt/local itself and its direct children) became permission mode 0775 after the installation was done, but were 0755 before the selfupdate phase started during installation.

I attached the installation log to this comment, it looks like /usr/bin/install sets directories mode 0775 during its work, and files 0644.

As a local administrator I can do things as root, but I'd always know about this before it happens since I have to enter my credentials. Being able to write as my regular admin user to an executable file which then gets executed as root would remove that requirement. In this case I trust an executable to behave nicely as root, while I (and so any process I run on the machine as my regular admin user) can modify it without requiring root access.

I admit 'privilege escalation' maybe wouldn't be the right term here, since I already have the privileges if I want to... but I don't have control over what process I grant these elevated privileges to (no password challenge).

[macports@…]

Summary: when I do a 'sudo port' command to manage my MacPorts installation, I'd have to check first if the port binary isn't changed by my regular user to prevent possible injected malicious code from executing as the root user.

Note: I noticed I cannot download my own attachment correctly, it ends up being only 12 KB while it should be 77 KB. I'll retry uploading it and see if that fixes it...

[nox@…]

/usr/bin/install uses 0755 by default:

     -m      Specify an alternate mode.  The default mode is set to rwxr-xr-x
             (0755).  The specified mode may be either an octal or symbolic
             value; see chmod(1) for a description of possible mode values.

The problem comes from base/doc/prefix.mtree generation, specifically the DSTMODE macro default value defined in aclocal.m4​.

[nox@…]

Patch to fix the default destination mode in aclocal.m4

[jmpp@…]

Thanks for this report and to N_Ox for the patch, which was committed in r30814. Closing ticket.

-jmpp

[tobypeterson]

Milestone MacPorts base bugs deleted