Opened 17 years ago

Closed 17 years ago

Last modified 15 years ago

#13178 closed defect (fixed)

Possible privilege escalation with group writable directories

Reported by: macports@… Owned by: macports-tickets@…
Priority: Normal Milestone: MacPorts 1.6
Component: base Version: 1.5.0
Keywords: security base directories group writable Cc: nox@…, jmpalacios (Juan Manuel Palacios), macports-mgr@…
Port:

Description

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.

Attachments (3)

Installer Log 7-Nov-2007.txt.gz (11.7 KB) - added by macports@… 17 years ago.
Installer Log 7-Nov-2007.txt.bz2 (62.0 KB) - added by macports@… 17 years ago.
aclocal.m4-default-dstmode.diff (843 bytes) - added by nox@… 17 years ago.
Patch to fix the default destination mode in aclocal.m4

Download all attachments as: .zip

Change History (11)

comment:1 Changed 17 years ago by jmpalacios (Juan Manuel Palacios)

Cc: jmpp@… macports-mgr@… added

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

comment:2 Changed 17 years ago by mww@…

Priority: HighNormal

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.

comment:3 Changed 17 years ago by 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).

comment:4 Changed 17 years ago by 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...

Changed 17 years ago by macports@…

Changed 17 years ago by macports@…

comment:5 Changed 17 years ago by nox@…

Cc: nox@… added

/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.

Changed 17 years ago by nox@…

Patch to fix the default destination mode in aclocal.m4

comment:6 Changed 17 years ago by jmpalacios (Juan Manuel Palacios)

Resolution: fixed
Status: newclosed

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

-jmpp

comment:7 Changed 16 years ago by tobypeterson

Milestone: MacPorts base bugsMacPorts Future

Milestone MacPorts base bugs deleted

comment:8 Changed 15 years ago by jmroot (Joshua Root)

Milestone: MacPorts FutureMacPorts 1.6
Note: See TracTickets for help on using tickets.