Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!execu!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F. Haugh II) Newsgroups: comp.unix.internals Subject: Trojan Horses Summary: Kernel support for SAK and trusted path Message-ID: <18578@rpp386.cactus.org> Date: 9 Oct 90 04:34:19 GMT References: <1990Oct7.155203.13283@hq.demos.su> Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 40 X-Clever-Slogan: Recycle or Die. In article <1990Oct7.155203.13283@hq.demos.su> avg@hq.demos.su (Vadim G. Antonov) writes: > Hi! I think the problem of login trojan horses has a quite simple > solution: > > 1) There should be UNMASKABLE method of killing all programs > reading this terminal. It may be a predefined sequence > of characters or a special hardware signal like BREAK or > CARRIER DROP. This feature should be hard-coded in TTY > driver. This is often refered to as "the secure attention key", or SAK for short. The idea is that some special key sequence is associated with the user wanting to validate the path to the system. By pressing the SAK sequence the user is certain they are speaking directly to the system, and not to a trojan horse. The BREAK key is a typical choice since it is baud-rate insensitive. Any key sequence which is dependent on the correct baud rate being set at any moment is likely to be circumvented by a clever hacker switching baud rates on you. > 2) All processes, associated with a TTY should be killed > (as SIGHUP does) andprotected processes should be > RE-ASSOCIATED with an unique TTY-id (which actually > does not exist). Killed is a tad strong. The only real requirement is that unauthorized access to the device be revoked. You can do this simply by marking a file table entry which references the device as "stale" and returning an error on any attempt (other than close, I suppose ...) to use that descriptor. In practice it seems that being overly agressive with your desires to kill processes makes users unhappy. Suitably privileged processes would be able to re-open the device, allowing daemons such as biff and month to avoid losing touch with reality ... You might want to get a copy of the DoD Orange Book, if you don't have one already. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson