Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Mar 2004 21:16:06 -0600
From:      "Jacques A. Vidrine" <nectar@FreeBSD.org>
To:        Oliver Eikemeier <eikemeier@fillmore-labs.com>
Cc:        FreeBSD Security <security@FreeBSD.org>
Subject:   Re: cvs commit: ports/multimedia/xine Makefile
Message-ID:  <20040330031606.GA5998@madman.celabo.org>
In-Reply-To: <4068CECD.8070300@fillmore-labs.com>
References:  <200403282344.i2SNi6Hq047722@repoman.freebsd.org> <20040329163309.GA81526@madman.celabo.org> <40686785.7020002@fillmore-labs.com> <20040329185347.GB87233@madman.celabo.org> <40687E18.9060907@fillmore-labs.com> <20040329201926.GA88529@madman.celabo.org> <4068CECD.8070300@fillmore-labs.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 30, 2004 at 03:35:09AM +0200, Oliver Eikemeier wrote:
> While we are at it: port www/squid24 is listed in
> 705e003a-7f36-11d8-9645-0020ed76ef5a.
> 
> Is this serious? Isn't it? Who should decide?

It's a good example for this topic.  Let's have a look.

  squid ACL bypass due to URL decoding bug

  Affected packages
    squid < squid-2.5.5

  Details

  VuXML ID  705e003a-7f36-11d8-9645-0020ed76ef5a
  Discovery 2004-02-29
  Entry     2004-03-26

  From the Squid advisory:

      Squid versions 2.5.STABLE4 and earlier contain a bug in the
      "%xx" URL decoding function. It may insert a NUL character into
      decoded URLs, which may allow users to bypass url_regex ACLs.

  References

  CVE Name CVE-2004-0189
  URL      http://www.squid-cache.org/Advisories/SQUID-2004_1.txt


Now I did not mark the squid port FORBIDDEN when I added this, because
I do not believe that there is impending danger to any squid user.
I arrived at this conclusion after considering:

  (a) Only users who use Squid's ACLs to block certain URLs could
      possibly be affected.

  (b) For those users who are affected, the impact is quite mild.
      Perhaps IT is trying to stop users from view pr0n, or from
      visiting job sites, or some such.

      By stretching the imagination, perhaps there might be some type
      of service provider out there somewhere using this feature to
      control level of service.  For example, a wireless provider that
      lets anyone use their infrastructure to view ``local'' content
      but needs a service contract to reach the Internet.  This scenario
      (using Squid for this purpose) doesn't seem likely at all.

So, I do not think this port needs to be marked FORBIDDEN for all
FreeBSD users.

However, I *do* think that it is important to document this issue,
and to let our community know about it.  Thus, it is entered into the
VuXML document.

Cheers,
-- 
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040330031606.GA5998>