brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/01/91)
In article <1991Mar30.202637.8629@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > The pty driver does not allow the master side to do an TIOCGPGRP on the > slave side (as they are running in different process groups, and POSIX says > that this should not happen for normal ttys). Idiotic. Absolutely idiotic. UNIX has always worked on the principle that if you have permission to open a file, you can open it, and use the descriptor forever. *Normal file access permissions handle security*. Now POSIX has to introduce more than thirty changes (by my count) to the tty and signal-handling systems, all in the name of tty security. Not a single change was justified by experience from more than one vendor, and most of them were entirely new. Few of them make sense. Why did POSIX make these changes? Because they did not understand that *normal file access permissions handle security*. They thought (correctly) that the tty subsystem was insecure, and they thought (incorrectly) that a bunch of ad-hoc changes would fix the problem. Convex UNIX 9.0 is a (supposedly) POSIX-compliant system. Not only does the OS follow every stupid POSIX restriction, but it introduces several new ad-hoc restrictions on tty access. You would think that this would eliminate all tty security holes. Not so. On every available BSD-based system---including Convex UNIX 9.0 and mainstream systems like SunOS and Ultrix---I can gain invisible write and TIOCSTI access to any tty, with a short program and no privileges. I sent such a sample program to Tom Christiansen not long ago, and it was both funny and sad to watch the ensuing panic. I keep telling people that the tty subsystem is insecure. I keep telling them how to fix it, with a simple set of basic changes, not the huge pile of inconsistent, senseless, ad-hoc rules that has found its way into every POSIX system. Berkeley still doesn't listen. Keith Bostic, are you listening? I'm sure someone will forward this to you if not. If I can write a program to break tty security under a standard BSD 4.4 setup, I will distribute that program as widely as I can. I guarantee you that this will happen if you do not make some fundamental changes to the BSD 4.3 + POSIX tty system. You think this is a threat? Then take it as a threat. It's only sympathy for the huge BSD 4.3 installed base that has kept me from distributing such a program already. BSD 4.4 will not have that installed base, and I see absolutely no ethical or legal reason to remain quiet about such a pervasive set of security holes. On the flip side, if you have enough interest in security to want to eliminate the holes, I'm perfectly willing to tell you how. You don't have to break POSIX compatibility (though it would be easier that way), and none of the necessary changes are very difficult (though again it would make a simpler system if you did put in more effort), and I'm not even going to pretend that you need a pty manager (though that would greatly reduce the number of lines you'd have to change in applications). Hell, you can get most of this information from Steve Bellovin. But if you're too lazy to ask, I'm not going to tolerate tty insecurity any more. > I found this in emacs, > incidently. The POSIX folks don't even understand backwards compatibility. Shameful. ---Dan
sef@kithrup.COM (Sean Eric Fagan) (04/01/91)
In article <4269:Apr105:57:0091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: (Dan and I have had this argument before, and we'll have it again 8-).) >In article <1991Mar30.202637.8629@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: >> The pty driver does not allow the master side to do an TIOCGPGRP on the >> slave side (as they are running in different process groups, and POSIX says >> that this should not happen for normal ttys). >Idiotic. Absolutely idiotic. UNIX has always worked on the principle >that if you have permission to open a file, you can open it, and use the >descriptor forever. *Normal file access permissions handle security*. So. I start a pty session, that means I can send any arbitrary signal to any process on the slave side? Gee, that doesn't sound right. The issue in question was that BSD pty's allow the master side of the pty to query (using TIOCGPGRP) to get the process group of the slave side. This is the same ioctl as one would normally use on a normal tty, to find out the process group of one's own tty. emacs then uses the resulting value to send a signal to it. This, incidently, does not work when the slave side of the pty is running under a different uid. Now: SCO's OS's never had this ioctl until 3.2, which added (broken until 3.2v2) job control. Therefore, they never had any backwards compatability. The reason sco doesn't do what berkeley does is because POSIX says that any process attempting to read (or do an tcgetpgrp, which essentially does the TIOCGPGRP ioctl in sco's implementation) shall have certain things happen under certain circumstances. For example, if the process in question is in a different pgrp than the tty in question, it shall get a signal (or something like that; I don't have 1003.1 with me right now, so I can't quote verbatim). In SCO's implementations of pty's, all ioctls, except for one or two, get passed to the tty driver, which is where the checks mentioned in passing above happen. Therefore, it doesn't allow that to happen. When I found this, it was too late to change it for 3.2v2, and, besides, I wasn't sure what should happen. So I enquired of the folks at CSRG, and a query was sent to the POSIX folks. CSRG responded with, essentially, "Ooops, we hadn't noticed that, you're right, here's what we're going to do," so I did what they said they did (although I want to confer with them again about it). Meanwhile, the POSIX query (as well as a query to rms) indicated that, since pty's are an extension, any behaviour is allowed by posix, so we could have "made" the old behaviour work. However, since I didn't like it, for a reason listed above, I didn't do that. (Besides, I liked the TIOCSIG ioctl 8-)). >Why did POSIX make these changes? Because they did not understand that >*normal file access permissions handle security*. Not entirely. Part of it is for *sanity*. Most of the changes I think you're referring to deal with what should happen when different pgrp's try to access a tty. Guess what: they all can have the same uid. I am not going to make any definitive statement without 1003.1 handy, though. Please tell me, for example, why a different process group should be able to change the pgrp associated with *my* tty? Since that pgrp may even be in a different session, on a different tty, but still have my uid, why should it be able to lock me out? >Not so. On every available BSD-based system---including Convex UNIX 9.0 >and mainstream systems like SunOS and Ultrix---I can gain invisible >write and TIOCSTI access to any tty, with a short program and no >privileges. Several people have commented that TIOCSTI is an abomination that should be forgotten. Neither SCO nor POSIX have it. >On the flip side, if you have enough interest in security to want to >eliminate the holes, I'm perfectly willing to tell you how. I think I asked you about your objections to POSIX, about a year ago, and you just complained that it broke things. Nothing about security. >> I found this in emacs, >> incidently. >The POSIX folks don't even understand backwards compatibility. Shameful. Gee, they broke some SysV'isms, yet I bet you don't complain about that. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (04/02/91)
In article <1991Apr01.083503.27317@kithrup.COM> sef@kithrup.COM (Sean Eric Fagan) writes: > In article <4269:Apr105:57:0091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Idiotic. Absolutely idiotic. UNIX has always worked on the principle > >that if you have permission to open a file, you can open it, and use the > >descriptor forever. *Normal file access permissions handle security*. > So. I start a pty session, that means I can send any arbitrary signal to > any process on the slave side? Gee, that doesn't sound right. Of course you can send a signal to a process on the slave side, provided you're the owner of that process. TIOCSIG is a separate abomination. > Please tell me, for example, why a different process group should be able to > change the pgrp associated with *my* tty? If a tty is in the filesystem, and it is writable to you, and accessing the tty for writing lets you change its pgrp, then you can change its pgrp. Why? Because that's normal UNIX security. The problem with the current BSD + POSIX setup is that you can go beyond the file permissions. > >Not so. On every available BSD-based system---including Convex UNIX 9.0 > >and mainstream systems like SunOS and Ultrix---I can gain invisible > >write and TIOCSTI access to any tty, with a short program and no > >privileges. > Several people have commented that TIOCSTI is an abomination that should be > forgotten. Neither SCO nor POSIX have it. Under SunOS and Ultrix, at least, I can also get *read* access, though this involves some race conditions. But write access is already a huge security violation. > >On the flip side, if you have enough interest in security to want to > >eliminate the holes, I'm perfectly willing to tell you how. > I think I asked you about your objections to POSIX, about a year ago, and > you just complained that it broke things. Nothing about security. You only asked for examples. Yes, my biggest complaint about POSIX is that in many cases it preserves *neither* the System V *nor* the BSD semantics. Instead it invents new, more complex semantics, with rationales as convincing as ``tty security'' (which they have failed to achieve). Did you know that the POSIX definition of ``background process'' does not agree with the BSD definition? So where does it come from? Why is it useful? There's *nothing* in the rationale to justify this change. > >> I found this in emacs, > >> incidently. > >The POSIX folks don't even understand backwards compatibility. Shameful. > Gee, they broke some SysV'isms, yet I bet you don't complain about that. I'm not familiar enough with System V to see where POSIX made silent changes. I can see some spots where POSIX changed from the System V behavior to the BSD behavior, and usually they tried to preserve the original semantics as a special case. If you show me some System V applications that break as badly as emacs, screen, atty, et al. under BSD + POSIX, I'll be glad to complain about them. However, tty security is a much more important problem right now for the real world, POSIX aside. I'll bet that your system hasn't closed any of the System V tty security holes that Steve Bellovin pointed out years ago. The latest I heard from Berkeley indicates that BSD 4.4 ttys will be just as insecure as BSD 4.3 ttys. WHY SHOULD EVERY SINGLE AVAILABLE BSD SYSTEM LET ANYONE BECOME ROOT? ---Dan