Path: utzoo!attcan!uunet!husc6!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Finding Passwords
Message-ID: <24208:Sep2803:36:2090@kramden.acf.nyu.edu>
Date: 28 Sep 90 03:36:20 GMT
References: <4086@auspex.auspex.com> <3346:Sep2422:01:3090@kramden.acf.nyu. <936@mwtech.UUCP>
Organization: IR
Lines: 30

In article <936@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes:
> In article <3346:Sep2422:01:3090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> >You cannot reliably *detect* a Trojan Horse unless you can reliably
> >*avoid* a Trojan horse.
> Agreed. You cannot do it ... at least not before login, but I think
> there are some ways to know really soon if you have been trapped by
> a trojan login, and even to find out who installed it.

Uh-uh. If a process gets your password, it can start an su to completely
switch to your uid, exec the su shell into a special program, pass the
tty file descriptors and any other relevant state to that program, and
finally have the program exec your login shell. The system is in
*exactly* the same state as it would be if you had talked to the normal
login. If su doesn't do the trick, there's always rsh and rlogin and
even ftp to put in a fake mail server that you then execute. And none of
what you mentioned will work against a solution that uses ptys.

Looking at the login history doesn't work since the most effective
attacks manage to keep tty access after the attacker has long logged
out.

> I can see few changes to circumvent these security barriers. Especially
> it would hard for the trojan to correctly simulate the behaviour that
> occurs *after* your login without knowing your .profile.

Ummm, I really am talking about a Trojan Horse, not a spoof; a program
can run a shell under your uid within a fraction of a second after it
knows your password.

---Dan