Xref: utzoo comp.unix.wizards:25631 alt.security:2544
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.wizards,alt.security
Subject: Re: BSD tty security, part 3: How to Fix It
Message-ID: <14021:May1521:56:2291@kramden.acf.nyu.edu>
Date: 15 May 91 21:56:22 GMT
References: <19270@rpp386.cactus.org> <25833:May1416:43:4291@kramden.acf.nyu.edu> <19276@rpp386.cactus.org>
Organization: IR
Lines: 67

In article <19276@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> Now, given that passwd can't verify who it is talking to, how can it
> possibly meet the assurances required to state that it isn't talking
> to a trojan horse?

You didn't answer my question. Are you going to restrict use of passwd
to people who can walk up to the console? If not, then you are always
vulnerable to eavesdropping, and it's the user's responsibility, not
passwd's, to make sure that nobody's looking over his shoulder.

It doesn't matter whether passwd can make your statement. All that's
necessary is that a normal user, under normal operation of the system,
will be able to start passwd in a safe way. That's what I've guaranteed.
If he later wants to do something stupid and start passwd in an unsafe
way, I can't stop him, and I see no reason that passwd should stop him.

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

Who tf cares? A sane user will never invoke such a pipe. It's not
passwd's responsibility to check that the user is sane.

Somehow we're failing to communicate here. My model is that the user
walks up to a console or makes a network connection, then types
something that (as the OS documentation guarantees) sends his future
keystrokes directly to the system and nobody else. If he then types his
username and password, nobody else gets the password. If he then types
passwd and changes his password, nobody else gets the password.

The problem right now is that there are all these security holes---the
system doesn't guarantee that nobody's looking on. My changes make that
guarantee, at least for the tty subsystem.

You seem to be in this fantasy world where the user intentionally
invokes a pipe to your recording wrapper around passwd. That's stupid.
He's going to do that about as often as he sends you his password by
e-mail. What problem are you trying to fix?

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

Perhaps you didn't read the suggestion. I don't just type my username
and password; I press the secure attention key, then my username and
password. Surely you're familiar with Multics?

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

Be serious. The whole point of a SECURE attention key is that it cannot
be violated by unprivileged applications (i.e., things outside the TCB).
And, as Bellovin told you, there's no need for an application to turn
off the SAK---you just make the SAK a variable-length signal if normal
data is fixed-length, and vice versa. This is a non-issue.

---Dan