FYI - security advisories on "delegate" proxy

  I'm passing this on, even though it's mostly off-topic for this list,
because I know this list frequently recommends people to "delegate" for
FTP proxies, for instance, and some people on the list may be using it.

  It sounds, to put it mildly, like this is not a good idea on any
Internet-connected server on most extant OSes.
  -- Clifton

----- Forwarded message from FreeBSD Security Officer <security-officer@freebsd.org>, FreeBSD Security Officer <security-officer@freebsd.org> -----

> Delivered-To: freebsd-announce@freebsd.org
> Date: Sat, 19 Feb 2000 22:45:45 -0800 (PST)
> X-Authentication-Warning: freefall.freebsd.org: kris set sender to security-officer@freebsd.org using -f
> From: FreeBSD Security Officer <security-officer@freebsd.org>
> Subject: FreeBSD Security Advisory: FreeBSD-SA-00:04.delegate
> Reply-To: security-officer@freebsd.org
> From: FreeBSD Security Officer <security-officer@freebsd.org>
> X-Loop: FreeBSD.org
> Precedence: bulk
> To: undisclosed-recipients: ;
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> =============================================================================
> FreeBSD-SA-00:04 Security Advisory
> FreeBSD, Inc.
>
> Topic: Delegate port contains numerous buffer overflows
>
> Category: ports
> Module: delegate
> Announced: 2000-02-19
> Affects: Ports collection before the correction date.
> Corrected: 2000-02-02
> FreeBSD only: NO
>
> I. Background
>
> 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.
>
> 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 ready-to-install format.
>
> 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.
>
> III. Impact
>
> 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.
>
> IV. Workaround
>
> Remove the delegate port/package, if you have installed it.
>
> V. Solution
>
> 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.
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
>
> iQCVAwUBOK+NTVUuHi5z0oilAQGGnAP+NOxAOVpEUpyR0iQwNjA1Je7B4M5gOxzc
> NwqQKp7WBm/IzzIW23KvyPcbTld83+m2tnhdNW3srh8ESSYDaa/hhmG2AtR0LYEL
> H2EWTIBcPBhidquX+ihKGTSaMnMjYpmp6GVGSsBqcNFXAPGHiJ6BbsEg2k6rJSLz
> wgL0NJ+qkCI=
> =ZhXO
> -----END PGP SIGNATURE-----
>
>
> This is the moderated mailing list freebsd-announce.
> The list contains announcements of new FreeBSD capabilities,
> important events and project milestones.
> See also the FreeBSD Web pages at http://www.freebsd.org
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-announce" in the body of the message

----- End forwarded message -----

-- 
 Clifton Royston  --  LavaNet Systems Architect --  cliftonr@lava.net
      The named which can be named is not the Eternal named.