BSD tty security, part 3: How to Fix It

[Robert Elz]

brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:

>> 	for (fd = 3; fd < ENOUGH; fd++)
>> 		close(fd);

>I pointed this out in the proposal. I also pointed out that it only
>affects programs which change fd 3 and then want to open /dev/tty

No, this is not true - it affects programs that close fd 3, then
exec any program that wants to open /dev/tty - the most common case
perhaps being those progs that have a '!' or 'shell' command, to
fork/exec an interactive shell, from which anything can be run.  This
is a much harder problem to fix - essentially it means that all progs
that close(3) and allow any other prog to be exec'd need to be fixed.

>The research UNIX people considered using 127, then decided
>that there wasn't anything so special about stdtty and made it 3.

Yes, I know - they have the luxury of fixing their entire environment.
Very few others do - vendors don't, they can't fix code supplied by
customers, or independant code suppliers.  Breaking code that customers
have written, or even worse, bought, is not something any vendor is
going to want to undertake lightly.

On the other hand, using fd -2 (not -1, that will cause stupid progs
that attempt to reference fd's after an open error to do weird things)
or 65535, or any other "unusual" number would not have these drawbacks.
Its much more work for the vendors in their kernels, but at least its
work that is mostly compatible with their current offerings.

kre