git-core requiring macports' ssh on leopard, openssh security concern

[bcbarnes@…]

I recently installed git-core via macports on OS X 10.5.5 (intel). macports 1.6.0 recently selfupdate'd.

As a dependency, the port openssh was installed. Due to the way the postflight script sets paths, /opt/local/bin is searched before /usr/bin . Therefore, ssh and ssh-keygen from the openssh port are used by default instead of the OS X ssh utilities.

This raises two concerns:

1. Security. If a vulnerability in ssh leads to an intrusion on my local machine, my company can blame Apple, or Apple can provide security patches in a timely fashion. Relying on macports for system security is not a preferred situation.

2. Why was this needed at all? In Tiger or Leopard, ssh is available by default. The openssh port should not be installed on Leopard if the normal system ssh may simply be used instead. It takes up disk space for no reason.

I really, really do not like macports hijacking a system utility related to security. At the very worst, the openssh port should install its binaries with names such as ssh-mp (for -macports), similar to how the gcc42/gcc43 ports install their compilers with a -mp extension. Then ports which must use the openssh port instead of the system ssh could reference the renamed executables.

Thanks for reading.

[blb@…]

I definitely wouldn't call it hijacking as /usr/bin/ssh is still present and usable just as before. Feel free to rearrange your PATH as needed, as /opt/local/bin isn't an absolute requirement (it just makes it easier when you want something installed from MacPorts to override something installed with the system).

Also, when using 'Remote Login' in System Preferences, it will still use Apple's sshd so the only security issue would be when using ssh as a client (or if you specifically enable the MacPorts openssh launchd item, which is off by default).

Finally, the reason it's used in the first place is that MacPorts tends to prefer installing dependencies on its own instead of relying on what Apple provides, see the ​FAQ entry about this.

[raimue (Rainer Müller)]

How should using ssh as a client lead to intrusion into your network?

I remember a comment by Bryan Larsen that openssh is used from MacPorts because it is needed at compile time for git, that means it is bundled to a specific version. Therefore we need to declare a dependency to be able to do upgrades when needed.

gcc is a different case, because the gcc provided by Apple is highly patched, e.g. to support building for multiple architectures (-arch options). The use of Apple's gcc is preferred. Also there is the gcc_select port to choose from multiple installed versions.

[bcbarnes@…]

Replying to blb@…:

I definitely wouldn't call it hijacking as /usr/bin/ssh is still present and usable just as before. Feel free to rearrange your PATH as needed, as /opt/local/bin isn't an absolute requirement (it just makes it easier when you want something installed from MacPorts to override something installed with the system).

I removed git-core, changed the PATH as suggested, and recompiled/installed git-core. Everything works fine; the macports binaries of openssh are apparently not required for git to function properly on OS X 10.5.5 (intel). If that is true, I would prefer that they were not installed...

I still find it slightly bad that the postflight script puts the macports path first, and then some ports replace critical system utilities. In what other cases does this happen? Is there a list?

[bcbarnes@…]

Replying to raimue@…:

How should using ssh as a client lead to intrusion into your network?

Well, if you google for openssh client vulnerabilities, there are several thousand links to sort through, but here is a recent example: ​http://www.ubuntu.com/usn/usn-612-2 the famous RNG problem with debian and ubuntu openssh. That's applicable here because if a similar problem existed for macports' ssh, well, the first thing I did after installing git-core was run ssh-keygen, which was run by the macports binary by default.

There are other older examples of ssh client problems with X11, ssh-agent, and other issues. And who knows what lies in the future? The point is, a security-critical utility is being overrode by macports without warning, or need. If macports disappeared one day, I would have degraded security, thinking that OS X patches of ssh would be helping me, when in fact they would not. Think about the average user who doesn't know to check their path or the trac...

I remember a comment by Bryan Larsen that openssh is used from MacPorts because it is needed at compile time for git, that means it is bundled to a specific version. Therefore we need to declare a dependency to be able to do upgrades when needed.

As noted in the previous reply of mine, I uninstalled git-core, changed my path, reinstalled it, and it worked fine. So at least the binaries are not being referenced by names such as ssh instead of absolute paths. openssh is also listed as a runtime dependency instead of a library (or build?) dependency. Maybe there's more to this, and if so, I hope Bryan can clear it up. If the binaries need to be used during build, then perhaps they could be renamed as ssh-mp instead of the system name, ssh? Hey, maybe I'm wrong, but I've tried to prove myself wrong with that test and it still worked.

gcc is a different case, because the gcc provided by Apple is highly patched, e.g. to support building for multiple architectures (-arch options). The use of Apple's gcc is preferred. Also there is the gcc_select port to choose from multiple installed versions.

Ok, but I would think that something so important as ssh could be treated as a special case as well. Apple does carefully maintain the security of their OS. However, based on investigations so far, there may be no need at all for macports to install openssh on OS X 10.5. I understand that macports prefers to install a variety of dependencies to promote smooth functioning across possible installs, but it does use the compiler, and it could use the system ssh in Leopard (and probably Tiger too). Why duplicate functionality when nobody has provided an example of it being needed? I mean, is it needed for OS X 10.3? :)

[blb@…]

Replying to bcbarnes@…:

I removed git-core, changed the PATH as suggested, and recompiled/installed git-core. Everything works fine; the macports binaries of openssh are apparently not required for git to function properly on OS X 10.5.5 (intel). If that is true, I would prefer that they were not installed...

Note that the PATH used by port is not the same as your PATH, it sets it up so that MacPorts' prefix is always first, so it most likely still uses the ssh in MacPorts.

