Re: tracking security issues without CVEs
On Mon, Mar 28, 2016 at 10:34 PM, Andrew Deck wrote: > On a related note, does anyone know what happened to OSF and the OSVDB? > There still seem to be blog updates, but I remember OSVDB having a web > UI, and the OSF website seems to be down. They have officially closed the OSVDB site: https://blog.osvdb.org/2016/04/05/osvdb-fin/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On a related note, does anyone know what happened to OSF and the OSVDB? There still seem to be blog updates, but I remember OSVDB having a web UI, and the OSF website seems to be down. https://en.wikipedia.org/wiki/Open_Source_Vulnerability_Database#Contributors -- "Institutions will try to preserve the problem to which they are the solution." - Kevin Kelly
Re: tracking security issues without CVEs
On Wed, Mar 23, 2016 at 10:59:34AM +0800, Paul Wise wrote: I think Debian needs to go towards the approach of VRDX-SIG and do identifier cross-referencing instead of settling on *one* system for referring to security vulnerabilities. Internally, we would continue to use CVEs and CVE-2016- for issues without CVEs and then map all the external identifiers onto those. I think debian should pick a common one to use by default, and use a different one only if necessary. I think trying to turn into yet another clearinghouse of cross-referenced vulnerability IDs is a bottomless pit of wasted effort. Mike Stone
Re: tracking security issues without CVEs
On Tue, Mar 22, 2016 at 10:06 PM, Antoine Beaupré wrote:
> Well, the friction is one thing, but we need to adopt *one* system for
> the future, if CVEs are going the wayside (or even as a complementary
> approach).
I agree with this post from oss-security:
https://marc.info/?l=oss-security&m=145764213513572&w=2
Fracturing of the security identifier space is inevitable and already
happening to some extent even before the CVE policy changes and before
OVE/OVI/DWF/etc started; many projects have their own identifiers and
some of those don't use CVEs (notably node-security and drupal
AFAICS). Here are some examples of project-specific identifiers:
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup
I think Debian needs to go towards the approach of VRDX-SIG and do
identifier cross-referencing instead of settling on *one* system for
referring to security vulnerabilities. Internally, we would continue
to use CVEs and CVE-2016- for issues without CVEs and then map all
the external identifiers onto those.
> DWF seems interesting because it incorporates CVE IDs
> directly and it also allocates CVE ranges to various projects.
> Debian could be one of those:
>
> https://github.com/distributedweaknessfiling/DNA-Registry/blob/master/DNA-Registry.csv
>
> ... and manage its own allocations.
ETOOMUCHGITHUB :)
> I am not sure I like the CSVs, however... and it doesn't seem to have
> much adoption yet:
>
> https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2016.csv
More available here:
https://github.com/distributedweaknessfiling/DWF-Database/blob/master/DWF-Database-2015.csv
Wow, both of those really aren't useful at all; no external references
or actionable useful information.
Either way we need to support it since it is already being used. I
have a local branch of the security tracker that has a data/DWF/list
file containing the following. Ultimately though, I think that is the
wrong approach. Instead, data/CVE/list should continue to contain all
the data and we just add {DWF-2016-8 DRUPAL-SA-37134} to the
beginning of the entry like we do for DSA/DLA. Then the tracker needs
to grow support for extra security issue identifiers and we need a
script reading sources.ini and automatically pulling down each kind of
identifier and adding it to data/CVE/list, as we do for CVEs
themselves.
https://wiki.debian.org/SummerOfCode2015/ProjectProposals/SecurityTrackerCheckExternal
https://anonscm.debian.org/viewvc/secure-testing/check-external/sources.ini?view=markup
DWF-2016-89000 Fedora captcha system weakness
NOT-FOR-US
NOTE: https://patrick.uiterwijk.org/2016/03/09/fedora-spam-dwf-2016-89000/
DWF-2016-89001 [Shotwell does not validate TLS certificates]
- shotwell 0.22.0-3 (bug #807110)
NOTE: https://bugzilla.gnome.org/show_bug.cgi?id=754488
> Centralisation certainly doesn't scale here...
I think using debbugs or similar for CVE numbers could easily scale,
if a few features were added to it, but I doubt that will happen.
https://marc.info/?l=oss-security&m=145766818820035&w=2
--
bye,
pabs
https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On Fri, Mar 11, 2016 at 3:49 AM, Moritz Mühlenhoff wrote: > On Sun, Mar 06, 2016 at 06:58:48PM +0100, Salvatore Bonaccorso wrote: > >> But I think as well that is right now to early to >> start adopting these for not yet assigned issues. > > Agreed, let's stick with the usual "file a bug to get a temporary > identifier" procedure for now. I wonder if the TEMP URLs should redirect to the bug report URL when there is a bug available? BTW, there was an LWN article about the alternatives to CVEs: http://lwn.net/SubscriberLink/679315/a38e2baa9ceaf953/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: tracking security issues without CVEs
On Sun, Mar 06, 2016 at 06:58:48PM +0100, Salvatore Bonaccorso wrote: > But I think as well that is right now to early to > start adopting these for not yet assigned issues. Agreed, let's stick with the usual "file a bug to get a temporary identifier" procedure for now. Cheers, Moritz
Re: tracking security issues without CVEs
Salvatore Bonaccorso writes: > For the record, the thread is starting at > > http://www.openwall.com/lists/oss-security/2016/03/04/4 > > where Kurt Seifried from Red Hat raised the concern. Yes, am following that. Not entirely confident anything will happen, however would be good if it does get resolved. -- Brian May
Re: tracking security issues without CVEs
Salvatore Bonaccorso writes: > Creating individual bugs in the Debian BTS, including more details > like fixing commits would be a great start, since we use either CVEs > or references to the Debian BTS in DSAs (and DLAs). Furthermore the > security-tracker handles both (you can actually search items there via > either CVE id, bug number or package name). The problem with this (if I understand security tracker as well as I think I do), if we want to track them using security-tracker, you need an entry in data/CVE/list. If there is no CVE that means you have to use CVE-2016-. Which in turn means that data/DSA/list and data/DLA/list can't directly refer to the data/CVE/list entry being fixed. I also seem to recall (???) that CVE-2016- is intended for when a CVE is expected very soon. So if you want to get a good idea of where we have fixed #692367, and what DSA/DLA were involved, I don't think there is a good way of adding this information to security-tracker. > The original CVE request at > http://www.openwall.com/lists/oss-security/2014/12/24/1 was IMHO not > fully optimal, since it just pasted a collection of items. Adding > references to fixing commits would have helped to get CVEs assigned to > issues. The original request at least makes it really hard to > identify the issues and make sure the CVEs are assigned correctly. Yes, I thought this was lousy too. There is a reference to a list of patches, however no easy way of being able to link each issue to each patch. So if a CVE was provided for each issue, it would be relatively hard to link it to the appropriate patch with 100% certainty. With so many different issues, I suspect it is going to be overwhelming requesting a CVE for each issue no matter what you do. -- Brian May
Re: tracking security issues without CVEs
Hi Brian, hi Paul, On Sun, Mar 06, 2016 at 04:59:43PM +0100, Salvatore Bonaccorso wrote: > Hi, > > On Sun, Mar 06, 2016 at 03:33:16PM +1100, Brian May wrote: > > Just wondering if there is some other way we can track security issues > > for when CVEs are not available. > > > > Thinking of imagemagick here, it has a lot of security issues, and > > requests for CVEs are not getting any responses. > > Creating individual bugs in the Debian BTS, including more details > like fixing commits would be a great start, since we use either CVEs > or references to the Debian BTS in DSAs (and DLAs). Furthermore the > security-tracker handles both (you can actually search items there via > either CVE id, bug number or package name). > > The original CVE request at > http://www.openwall.com/lists/oss-security/2014/12/24/1 was IMHO not > fully optimal, since it just pasted a collection of items. Adding > references to fixing commits would have helped to get CVEs assigned to > issues. The original request at least makes it really hard to > identify the issues and make sure the CVEs are assigned correctly. Just one comment which I forgot to address in the previous mail, regarding the OVE identifiers. The question about the CVE assignments were just re-raised yesterday on oss-security. The whole might look promissing indeed. But I think as well that is right now to early to start adopting these for not yet assigned issues. Instead follow the current discussion on oss-security and let's see if across distributions there is going to be some consensus/approach for this issue. For the record, the thread is starting at http://www.openwall.com/lists/oss-security/2016/03/04/4 where Kurt Seifried from Red Hat raised the concern. Regards, Salvatore
Re: tracking security issues without CVEs
Hi, On Sun, Mar 06, 2016 at 03:33:16PM +1100, Brian May wrote: > Just wondering if there is some other way we can track security issues > for when CVEs are not available. > > Thinking of imagemagick here, it has a lot of security issues, and > requests for CVEs are not getting any responses. Creating individual bugs in the Debian BTS, including more details like fixing commits would be a great start, since we use either CVEs or references to the Debian BTS in DSAs (and DLAs). Furthermore the security-tracker handles both (you can actually search items there via either CVE id, bug number or package name). The original CVE request at http://www.openwall.com/lists/oss-security/2014/12/24/1 was IMHO not fully optimal, since it just pasted a collection of items. Adding references to fixing commits would have helped to get CVEs assigned to issues. The original request at least makes it really hard to identify the issues and make sure the CVEs are assigned correctly. Regards, Salvatore
Re: tracking security issues without CVEs
On Sun, Mar 6, 2016 at 12:33 PM, Brian May wrote: > Just wondering if there is some other way we can track security issues > for when CVEs are not available. ... > For example, if there are no CVEs are we able to use OVEs instead? > > http://www.openwall.com/ove This sounds like a good idea to me. Do you know of any issues where OVEs were used? Is there any project who uses them regularly? I wonder if we should be discussing this more widely, for example on oss-sec? > Thinking of imagemagick here, it has a lot of security issues, and > requests for CVEs are not getting any responses. It sounds like Mitre has quite a backlog: https://marc.info/?i=1456968329.26654.16.ca...@bonedaddy.net https://marc.info/?i=CANO=ty1yvjf505lzrj7utg5ypbys1gabo4bd0e5h95pup62...@mail.gmail.com https://cve.mitre.org/data/board/archives/2015-11/msg00018.html -- bye, pabs https://wiki.debian.org/PaulWise
tracking security issues without CVEs
Hello, Just wondering if there is some other way we can track security issues for when CVEs are not available. Thinking of imagemagick here, it has a lot of security issues, and requests for CVEs are not getting any responses. For example, if there are no CVEs are we able to use OVEs instead? http://www.openwall.com/ove As an example of the problems this causes, it is going to be challanging working out for sure which changes made in the squeeze version fixed TEMP-0773834-5EB6CF (for porting to wheezy version), particular as TEMP-0773834-5EB6CF refers to multiple security issues. As there is nothing in the changelog refering to these temp ids, because of cause they are only temp ids. https://security-tracker.debian.org/tracker/TEMP-0773834-5EB6CF In this particular case, I suspect it might be just the last two patches, as other issues have CVEs or appear to be fixed in wheezy already. e.g. #692367 (which doesn't appear to have security tracking). fix-overflow-in-icon-parsing.patch fix-overflow-in-pict-parsing.patch Regards -- Brian May https://linuxpenguins.xyz/brian/
