Date: Mon, 4 Oct 1999 14:25:28 -0400
From: Dan Astoorian <[email protected]>
To: [email protected]Subject: Re: [Fwd: Truth about ssh 1.2.27 vulnerabiltiy]
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
[email protected] the other options really suck. --Dan Redican