I still find it slightly bad that the postflight script puts the macports path first, and then some ports replace critical system utilities. In what other cases does this happen? Is there a list?

This is for usability as otherwise there are numerous people who do want the MacPorts-installed items to override what's in /usr, again you are quite free to change this (I myself don't have it first in my PATH).

[blb@…]

Replying to bcbarnes@…:

Well, if you google for openssh client vulnerabilities, there are several thousand links to sort through, but here is a recent example: ​http://www.ubuntu.com/usn/usn-612-2 the famous RNG problem with debian and ubuntu openssh. That's applicable here because if a similar problem existed for macports' ssh, well, the first thing I did after installing git-core was run ssh-keygen, which was run by the macports binary by default.

Note that MacPorts doesn't think we can do better than the original authors of software, so there won't be any functionality-based patches in MacPorts like what Debian did. The vast majority of patches applied are to get it either to work with MacPorts' prefix and to build in the first place. openssh is in fact one that has a few more patches, but these are two-fold: one is a "high-performance" patch which comes from psc.edu and only if you specifically select it with the +hpn variant; the other is a patch to get ssh to work better with Apple's launchd/DISPLAY functionality, and this patch comes from Apple.

There are other older examples of ssh client problems with X11, ssh-agent, and other issues. And who knows what lies in the future? The point is, a security-critical utility is being overrode by macports without warning, or need. If macports disappeared one day, I would have degraded security, thinking that OS X patches of ssh would be helping me, when in fact they would not. Think about the average user who doesn't know to check their path or the trac...

Very true about the future, you never know with software, but this applies regardless of your source; MacPorts is usually quite fast in updating ports to the latest version (popular ports are updated in hours or days when the new version is available upstream), so security issues fixed upstream are fixed here quickly.

[bryan@…]

The reason that the ssh dependency was added was because at one point in time the OS X ssh did not work with git for some reason. It was probably an older version of OS X that had this problem.

[maccheck@…]

I updated the Portfile and removed the run dependency for openssh. As a few tests (under 10.5.5) showed it didn't introduce any other errors. But I don't have access to 10.4 or 10.3 machines anymore.

I'll attach the Portfile patch here.

[bcbarnes@…]

Thank you for investigating this (maccheck)! I hope it works under Tiger and is committed to the port. I do not have access to a Tiger machine.

[maccheck@…]

I integrated the patch in the upcoming Portfile for git 1.6.0.3 (see #16955) as well.

[nox@…]

It's not in MacPorts policy to use a system software instead of the one provided by MacPorts itself, the only well-known exception is X11. I don't think we should make this exception for openssh too.

[maccheck@…]

I have to admit that I don't mind. As tested by myself both versions (with or without MacPort's openssh dependency) worked for me. Hence, I would go the road that an official MacPort's maintainer will guide me.

[bcbarnes@…]

Replying to nox@…:

It's not in MacPorts policy to use a system software instead of the one provided by MacPorts itself, the only well-known exception is X11. I don't think we should make this exception for openssh too.

Well, I have no problem with *this port* using openssh installed by macports. To reiterate my original concern, it's that the combination of the installed binaries' names and the modification to $PATH by the macports' install script results in the system-wide default ssh being the macports' ssh, instead of Apple's ssh (again, by a default install of macports and git-core). Perhaps a compromise could be reached by either changing the default order in $PATH, or the executable names of the openssh binaries (similar to how the gcc4x ports have binary names which do not conflict with the system compilers). The openmpi package also uses different binary names by default. This being said, I'm just a macports user, and have no position to tell you all what to do. I just think this is a reasonable solution. When I use macports and find something not working as I would hope, I file a ticket and try to be constructive, instead of just complaining somewhere that "macports sucks". Macports is great. I want to continue using macports when possible for my third-party open source software installs, but continuing to subvert the system ssh by default would drive me away from macports my git installation.

Is there a list somewhere which shows what other OS X /usr/bin or /bin executables may be trumped by a macports port install? I imagine something like emacs may be in such a list, but I think replacing the default emacs is much less scary than replacing ssh :)

Please consider the point of view of the security-paranoid end-user, busy IT admins, and people who do not often upgrade outdated ports when finalizing this change. Thanks for reading.

[bcbarnes@…]

Ah, if it's not entirely obvious by now, my concern I suppose has more to do with the openssh port than the git-core port. Perhaps the openssh maintainer should be cc'd on this if he is not already. Removing the dependency for the git-core port mitigates the problem for me right now (and I'm entirely happy with that change), but anyone installing openssh via macports is subjected to my security concerns talked about above. I do not know what other ports, if any, require the openssh port as a dependency.

[blb@…]

openssh removed as a dependency in r41984 per update in #16955.

[ryandesign (Ryan Carsten Schmidt)]

Replying to bcbarnes@…:

Ah, if it's not entirely obvious by now, my concern I suppose has more to do with the openssh port than the git-core port. Perhaps the openssh maintainer should be cc'd on this if he is not already. Removing the dependency for the git-core port mitigates the problem for me right now (and I'm entirely happy with that change), but anyone installing openssh via macports is subjected to my security concerns talked about above. I do not know what other ports, if any, require the openssh port as a dependency.

openssh has no maintainer, so anybody should feel free to make appropriate changes to it. sshfs and dsh declare a port dependency on openssh, while dsocks, scponly and rsnapshot only declare a binary dependency on ssh, falling back to the openssh port if necessary.

[(none)]

Milestone Port Bugs deleted