Xref: utzoo comp.unix.wizards:25265 alt.security:2375 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pcserver2!kdenning From: kdenning@pcserver2.naitc.com (Karl Denninger) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 4: What You Can Look Forward To Summary: MIPS has fixed the most obvious incantation of this. Message-ID: <1991Apr30.224740.17040@pcserver2.naitc.com> Date: 30 Apr 91 22:47:40 GMT References: <3600:Apr2614:04:4391@kramden.acf.nyu.edu> Organization: AC Nielsen, Bannockburn IL USA Lines: 34 In article <3600:Apr2614:04:4391@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >To close this series of postings, I'd like to briefly survey the state >of tty security. I'm sorry I haven't been able to respond personally or >quickly to everyone's mail on this issue. > >Just a few years ago I was exploring the depths of an old Ultrix system. >It didn't take a genius to notice the occasional background jobs gone >astray---obviously any user could affect any other user's tty, despite >vhangup(). Soon I had ``blip'', a reasonably powerful tty mode mangler >that could act both as a concise stty and as a tty security breaker. >With it I could write arbitrary text to anyone's tty, TIOCSTI terminal >input, change tty mode settings, send tty signals, and so on. MIPS has apparently fixed most of the ways this can be exploited. The most obvious attempts, taking over "unused" ptys slave ends, result in the system skipping them when assignment time comes around. This prevents the most obvious ways to exploit this hole. I believe MIPS may be using some form of "O_EXCL" to prevent multiple access.... The RS/6000 dynamically creates ptys, and thus doesn't suffer from the problem at all. ISC, Apple (A/UX), and Sun, DO have the problem. KUDOS TO MIPS ON THIS ONE. They got it right. -- Karl Denninger - AC Nielsen, Bannockburn IL (708) 317-3285 kdenning@nis.naitc.com "The most dangerous command on any computer is the carriage return." Disclaimer: The opinions here are solely mine and may or may not reflect those of the company.