We use a quite open system for maintaining our data, but some notes
to ensure a continuing high level of data quality:
- Do not add <not-affected> entries unless it''s very obvious
(like
Windows-specific issues) or clearly stated inside a bug log or
home page.
- Severity ratings have been repeatedly picked up by news sites
taking it as an official position of the Debian project and
indirectly the Security Team. This means that severity ratings
should only be added with great care. Not every issue needs
a severity rating, if in doubt leave out or mark it unknown.
- Do not trust vulnerability web sites or the CVE description!
- If you add NOT-FOR-US: you should have done significant checking
if that package is not in the archive. If the package can even
be found with "apt-cache search" you haven''t tried hard
enough.
Cheers,
Moritz
Alex de Oliveira Silva
2007-Jan-13 03:08 UTC
[Secure-testing-team] Some notes on data commits
Hallo Moritz. Wie geht`s? :) On Fri, 12 Jan 2007 22:59:14 +0100, Moritz Muehlenhoff wrote> We use a quite open system for maintaining our data, but some notes > to ensure a continuing high level of data quality: > > - Do not add <not-affected> entries unless it''s very obvious (like > Windows-specific issues) or clearly stated inside a bug log or > home page.ok.> - Severity ratings have been repeatedly picked up by news sites > taking it as an official position of the Debian project and > indirectly the Security Team. This means that severity ratings > should only be added with great care. Not every issue needs > a severity rating, if in doubt leave out or mark it unknown. > > - Do not trust vulnerability web sites or the CVE description!Did you mean that I shoudn''t trust in mitre CVE "CVSS Severity"? I changed many severity bugs using it. :( Do you wait for the avaliation of the mantainer to change the severity afterwards or do you only look in description of the bug? How can I analize the severitys correctly?> - If you add NOT-FOR-US: you should have done significant checking > if that package is not in the archive. If the package can even > be found with "apt-cache search" you haven''t tried hard enough.I made a mistake when I thought that there were no Debian Firefox extensions packages. (NOT-FOR-US: Sage extension). Sorry.> Cheers, > Moritz >.''''`. Alex de Oliveira Silva / Fortaleza-CE / Brazil : :'' : Home Page: www.enerv.host.sk `. `''` email: enerv@host.sk `- Uin: 104073787
Alex de Oliveira Silva
2007-Jan-13 03:13 UTC
[Secure-testing-team] Some notes on data commits
Hallo Moritz. Wie geht`s? :) On Fri, 12 Jan 2007 22:59:14 +0100, Moritz Muehlenhoff wrote> We use a quite open system for maintaining our data, but some notes > to ensure a continuing high level of data quality: > > - Do not add <not-affected> entries unless it''s very obvious (like > Windows-specific issues) or clearly stated inside a bug log or > home page.ok.> - Severity ratings have been repeatedly picked up by news sites > taking it as an official position of the Debian project and > indirectly the Security Team. This means that severity ratings > should only be added with great care. Not every issue needs > a severity rating, if in doubt leave out or mark it unknown. > > - Do not trust vulnerability web sites or the CVE description!Did you mean that I shoudn''t trust in mitre CVE "CVSS Severity"? I changed many severity bugs using it. :( Do you wait for the avaliation of the mantainer to change the severity afterwards or do you only look in description of the bug? How can I analize the severitys correctly?> - If you add NOT-FOR-US: you should have done significant checking > if that package is not in the archive. If the package can even > be found with "apt-cache search" you haven''t tried hard enough.I made a mistake when I thought that there were no Debian Firefox extensions packages. (NOT-FOR-US: Sage extension). Sorry.> Cheers, > Moritz >
On Saturday 13 January 2007 02:51, Alex de Oliveira Silva wrote:> > - Do not trust vulnerability web sites or the CVE description! > > Did you mean that I shoudn''t trust in mitre CVE "CVSS Severity"? > I changed many severity bugs using it. :( > Do you wait for the avaliation of the mantainer to change the > severity afterwards or do you only look in description of the bug? > How can I analize the severitys correctly? ?Maybe we should discuss this again. Maulkin added "These are generally based on the ''score'' from NVD" to the documentation, but this is IMHO not what we did. Our severety includes how important a package is and what we label ''medium'' will often be ''high'' on NVD. OTOH, a XSS in a webapp is nearly always ''low'' in our old scheme, while NVD assigns ''high'' to e.g. CVE-2007-0204. I think we should stick with the old way and remove that sentence from the documentation again. What do you think? Cheers, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070113/ed7ce72b/attachment.pgp
On Friday 12 January 2007 22:59, Moritz Muehlenhoff wrote:> We use a quite open system for maintaining our data, but some notes > to ensure a continuing high level of data quality:some more hints:> - Do not trust vulnerability web sites or the CVE description!If there is a list of affected version on a site, and the version you are interested in is not there, then this means ''no information available'' and not ''not affected''. Some PHP modules (e.g. tinymce, adodb) are embedded by many PHP apps. If a filename in a webapp is given, it is a good idea to search for it with apt-file. I find the check-new-issues script [1] useful, too (but YMMV). Look at secure-testing/data/embedded-code-copies. Use svn diff before commiting. Cheers, Stefan [1] http://lists.alioth.debian.org/pipermail/secure-testing-commits/2006-November/005139.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.alioth.debian.org/pipermail/secure-testing-team/attachments/20070113/0184cec2/attachment-0001.pgp
* Stefan Fritsch:> I think we should stick with the old way and remove that sentence from > the documentation again. What do you think?Might make sense. I believe we referred to the old NVD scoring, which wasn''t based on CVSS.
* Alex de Oliveira Silva:> Did you mean that I shoudn''t trust in mitre CVE "CVSS Severity"?No, I don''t think so. For instance, CVE-2006-6235 gets a full 10.0 by NVD, and according to our standards, it''s "medium".> Do you wait for the avaliation of the mantainer to change the severity > afterwards or do you only look in description of the bug? > How can I analize the severitys correctly?The general rules are, as far as I''m concerned: - "high" for anything that permits an attacker to execute arbitrary code on the vulnerable system (with or without root privileges[1]). High-impact denial-of-service bugs should be put into that category, too (for instance, an IPv4 forwarding path vulnerability which requires only very few packets to exploit). Significant defects in security software can be rated "high" as well (for instance, a vulnerability in a piece of cryptographic software which flags forged digital signatures as genuine). - "medium" for anything which permits code execution after user interaction. Local privilege escalation vulnerabilities are in this category as well, or remote privilege escalation if it''s constrained to the application (i.e. no shell access to the underlying system, such as simple cross-site scripting). Most remote DoS vulnerabilities fall into this category, too. - "low" is intended for local DoS, /tmp file races and so on. - "unimportant" are PHP Safe mode bugs, path disclosure (doesn''t matter on Debian), and issues for which we only ship vulnerable source code which isn''t compiled into the package. Certain packages may get higher or lower rating than usual, based on their importance. [1] Given the ubiquity of privilege escalation vulnerabilities, it doesn''t make much sense to differentiate between root and non-root.
* Moritz Muehlenhoff:> - Severity ratings have been repeatedly picked up by news sites > taking it as an official position of the Debian project and > indirectly the Security Team. This means that severity ratings > should only be added with great care. Not every issue needs > a severity rating, if in doubt leave out or mark it unknown.I doubt the severity ratings in the tracker are used by news organisations (perhaps with the exception of LWN), given that it''s virtually unknown. But we should assign the severities such that "high" means "we must work on this ASAP", and "medium" something like "we should really try fix this". It doesn''t make sense if most open security bugs are flagged as "high" because it defeats the purpose of multiple severity levels.
On Sat, Jan 13, 2007 at 06:41:11PM +0100, Florian Weimer wrote:> * Moritz Muehlenhoff: > > > - Severity ratings have been repeatedly picked up by news sites > > taking it as an official position of the Debian project and > > indirectly the Security Team. This means that severity ratings > > should only be added with great care. Not every issue needs > > a severity rating, if in doubt leave out or mark it unknown. > > I doubt the severity ratings in the tracker are used by news > organisations (perhaps with the exception of LWN), given that it''s > virtually unknown.I''ve seen this at Heise (most important German language IT news site) when reporting about security issues ("This issue has been classified as "high" by Debian") Cheers, Moritz
Alex de Oliveira Silva wrote:> Hallo Moritz. Wie geht`s? :)Welcome to the secret cabal of German speaking Debian people. :-)> > - Severity ratings have been repeatedly picked up by news sites > > taking it as an official position of the Debian project and > > indirectly the Security Team. This means that severity ratings > > should only be added with great care. Not every issue needs > > a severity rating, if in doubt leave out or mark it unknown. > > > > - Do not trust vulnerability web sites or the CVE description! > > Did you mean that I shoudn''t trust in mitre CVE "CVSS Severity"? > I changed many severity bugs using it. :( > Do you wait for the avaliation of the mantainer to change the severity > afterwards or do you only look in description of the bug? > How can I analize the severitys correctly?We''ve never actively used CVSS or NVD. The current classifications have been defined at the Linux Developer''s Meeting in Oldenburg in 2005. It''s roughly: low: security issues w/o real-world ramifications medium: genuine security problems high: severe genuine security problems (remote code injection against important software, issues with an exploit in the wild, popular web crap with worm potential, Linux root exploits, etc) It''s probably best to follow commits for a while to get a feeling for it. All in all, severity classifications are rather useless, anyway.> > - If you add NOT-FOR-US: you should have done significant checking > > if that package is not in the archive. If the package can even > > be found with "apt-cache search" you haven''t tried hard enough. > > I made a mistake when I thought that there were no Debian Firefox extensions > packages. (NOT-FOR-US: Sage extension). Sorry.No worries. If in doubt just add a TODO: and note the information you''ve found about it, see some commits be Stefan as an example. Cheers, Moritz
Stefan Fritsch wrote:> I think we should stick with the old way and remove that sentence from > the documentation again. What do you think?Ack. Cheers, Moritz
Florian Weimer wrote:> - "unimportant" are PHP Safe mode bugs, path disclosure (doesn''t > matter on Debian), and issues for which we only ship vulnerable > source code which isn''t compiled into the package.Plus all the junk reports about security issues, which are non-issues in practice, like issues only "exploitable" if the code in question is setuid root, exploits which only work if someone already has administrative privileges or similar.> [1] Given the ubiquity of privilege escalation vulnerabilities, it > doesn''t make much sense to differentiate between root and > non-root.While that used to be true in the past, Linux has become better and local privilege escalation in production code isn''t a monthly event these days. (Unless you stuff several megabytes of black-box code into your kernel, which led to two shiny remote root exploits in the Ubuntu kernels. (Nvidia and Madwifi)) Cheers, Moritz
Alex de Oliveira Silva
2007-Jan-14 16:58 UTC
[Secure-testing-team] Some notes on data commits
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moritz Muehlenhoff escreveu:> Alex de Oliveira Silva wrote: >> Hallo Moritz. Wie geht`s? :) > > Welcome to the secret cabal of German speaking Debian people. :-)IT''S SECRET!!! Don''t tell anyone.> >>> - Severity ratings have been repeatedly picked up by news sites >>> taking it as an official position of the Debian project and >>> indirectly the Security Team. This means that severity ratings >>> should only be added with great care. Not every issue needs a >>> severity rating, if in doubt leave out or mark it unknown. >>> >>> - Do not trust vulnerability web sites or the CVE description! >> Did you mean that I shoudn''t trust in mitre CVE "CVSS Severity"? >> I changed many severity bugs using it. :( Do you wait for the >> avaliation of the mantainer to change the severity afterwards or >> do you only look in description of the bug? How can I analize the >> severitys correctly? > > We''ve never actively used CVSS or NVD. The current classifications > have been defined at the Linux Developer''s Meeting in Oldenburg in > 2005. It''s roughly: > > low: security issues w/o real-world ramifications medium: genuine > security problems high: severe genuine security problems (remote > code injection against important software, issues with an exploit > in the wild, popular web crap with worm potential, Linux root > exploits, etc) > > It''s probably best to follow commits for a while to get a feeling > for it. All in all, severity classifications are rather useless, > anyway. >I make this. Maybe is a good idea put this in definition of narrative_introduction and remove this "These are generally based on the ''score'' from NVD" ?>>> - If you add NOT-FOR-US: you should have done significant >>> checking if that package is not in the archive. If the package >>> can even be found with "apt-cache search" you haven''t tried >>> hard enough. >> I made a mistake when I thought that there were no Debian Firefox >> extensions packages. (NOT-FOR-US: Sage extension). Sorry. > > No worries. If in doubt just add a TODO: and note the information > you''ve found about it, see some commits be Stefan as an example.Ok, I added some notes in commit 5260 to help and I''ll wait to see how you are going to solve it .> > Cheers, Moritz >regards, - -- .''''`. : :'' : Alex de Oliveira Silva | enerv `. `'' www.enerv.net `- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFqlLoarbczl+z12gRAuWpAKCuYxJU6JzrxeuX7R07rfLVCkA7dgCdE2g+ vRO1RZvQ/tI74Me/y1N0VJo=/bz5 -----END PGP SIGNATURE-----