BSD tty security, part 3: How to Fix It

[Barnacle Wes]

Trojan horses:

In article <25833:May1416:43:4291 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
% Eavesdropping (and data corruption) is no worse a problem for passwd
% than it is for any user program. If you want to solve those essentially
% physical problems, encrypt your data.

In article <19276 at rpp386.cactus.org>, jfh at rpp386.cactus.org (John F Haugh II) replies:
> Sure.  But I'm not even talking about eavesdropping, I'm talking
> about really simple stuff, like trojan horses.  What about a case
> where my application looks just like "passwd", but is really just
> a pipe or somesuch (like the "pty" command) from your keyboard to
> the real passwd command.

% Sure it does. Please read suggestion #24.

> I log in as "jfh", and start my trojan horse.  It displays a login
> banner.  You type "brnstnd".  I prompt for your passwd.  You enter
> it.  I stuff the username and password in a file and exit.  What
> does your scheme do to prevent that from happening on a hardwired
> terminal?

It doesn't.  Of course, there is no way you can really prevent such
things from happening unless you have only local terminals with physical
control.  Case in point:

I worked with a man several years ago who was such a pest on the
(VAX/VMS) system we used that I and several friends decided to take
away the privileges on his account.  Our accounts didn't have the
privilege to change his account, but his did, so we dragged a PC with
two serial ports into the wiring closet and spliced it into his
terminal line.  We wrote a simple program for the PC that passed data
back and forth between COM1: and COM2: while looking for the login and
password prompts and recording his responses.  That night, we logged
into his account, ran authorize, and took away all his privileges.  We
continued doing this for every privileged account he logged into for
the next several days.  Everything was quiet on the system for about 3
months after this attack, until he managed to get SETPRIV back.

Secure Attention Keys:

> As for using
> different SAK keys, what to do about UUCP, etc?

% This is a non-issue.

> It just goes to show that you've never bothered thinking about what
> the issues are.  How exactly would an application turn off the SAK
> key under your system?

Just make the SAK SEQUENCE a break (framing error).  This solves any
problems with UUCP, and if you have a ""-BREAK-in: sequence in your
send-expect strings, you'll get the secure port on login.  This may, of
course, disagree with any terminal servers you're using, but they can
usually be reconfigured to support a "local" key other than break.

	Wes Peters
-- 
#include <std/disclaimer.h>                               The worst day sailing
My opinions, your screen.                                   is much better than
Raxco had nothing to do with this!                        the best day at work.
     Wes Peters:  wes at harem.clydeunix.com   ...!sun!unislc!harem!wes