[<prev] [day] [month] [year] [list]
Message-ID: <663a0880-a3d2-4a7d-b85d-3d0cc31cc021@oracle.com>
Date: Wed, 8 Jan 2025 15:31:03 -0800
From: Alan Coopersmith <alan.coopersmith@...cle.com>
To: oss-security@...ts.openwall.com
Subject: "/bin/sh: The Biggest Unix Security Loophole" paper from 1984
The Unix Historical Society has recently received and shared a copy
of a Bell Labs technical report from 1984 by James Allen titled
"/bin/sh: The Biggest Unix† Security Loophole" - the scanned doc is at:
https://www.tuhs.org/Archive/Documentation/TechReports/Bell_Labs/ReedsShellHoles.pdf
While this report reveals no real surprises 40 years later, it's conclusion
is advice that wouldn't sound out of place today:
Setuid programs (with the sole exception of the su command) should not
execute shells. Further, they should not execute any program whose
name does not begin with a slash. In all cases they should check their
arguments *very* carefully. They should not call any of these dangerous
subroutines:
execlp
execvp
popen
system
The last two of these (as we saw above) can involve execution of extra
shells not intended by the programmer. Each call to any of the above,
or to any other form of exec should be preceded by a setuid(getuid())
if at all possible.
The typical UNIX system has too many setuid programs.
This should serve as additional reference for how long we've known about
and had to fix shell injections and similar bugs. Fortunately when
discussing other classes of bugs, it's prediction that "it is very unlikely
that UNIX will ever be immune to this kind of loophole" has not stood the
test of time as well.
--
-Alan Coopersmith- alan.coopersmith@...cle.com
Oracle Solaris Engineering - https://blogs.oracle.com/solaris
† UNIX was a trademark of AT&T Bell Laboratories when that report was written.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
