Threat modeling and MacPorts [was Re: security projects thoughts]

Tue Apr 19 14:03:51 PDT 2011

Howdy all,

So, that was quite some thread!   I've finally gotten all the way through it and have to say that the overall level of civility and "quality of discussion" was pretty darned high for an open discussion on The Intarwebs and I'm impressed that everyone managed to beat the signing discussion to death without actually attempting to beat one another to death in the process.  Well done, everyone - I'm genuinely impressed!   You may or may not know how truly rare that is.  :-)

That said, I think we covered a considerable amount of ground and conflated a whole bunch of different issues which may or may not have been amenable to such aggregation in that discussion.  What we clearly need to do now is devote some time to distilling down a set of tangible, mutually-defined goals that can go into Trac, and I think one way of doing that will be to try and at least agree on which threats are most important / highest in priority and which "non-security goals" need to also be prioritized in order to reach a state of affairs where security, vs flat-out missing functionality, is genuinely top-of-mind for MacPorts' user community (that would be a nice problem to have, I think).

So, rather than dive into a bunch of questions that are hard to answer ("who signs stuff?  who makes sure the signing machinery itself is not compromised?  who revokes things when and if it is?  who's going for pizza while we figure all this out??") since I think that can only lead to a lot of unanswered questions and a dying discussion, let's see if there are any questions we CAN answer or common definitions we can at least agree upon.   First off, let's make sure we understand the full and complete threat model, starting from one end of the food chain (or "sausage factory assembly line") to the other:

Step 1:  Source tarballs on random web/ftp sites.  I think we can all agree that the most fundamental part of the threat starts here.   Is an upstream tarball any good?  What about when it's updated in-place without changing the name or version # information?  Should the maintainer simply assume this was legitimate and update the checksums to match, should they contact the upstream maintainer (who's relationship with MacPorts is likely to be tenuous, non-existent or even openly hostile), should they refuse to update the port at all, or what?  I don't think there is any unified policy here, and if all that it takes for a trojan to infect macports is for someone to attack the tarball on its home web site AND for the maintainer to simply assume that this was intentional, it's game over regardless of the signing machinery.  We can't assume that all maintainers are watching all of the CERT advisories or even keeping a particularly close eye on their upstream providers since some maintainers have a lot of ports and they do it all in their spare time, so what level of assurance is really being provided here?  Do we get more or less assurance by caching all of the tarballs on Mac OS Forge?  It restores some level of control, but it also means there's one centralized location to attack now, too.   Again, this is more of a policy question than anything else since, lacking policy, everyone will always assume whatever's most convenient, not whatever's most secure.  That's just human nature.

Recommendation:   1a.  Sign the entire Portfile, including the hashes, and validate its authenticity from the port(1) command.  1b.  Declare a policy that any port which fails its fetch-time hash check needs at least 24 hours of scrutiny and at least one attempt to communicate with the upstream maintainer (note to self:  We probably need an "author" email address in the Portfile to distinguish this from the portfile maintainer) in order to ensure that this is not an attack against the upstream source.

Step 2:  The runtime behavior of individual ports during the build and installation process.  A lot of MacPorts runs privileged, of course, and it executes any number of custom Tcl procedures / shell scripts inside a given Portfile, including the chained invocation of a lot of custom build/install rules from the unpacked source tarball itself, all of which does god-only-knows-what, particularly when you include all of the dependencies in this list.  Step 1 validates that we got what we expected to get from the upstream site, sure, but it does nothing to ensure that the behavior of that port during build/install time (particularly the behavior that we ourselves added) is kosher.  At this level of "defense in depth" it's probably unlikely that actual malicious exploits will target this step so much as simple coding errors which will cause issues.  Say that someone writes a cleanup pass which removes some temporary files, but they forget to quote a variable expansion and now it suddenly encounters a path with spaces in it which never occurred during testing (users can name their volumes however they like, after all) and BOOM, the user is missing some files and the port is effectively a rogue until such time as it is detected and fixed.

Recommendation:  Run this part of the build/install process under a highly restrictive trace mode "chroot" which is aimed less at preventing exploits and more at simple damage mitigation from poorly written ports.  As I noted in a previous discussion, this would also be desirable for reasons of reproducibility and correctness - you don't want a port built on host A to be substantially different than one built on host B just because host B has different optional software installed.

Step 3: The MacPorts infrastructure itself.  Clearly, if I can compromise the project's MacPorts package delivery chain (http://www.macports.org/install.php), the MacPorts repository, or the physical on-disk contents of /opt/local/share/macports, I win even bigger because now I don't need to compromise the individual Portfiles (or the download hashes) themselves at all.  I can simply disable the signature checks and/or inject code into the build process for any given port such that any and all attempts to secure Steps #1 and #2 are effectively compromised and now we're very much in "false sense of security" territory.  Arguably, this is a much bigger problem than the previous 2 steps because attacking the MacPorts infrastructure gives me the keys to the entire store and is therefore a much more rewarding and attractive target.

Recommendation:  2a.  Sign the official MacPorts packages if they aren't already.  2b.  Make sure r/w access to the repository (and the machine hosting it) is very tightly controlled and that off-site backups are taken frequently enough to be able to at least diff a pre-exploit repo against a post-exploit repo, if only to determine whether or not the attacker actually did something there (a lot of this security is already provided by MOSForge, but possibly not the backups - Bill?).   2c.  Make sure that all of the MacPorts infrastructure files on-disk are properly owned by a privileged user and not easily modifiable by anyone else (including the build/install phases of individual ports when running as root).  Ordinarily I'd suggest code signing of all the relevant executables and libraries, but code-signing enforcement isn't fully enabled and yet does't work on shell scripts in any case (of which the port(1) command is one), so this is probably the best we can do for now.  We *could* of course compute all of our own hashes and sign them, validating them every time port(1) runs, but that's probably too expensive from a performance perspective - the port command is already slow enough as it is. :)

Step 4:  The legendary MacPorts Binary Packages.   Sure, we don't have them yet, but assuming that we do someday, they constitute a complete attack vector of their own which require "Steps 2 and 3" to be done in a package-centric way.  Namely, the packages need to be signed, the physical repository for them needs to be secure, and the runtime installation behavior of the packages needs to be sandboxed in the same way that trace mode "sandboxes" the build/install phases of ports.  A binary packages' installer can be attacked in any number of ways, or perform any number of untrusted operations at install time, and all of that needs to be secured appropriately.

Recommendation:  4a.  Sign packages in the same way that the MacPorts installer package is (or should be) signed.  4b.  Make the package installer (assuming it's not simply Installer.app) create an execution sandbox around the package installation phase such that its operations can be audited and/or gated for desirability.

Step 5:  Runtime behavior of MacPorts-provided software.   This is the hardest but possibly the most rewarding step of all since, ultimately, you'd really like to be able to provide a "plug-n-play" experience for software on Mac OS X where "plug-n-play" means that arbitrary software can be installed, run for some period of time, and then uninstalled again without leaving any traces behind, without compromising the system during its runtime, and without doing bad / unauthorized things to sensitive private data like emails, calendars, photos ("Oh Hai, I just mailed all the pictures of your sister to a photoshopping porn site!  Ha ha!")  and so on.

Recommendation:       This is clearly a sandbox challenge, and I'll be able to say a lot more about the whys and wherefores of that in the future, just not quite yet. :-)

Does that about cover it?   Did I miss anything?

- Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20110419/d09bf407/attachment-0001.html>