Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Vulnerability in 4.4BSD Secure Levels Implementation
From: abc () RALPH ML ORG (abc () RALPH ML ORG)
Date: Fri, 12 Jun 1998 13:21:18 -0600


The key word is "should" draw attention.  Unless there is an
application (or the system itself) that periodically checks for any
change in status of a system daemon (like the change of a PID), I
suspect that most sysadmins will not even notice that a system daemon
has died and restarted.  To help plug this vulnerability one of the
following options might be desirable,

Many sysadmins in control of operating systems which have the
immutable/no-unlink flags don't use those flags at all.

following options might be desirable,

1.  Disallow sending signals to processes started from immutable
binaries,
    except from init, e.g. during shutdown.
    Advantage:  Improved security.
    Disadvantages:  Administration may be virtually impossible and may
break
    existing applicaitons.

While I agree that the signal issue is very messy, I don't think this
is a good idea.  The obvious reasons include being able to keep a handle
on an out-of-control process.  This would also be a great help to an
intruder who doesn't like his/her processes being killed.

1a. A variation of #1 except using a new "unkillable" flag which denotes
    immutable binaries that cannot be sent signals.

Same problems.

[...]

3.  Replicate the immutable flag when a file is copied.
    Advantage:  Some improved security.
    Disadvantage:  Intruder can FTP a rogue daemon and run it instead.

Reliably implementing this would be impossible.  The system has no
real way of knowing whether or not a file is being opened for the purpose
of its duplication, and making guesses at that could just lead to
big problems.

--
cstone   <cstone () pobox com>  <abc () ralph ml org>



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]