Does this mean I have to shut down my Public Proxy?
Are these issues being addressed in 6.1?
Date: Sat, 19 Feb 2000 22:50:34 -0800
From: Kris Kennaway kris@FREEBSD..
Subject: FreeBSD Security Advisory: FreeBSD-SA-00:04.delegate
FreeBSD-SA-00:04 Security Advisory FreeBSD, Inc.
Topic: Delegate port contains numerous buffer overflows
Affects: Ports collection before the correction date.
FreeBSD only: NO
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
II. Problem Description
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
FreeBSD makes no claim about the security of these third-party
applications, although an effort is underway to provide a security
audit of the most security-critical ports.
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.
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.