Xref: utzoo comp.unix.wizards:25704 alt.security:2595 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!viusys!uxui!unislc!harem!wes From: wes@harem.clydeunix.com (Barnacle Wes) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 3: How to Fix It Summary: Snooping hard-wired terminals, etc. Message-ID: <290@harem.clydeunix.com> Date: 20 May 91 14:25:46 GMT Article-I.D.: harem.290 References: <19262@rpp386.cactus.org> <10581:May1315:01:2891@kramden.acf.nyu.edu> <19276@rpp386.cactus.org> Organization: Clyde's Harem; Eunuchs Guard Lines: 62 Trojan horses: In article <25833:May1416:43:4291@kramden.acf.nyu.edu> brnstnd@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@rpp386.cactus.org>, jfh@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 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@harem.clydeunix.com ...!sun!unislc!harem!wes