Whoever broke into the Debian servers did us a big favor by raising
awareness without causing any serious damage.
Seems like the critical link to be fixed is the vulnerability of daemons
that run with root privilege and receive input from users. The
other links in the chain are inherently insecure. We should not
rely, for example, on keeping developers' passwords secret. Anyone
with physical access to a developer's machine can install a key
logger.
Seems like we should have *absolute* security in the way these daemons
operate -- the kind of security we have in microprocessors that do not
allow a user process to enter supervisor mode. If that barrier were
any less than 100%, on a machine executing billions of instructions per
second, we would have 100 crashes per second just from random
(non-malicious) errors.
I'm no expert on OS design, but it seems like any daemon needing both
root access and input from a user process should be required to read that
input only through a special routine that does not allow anything
dangerous to pass. One of the arguments to the routine could be the
maximum length of the input, thereby eliminating any possibility of
reading a string so long that it overwrites executable code outside the
buffer area. See
http://www.Linux-Sec.net/Kernel/
for a picture of buffer overflow ( Thanks to Alvin Oga for pointing me to
this.)
So how many daemons need both root access and user input?
-- Dave
- Re: Debian Server Compromise -- A Fire Drill ?? Dave
- Re: Debian Server Compromise -- A Fire Drill ?? Isaac To
- Re: Debian Server Compromise -- A Fire Drill ?? John Hasler
- Re: Debian Server Compromise -- A Fire Drill ... Tom
- Re: Debian Server Compromise -- A Fire Dr... Johannes Zarl
- Re: Debian Server Compromise -- A Fi... Karsten M. Self