Re: [Fwd: Truth about ssh 1.2.27 vulnerabiltiy]

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

On Thu, 30 Sep 1999 15:04:14 EDT, Eric Griffis writes:
> This race condition was pointed out to me a little while before my message
> made it to the list, and I am still puzzled as to how one would get the
> timing right to perform such a maneuvre. Is there a way to somehow detect
> that there's been an lstat performed without being superuser?

It *might* be theoretically possible to detect the lstat(), if you could
make /tmp/ssh-username point to a remote filesystem on a server that's
under the user's control, but even if it's possible, it's probably not
easy.

A hacked ssh client/agent might also be able to have inside information
about when it's about to send the request for agent forwarding.

However, suppose the program merely guesses at the timing.  Even if you
lose the race, you can just keep retrying until you win the race; you
only have to get it right once.  In other words, if the odds of getting
it right are one in a million, try it a few million times.

> Also, I think the amount of processor time it takes to create a symbolic
> link is multiple times larger than the amount of time between the return of
> lstat and actual socket creation,

All it takes is for the scheduler to decide to end sshd's time slice at
an inconvenient time--and the context switches relating to the system
calls are probably good candidates for that.

> Okay, I see a few other messages about popen, permissions and such... At the
> moment, I believe disabling remote agent services entirely is the only sure
> way to remedy the whole issue, which will require password authentication.
> And sshd needs to be run as root to perform authentication. I don't think
> there's an easy way around that one.

Disabling agent forwarding is probably overkill.  (It would nevertheless
have been nice if sshd had a way to disable agent forwarding from
/etc/sshd_config, but that's neither here nor there.)

Until we apply the kernel patch which Alan Cox is producing (has
produced?) for Linux (the only vulnerable OS I personally have to deal
with), I'm employing the following workaround: if someone uses this DoS
on one of our systems, I'm going to go kick his ass.  The system logs
and the timestamp on the /etc/nologin file created by the denial of
service makes it fairly straightforward to track down the idiot
responsible.

Jeff Long's patch is the sort of method I had in mind for fixing the
problem properly.

I'm not sure whether there are other credentials which the code should
also be giving away--for instance, if root belongs to supplementary
groups, then perhaps directories that are writable by those groups might
still be attacked by the exploit.  It would be worth testing whether
this is the case.  If so, perhaps an appropriate "initgroups(...)" would
help?

One could also include Eric Griffis's code to do the lstat() beforehand,
in conjunction with Jeff's fix, if one wanted to.  Adding the lstat()
check is safe and effective, and there's no reason not to do it in
addition to the other mechanism for fixing the flaw.

And here's yet another option.  I have *not* actually tried the
following, but from a quick reading of the code, I *think* the problem
could be eliminated by adding this quick hack to newchannels.c, anywhere
after the #include's but before the definition of
auth_input_request_forwarding():

#undef  SSH_AGENT_SOCKET_DIR
#define SSH_AGENT_SOCKET_DIR "/var/run/ssh-%.50s"

This overrides the definition in ssh.h (for sshd, but not for
ssh-agent), and *should* cause SSH agent sockets to be created under
/var/run instead of /tmp when the agent forwarding is being done by sshd
(but not when it's being done by ssh-agent).

I'm assuming here, of course, that /var/run exists and is writable only
by root; feel free to substitute a more appropriate directory name if
you don't like this one.

Try this fix at your own risk.  People with more spare time than I have
should feel free to test whether this fixes the problem, and report back
to the list whether or not it does any good.

This "undef/define" fix is *not* compatible with Jeff's patch; if you
try to use both fixes, you'll definitely break agent forwarding.  Eric's
code change is compatible with both Jeff's and mine.

Hope this helps somebody....

--                          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