COMMAND
	    Delegate
SYSTEMS AFFECTED
	    FreeBSD with ports collection before 2000-02-02
PROBLEM
	    Following is based on Security Advisory.  An optional  third-party
	    port     distributed     with     FreeBSD     contains    numerous
	    remotely-exploitable buffer overflows  which allow an  attacker to
	    execute arbitrary commands on  the local system, typically  as the
	    'nobody' user.
	    Delegate is a versatile application-level proxy.  Unfortunately it
	    is written in  a very insecure  style, with potentially  dozens of
	    different   exploitable   buffer   overflows   (including  several
	    demonstrated  ones),  each  of  which  could  allow an attacker to
	    execute arbitrary code on the delegate server.  This code will run
	    as the user ID of  the 'delegated' process, typically 'nobody'  in
	    the  recommended  configuration,  but  this  still  represents   a
	    security risk as the attacker may be able to mount a local  attack
	    to further upgrade  his or her  access privileges.   Note that the
	    delegate utility is not installed  by default, nor is it  "part of
	    FreeBSD" as  such: it  is part  of the  FreeBSD ports  collection,
	    which   contains   over   3100   third-party   applications  in  a
	    ready-to-install format.
	    If you have not chosen to install the delegate port/package,  then
	    your system is not vulnerable.  If you have, then local or  remote
	    users  who  can  connect  to  the  delegate  port(s), or malicious
	    servers  which  a  user  accesses  using  the  delegate proxy, can
	    potentially execute arbitrary  code on your  system in any  number
	    of ways.
SOLUTION
	    Remove  the  delegate  port/package,  if  you  have  installed it.
	    Unfortunately no simple fix is  available - the problems with  the
	    delegate software are too endemic  to be fixed by a  simple patch.
	    It is hoped the software  authors will take security to  heart and
	    correct the security problems  in a future version,  although user
	    caution is advised given the current state of the code.
	    Depending  on  your  local  setup  and your security threat model,
	    using  a  firewall/packet  filter  such  as  ipfw(8)  or ipf(8) to
	    prevent remote users from  connecting to the delegate  port(s) may
	    be enough to meet  your security needs.   Note that this will  not
	    prevent legitimate proxy users from attacking the delegate server,
	    although this may not be an issue if they have a shell account  on
	    the  machine  anyway.   Note  also  that  this  does  not  prevent
	    "passive"  exploits  in  which  a  user is convinced through other
	    means into visiting a malicious server using the proxy, which  may
	    be able to  compromise it by  sending back invalid  data.  Several
	    flaws of this type have  been discovered during a brief  survey of
	    the code.
	    If you are  running FreeBSD 4.0,  a possible solution  might be to
	    confine  the  delegate  process  inside  a "jail" (see the jail(8)
	    manpage).  A  properly configured jail  will isolate the  contents
	    in their  own separate  "virtual machine",  which can  be suitably
	    secured  so  that  an  attacker  who  gains  control  of a process
	    running inside the jail cannot escape and gain access to the  rest
	    of the machine.   Note that this  is different from  a traditional
	    chroot(8), since  it does  not just  attempt to  isolate processes
	    inside portions of the filesystem.  This solution is not  possible
	    under standard FreeBSD 3.x or earlier.