On Fri, 01 Oct 1999 14:39:20 EDT, Chris Keane writes: > > Surely this still isn't ideal, though? It now won't overwrite root-owned > files, so the security hazard isn't there, but anyone on the system can > still fool a user into overwriting one of his own files, which is not > great. > > Or have I missed something? The directory where the bind() is done has mode 0700 (accessible by owner only). Only the user himself (or root) can write there; sshd already takes measure to ensure that this is the case before it will use the directory. The threat we're talking about is of the user himself tricking root. Unless *I've* missed something. By the way: at one point, I suggested redefining SSH_AGENT_SOCKET_DIR in newchannels.c to "/var/run/ssh-%.50s" as a possible (albeit untested!) remedy. After closer inspection, I now see that this does *not* help. (sshd gives ownership of the created directory to the user, so even if that directory is under /var/run/, the attack is still possible.) Many readers are probably confused about this issue, so I'm going to try to summarize for the benefit of those who just want to know what they should do to protect themselves: - If the demo program I previously posted reports the message "bind() returned EADDRINUSE; this system appears to be okay" on your systems, you have nothing to worry about. - If the program reports "bind() succeeded; this system appears to be vulnerable," then it's possible for *local users on your system* to carry out a denial of service attack. * If your users are trustworthy, you don't need to panic. If one of your users does attack your system, you probably won't have much trouble figuring out which user was responsible. * If your users tend to be mischievous, you should try to take one of the following measures: a) Get a fix for your operating system from your vendor, if one is available; or, b) See below for various ways to patch sshd; consider waiting a few days first, for others to have a chance to scrutinize the patches for problems. I've counted about five patches/fixes for sshd proposed on Bugtraq so far: * Sylvain Robitaille and Eric Griffis each posted a patch which is *mostly* effective. It doesn't completely eliminate the problem, but it makes it a lot harder to exploit, and is better than nothing. Eric's patch is the simpler of the two; if one was going to use one of these two patches, it's the one I'd personally recommend, without prejudice to Sylvain. * I suggested perhaps redefining SSH_AGENT_SOCK_DIR in newchannels.c; as I said above, this method is *ineffective*, and shouldn't be used. * Jeff Long posted a patch which tries to fix the problem by temporarily revoking privileges before the bind() call, but which does not quite completely fix the problem on systems which allow multiple simultaneous group memberships; he posted a subsequent version (pending moderator approval, as of this writing) which appears to fix that problem properly, although he warns that it may not compile as-is under all operating systems. The patch also could be simplified, but it looks like it does the job. * Scott Gifford posted a patch which appears to solve the problem by using a directory which is writable only by root. I could easily have missed something, but I don't see any obvious weaknesses in Jeff's latest patch--the one that includes the initgroups() call--nor Scott's patch. Others, I'm sure, will inspect these patches and report if they find any problems with them. Jeff and/or Scott may wish to send their patch to DataFellows, and ask them to incorporate one patch or the other into a 1.2.28 release. I wouldn't hold your breath waiting for an official SSH patch, though--DataFellows has been known to be less than prompt in the past at fixing bugs they don't think are important, especially ever since they released SSH 2.*. I hope this clarifies things a bit. -- People shouldn't think that it's better to have Dan Astoorian loved and lost than never loved at all. It's Sysadmin, CS Lab not, it's better to have loved and won. All djastat_private the other options really suck. --Dan Redican
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:06:34 PDT