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.