Re: [Fwd: Truth about ssh 1.2.27 vulnerabiltiy]

[djast () CS TORONTO EDU (Dan Astoorian)]

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
djast () cs toronto edu        the other options really suck.    --Dan Redican