On Thu, 2003-08-28 at 15:59, Gerald Combs wrote:
> - Some sort of privilege separation between the capture code and display
> code
I've been giving this considerable thought lately, although haven't
written anything formal yet.
I basically see two modes of operation for Ethereal -- these are the
common ways in which it is used. There may be other ways people use
Ethereal, in which case please speak up.
1. To read existing capture files -- requires no special privilege,
typically run under the non-privileged user account. A security hole in
the display code results in arbitrary execution as the non-privileged
user. While this is not as bad as execution as root, it is still not a
good thing.
2. To capture files and dissect the output. This typically requires
root, which is accomplished one of two ways -- either su to root and run
Ethereal, or configure the Ethereal binary as setuid. Either way, the
net effect is that Ethereal runs as root. Compromise of the capture
code results in execution as root -- definitely a bad thing.
Ideally I see two phases:
To reduce the amount of code that runs as root
To reduce the amount of damage that can be done by malicious code
running under the non-privileged user account.
The first part is clearly the more critical, especially given that I
believe many people, and definitely most people not conscious of
security, will run Ethereal as root, and any malformed packet can crash
their system or worse. I believe this is consistent with Gerald's
vision, given that this requires splitting out the display/dissection
code from the capture code. My initial thought regarding how to address
this problem is to allow the binary to be run setuid root (determining
who can run the binary will be dictated by group membership for a group
named ethereal). The program will start setuid root and start two
children. The first child will be responsible for operating the capture
interface. The second child will be responsible for the
display/dissection interface. The two can communicate via unnamed pipes
or some other transport. This will create a model where only the
capture code itself runs as root, everything else runs as the
non-privileged account. Further, only a problem in the capture library
itself, or the transport between the two daemons, can result in root
compromise.
The second phase is more ambitious, because it would require the bulk of
the dissection code to not run as either root or the non-privileged
user, but rather a third user account that does not have the privilege
of the regular user. We could have a user called "ethereal". The
setuid root copy of Ethereal starts, forks off the capture subprocess
(uid=root), forks off the dissection/display process (uid=ethereal), and
forks off the filesystem access process (uid=original user). The
filesystem access process is required in order to read captures that the
original user has access to, and to be able to save captures back to
disk. In this model, a compromise of the display/dissection code
results in arbitrary code execution as the "ethereal" user, which
effectively has no permissions. We might even be able to chroot the
process.
Ok, I've rambled enough for one afternoon -- I'm just trying to get a
dialog going on this issue, given that Gerald brought it up and I've
been thinking about it for a few weeks.
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc.
