From owner-freebsd-security  Mon Aug  4 11:12:38 1997
Return-Path: <owner-freebsd-security>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id LAA16952
          for security-outgoing; Mon, 4 Aug 1997 11:12:38 -0700 (PDT)
Received: from kithrup.com (kithrup.com [205.179.156.40])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA16944
          for <security@freebsd.org>; Mon, 4 Aug 1997 11:12:34 -0700 (PDT)
Received: (from sef@localhost) by kithrup.com (8.6.8/8.6.6) id LAA21777 for security@freebsd.org; Mon, 4 Aug 1997 11:12:30 -0700
Date: Mon, 4 Aug 1997 11:12:30 -0700
From: Sean Eric Fagan <sef@Kithrup.COM>
Message-Id: <199708041812.LAA21777@kithrup.com>
To: security@freebsd.org
Subject: My last words on teh subject
Sender: owner-freebsd-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Period.  Get it?  Do not reply to this, do not offer me your opinion.

Having any resources shared across an exec is bad.  It is a completely
different address space.  Historically, no resources have been shared.
Not even environment space, which is arguably more useful than a shared
file descriptor space.

rfork() exists for two reasons, semi-related.  One is to offer a faster way
to create a process, by making the process creation more lightweight.  The
other is to offer support for threads; to do this, resources need to be
shared.  The latter is a change in the unix model, but one that has done
before, and will undoubtedly be done again.

One use for the latter is to have sh, make, init, etc., use rfork() instead
of fork().  Make it multi-threaded, that is, instead of what it is now.
This could result in some interesting performance gains.

But by having the SUIDness turned off, this breaks.  How useful is a /bin/sh
that can't run passwd?

You end up with non-traditional behavour -- the exec() succeeds,
but the program is not what it expects to be.  So it goes and
creates some files, or writes some data.  And, lo, the parent now
has access to any file descriptors it creates!  Including sockets.
Perhaps there was a password embedded in the program, or a key.
Perhaps it just tried to rely on some security thorugh obscurity.
Who knows, and it's not all that relevent.

The rfork fd table sharing across exec is not, primarily, a security issue.
It is a unix API issue.  As it was, it was *broken*.  Period.

The fact that this only showed up because of the SUID issue is irrelevent;
when I first read the description, my first thought was, "this is broken."

I don't care if OpenBSD got it wrong.  OpenBSD is not the model I base my
life on.  If I did, I would be breaking into systems all over the world
because someone annoyed me.

Sean.