[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121221195054.GB7583@netbsd.org>
Date: Fri, 21 Dec 2012 19:50:54 +0000
From: David Holland <dholland-oss-security@...bsd.org>
To: Kurt Seifried <kseifried@...hat.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Isearch insecure temporary files
On Fri, Dec 21, 2012 at 10:26:57AM -0700, Kurt Seifried wrote:
> > NetBSD pkgsrc ships an old text search package called Isearch,
> > which I found tonight (in the course of making it compile with a
> > modernish C++ compiler) to contain garden-variety /tmp races.
> >
> > Does anyone else ship it? I don't think this is worth a CVE unless
> > someone does; the package appears to be dead upstream.
>
> This is similar to http://seclists.org/oss-sec/2012/q4/142
>
> Ideally we need some way to mark software as dead/unsafe/don't use. I
> don't know what the answer is though (does someone maintain a
> blacklist? who decides? etc.).
Yeah.
Looking at that thread (which I didn't see at the time because I no
longer have time to follow this list much) I think I'd agree that the
CVE system itself is the wrong scheme, not only for its own reasons
but also because it doesn't reach the right targets.
Most people prefer to get software from some kind of package
collection, both because it's easier and because such collections are
to some extent curated. CVEs work well in this environment; they go
out to the collection maintainers, packages in the collections get
tagged, end users can crosscheck their installed package lists against
CVE databases, etc.
However, the kind of software we're talking about (dead upstream,
inherently suspect, not really worth auditing or fixing) tends to get
kicked out of these collections and forgotten. So when/if end users
are exposed, it's likely to be because they downloaded something from
some random place and installed it in /usr/local/bin, or worse,
untarred it in ~httpd, and then possibly forgot entirely about it.
There isn't much of a pipeline for getting CVE information to them,
and they aren't in general likely to think to crosscheck the CVE
database. (Nor, with some of these old things, is it always entirely
clear if the item they're looking at is the same as the one the CVE
database is talking about.)
All of these problems also apply to any new scheme someone sets up;
what I'm suggesting is that the existing CVE infrastructure is not
necessarily that much of an advantage.
That said, I don't know what the answer is. We have quite a number of
packages in pkgsrc that are dead (or comatose) upstream and that we're
effectively maintaining ourselves because they require only minor
attention or someone considers them worthwhile. I've often thought it
would be helpful to have some kind of wider community for dealing with
these, not just for security but also for general patches and bug
fixes. This could also serve as a clearinghouse for deciding which
things should be declared dead. But you can't create such a community
by waving a wand.
> > http://gnats.netbsd.org/47360 for reference; the relevant portions
> > of the patches cited follow.
>
> Yeah that's pretty classic /tmp vulns. Please use CVE-2012-5663 for
> this issue.
Will do, thanks.
--
David A. Holland
dholland@...bsd.org
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
