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.