Today, I reported two bugs in debian packages which
install binaries suid root. Both bugs were avoidable:
- Bug #21799 is dealing with /usr/X11R6/bin/xload's
permissions - Debian installs this program suid root,
while it doesn't need this privilege level. It became a
security breach by the recent Xaw buffer overruns.
Anyway, a 10 week old report (#19217) already deals with
this topic, but is declared as a "normal bug".
Apparently, it was not considered to be important enough
to be fixed in time.
Fixing this bug in time may have prevented one more
buffer-overrun exploit from working.
- Another report is dealing with /usr/bin/suidexec from
the suidmanager package (I did not yet get a
confirmation). Once this program is used for just one
suid shell script, it may be used to gain root access in
a rather trivial way. Even if suidexec would check for
the use of a shell which is (e.g.) listed in
/etc/shells, it can't control every shell's startup
behaviour. I'm thinking about csh reading and executing
$HOME/.cshrc right now - it's the old exploit against
/sbin/suid_exec on System V machines with the Korn and C
Shells installed.
This program should (IMTAO) never have become part of
the distribution. (Note that the rest of the
suidmanager package is actually quite nice. ;-) A short
glance over the manual page and source code gave me a
pointer in the right direction.
What are the conclusions from this?
First, the Debian Policy should be enhanced by a paragraph
on suid binaries. The policy should emphasize the least
privilege principle. It should require the use of
suidmanager when installing scripts suid root.
Further, the policy should require maintainers to tag bug
reports about programs running suid root "critical". (You
may also consider to add an option to the bug program
which tags a bug report as a security problem, and thus
"critical". This is also interesting for network programs
which have security breaches and/or denial of service
vulnerabilities.)
As an additional measure, one could enforce the
four-eye-principle with respect to including suid root
binaries in the distribution:
Introduce an suid-clearance package. It should install a
file in /etc which lists package name, package version,
file name, owner, group, and mode for _every_ binary which
is to be installed suid root.
This list should be consulted at three points:
- The Debian Installer should check for every package, if
all suid binaries contained therein have an entry in
that list. If a binary fails to have been registered,
the Installer should complain loudly to the package
maintainer.
For a transition period, one may still accept such
packages.
- While installing packages, dpkg-deb(8) should consult
the clearance list and warn the user about certain
programs not being in the clearance list.
- /usr/sbin/checksecurity should compare the clearance
list to the installed system and loudly complain to the
system administrator if it finds any differences.
- Additionally, the postinst script of that package itself
should perform the same check and complain loudly.
Now, what should the registration procedure look like?
I'd propose to require every maintainer who wants to
include a binary runnig suid or sgid anyone to file a
formal application with the suid-clearance package
maintainer. He should at least answer the following
questions:
- What privileges does the program get?
(suid root, sgid games, ...)
- What are these privileges required for?
(Bind to port 25, allocate a pseudo terminal, write to
utmp, ...)
- Are these privileges critical for the system's security?
(E.g., having xterm suid root is required for two
purposes:
- correct a pseudo terminal's ownership and permissions
- write utmp/wtmp entries
Correct pseudo terminal permissions are needed to
prevent other users from writing to the xterm window,
possibly subverting the account running xterm. The utmp
and wtmp entries aren't really critical.)
- What ways to additionally increase privileges are there?
(E.g., can _other_ programs be turned into trojan
horses? [This is especially interesting for games.] What
other programs/packages access the resources the
privileged program can manipulate?)
- Has the maintainer confirmed that the program is
designed to be run with said privileges?
- What kind of review has been done?
(E.g., the program is also part of these and that third
distributions, OpenBSD, etc., and the maintainer has
checked their patches available for additional security
enhancements.)
As time proceeds, tools for (e.g.) testing for buffer
overflows should be made available. Their application by
package maintainers should be required.
The applications should be made public on the Debian Web
Server. They should further be included in the doc
directories of the packages in question.
The suid-clearance package maintainer should check if the
answers to these questions are correct, and he should
verify if the privileges the program gets are actually the
privileges it requires. He may then grant or deny the
clearance and should work with the package maintainer to
get the package secure _and_ working, if possible. If it
is not possible to achive a secure mode of operation for a
specific package, it should not get the suid clearance.
This means that certain kinds of programs (like suidexec)
should _never_ get into the distribution.
As an additional level of "certification", packages may be
tagged "insecure", depending on previous experience or the
level of review (e.g., the BSD lpr, xbase, and sendmail
packages may be tagged "insecure", while qmail is tagged
"secure"). The installation procedure could then ask the
user for the system's security level and warn him if he
tries to install a package with a non-appropriate
certification.
The maintainers of packages which install programs with
increased privileges should forward any bug reports which
may contain security breaches to the suid-clearance
package maintainer. [This could be done automatically if
bug would offer a "security breach" tag for bug reports.]
Security breaches _must_ lead to the immediate removal of
a clearance from the suid-clearance package for versions
in question. Thus, users who regularly update the (rather
small) suid-clearance package are warned about recent bugs
and security breaches which apply to their systeem.
Clearly, maintaining the suid-clearance package will be a
rather time-intensive job. This means that it should most
probably be done by several people, each of whom will pick
the packages they work on.
Comments?
tlr
--
Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/
2048/CE6AC6C1 · 4E 04 F0 BC 72 FF 14 23 44 85 D1 A1 3B B0 73 C1
Attachment:
pgpUoopXZQwZP.pgp
Description: PGP signature