[20921] in bugtraq
Re: SSH / X11 auth: needless complexity -> security problems?
daemon@ATHENA.MIT.EDU (Dale Southard)
Fri Jun 8 14:25:19 2001
To: Peter W <peterw@usa.net>
Cc: bugtraq@securityfocus.com
From: Dale Southard <southard1@llnl.gov>
Date: 07 Jun 2001 11:45:47 -0700
In-Reply-To: <20010606001740.D5700@usa.net>
Message-ID: <ub6iti8yvqc.fsf@zonker.llnl.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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 */
