Date: Mon, 24 Mar 2003 12:44:28 -0600 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: D J Hawkey Jr <hawkeyd@visi.com> Cc: twig les <twigles@yahoo.com>, freebsd-security@FreeBSD.ORG Subject: Re: another TCPDump update question (going slightly off-topic) Message-ID: <20030324184428.GH1911@madman.celabo.org> In-Reply-To: <20030324110222.A8625@sheol.localdomain> References: <20030311231326.82217.qmail@web10107.mail.yahoo.com> <20030324151410.GE94153@madman.celabo.org> <20030324093021.A8296@sheol.localdomain> <20030324160020.GA1911@madman.celabo.org> <20030324110222.A8625@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 24, 2003 at 11:02:22AM -0600, D J Hawkey Jr wrote:
> On Mar 24, at 10:00 AM, Jacques A. Vidrine wrote:
> > Well, there are no hard-n-fast rules. It's a judgement call. We
> > generally limit SAs to those issues that we deem `important', so as
> > not to devalue them. (c.f. The Boy Who Cried Wolf)
>
> I can appreciate this, yes. Might it not be worth a SN, though?
Perhaps so. We (so-team) need to get back in the habit of issuing
SNs.
> > You're right: there have been SAs for remote DoSs before. In this
> > case, both the cirumstances that could lead to this remote DoS, and
> > especially the impact of the bug are so minimal as to not be worth
> > updating your system.
>
> I'll defer to your judgement on this; I don't know how easy this hole
> is to exploit. But if you'll indulge me, I'm thinking of a larger picture
> that this might illustrate:
OK, I'll indulge you :-) I don't want to say, ``just trust us'' --- we
make mistakes. However, we did already do this same sort of analysis.
> www.tcpdump.org shows a new libpcap "to go with" the updated tcpdump.
> They don't say a vulnerability was in libpcap, but if so, a quick scan
> of userland shows that pppd is linked to libpcap. By inference, I would
> think kernel-mode PPP falls in line with this, too. Now, there's a
> rather big "if" here, but if true, would this then qualify as worthy
> of a SA? As an aside, isn't BPF also tied to libpcap?
The `if' is indeed big. The assumptions in the above paragraph
don't hold:
(1) The vulnerability was in a tcpdump printer, not libpcap.
(2) While pppd does indeed use libpcap to implement packet filtering,
kernel-mode PPP most certainly does not.
(3) libpcap's live-capture mode is implemented on top of bpf, not the
other way 'round.
> I guess what my bigger concern is, is how much should a diligent SysAdmin
> have to scan external entities to be up on vulnerabilities of utilities
> that are part of the base/standard OS? My gut feeling is, "None, The
> Project should inform the user base.", but that may be too high a bar
> for what is esentially a for-free product.
Well, that is a goal, actually. I will freely admit that we are
falling short of that goal in the ports area right now, but I do not
expect that to be a permanent situation.
But as for this issue ... I honestly do not think it is important to
any FreeBSD user. The only possible exception might be someone
deploying tcpdump or tcpdump code fragments as part of an intrusion
detection system (seems unlikely).
Remember guys, we're talking about a command-line utility going into
an infinite loop. No crashes. No code execution. No nothing, it
just sits there printing to stdout.
> If my feeling is wrong, then
> I have to wonder if these utilities that are not "truly BSD" shouldn't
> be in the ports collection, and removed from the base?
Your feeling may be wrong in only one way: you seem to be assuming
that the tcpdump issue did not get treatment. We got early
notification, we looked at the bug, we looked at the fix, we analyzed
the impact, and we decided that it was not an issue. It got fixed in
-CURRENT, it got fixed in -STABLE (and for 4.8-RELEASE), but we do not
believe that a security advisory was needed nor that it was a fix that
should be incorporated into the security branches.
i.e. the issue got handled with as much thoroughness as any issue that
affects the base system does. You probably don't realize that there
are many judgement calls such as this one that must be made every
month. We invest a lot of time in each.
> Having said all this, I do in fact applaud you and your team for what
> you do provide, considering it's all done gratis.
Thanks! We do appreciate feedback about what should and should not be
considered for security advisories and the security branches. We rely
on that feedback to make future decisions. In this case, I still
think the right decision was made.
Cheers,
--
Jacques A. Vidrine <nectar@celabo.org> http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030324184428.GH1911>