Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Sun, Jul 18, 2004 at 11:47:38PM -0400, Bradley Alexander wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sunday 18 July 2004 23:11, Matt Zimmerman wrote: > > As you have repeatedly confirmed, the security team is very busy. > > Matt, > > Is there anything I can do to help? I am a security engineer, but not a > programmer. Let me know what you need done. You can help by identifying security vulnerabilities that need to be fixed in stable, and helping to gather the necessary information to fix them. Here is some information: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 18 July 2004 23:11, Matt Zimmerman wrote: > As you have repeatedly confirmed, the security team is very busy. Matt, Is there anything I can do to help? I am a security engineer, but not a programmer. Let me know what you need done. > Generally, if an issue doesn't affect stable, I don't track it at all. > If an issue does affect stable, then when I release an advisory, I check > the package in unstable and file a bug if necessary. > > Some people help track bugs in unstable by watching for new vulnerabilities > in public databases, verifying whether the bug is present in unstable, and > filing a bug if so. It would be great if you would help with these > efforts. You do not need any authorization or information from the security > team in order to do so. > > -- > - mdz - -- - --Brad Bradley M. Alexander| SysAdmin, Security Engineer| storm [at] tux.org Debian/GNU Linux Developer | storm [at] debian.org Key fingerprints: DSA 0x54434E65: 37F6 BCA6 621D 920C E02E E3C8 73B2 C019 5443 4E65 RSA 0xC3BCBA91: 3F 0E 26 C1 90 14 AD 0A C8 9C F0 93 75 A0 01 34 In the ongoing battle between objects made of aluminum going hundreds of miles per hour and the ground going zero miles per hour, the ground has yet to lose. --Rules of the Air, #19 -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA+0Rac7LAGVRDTmURAtMxAKCIG+tQHEtNszbxik368R9mPrk6kQCgxSpX WCE4AcIHAegOmoIZIhDdjBE= =OsVo -END PGP SIGNATURE-
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: > Or is there some reason filing bugs like I described here isn't > wanted? As you have repeatedly confirmed, the security team is very busy. Generally, if an issue doesn't affect stable, I don't track it at all. If an issue does affect stable, then when I release an advisory, I check the package in unstable and file a bug if necessary. Some people help track bugs in unstable by watching for new vulnerabilities in public databases, verifying whether the bug is present in unstable, and filing a bug if so. It would be great if you would help with these efforts. You do not need any authorization or information from the security team in order to do so. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
Could you guys please stop sending cc:s my way? Debian list policy suggests not to do this, and I never requested cc:s. Thank you. -- vbi On Saturday 10 July 2004 17.37, Florian Weimer wrote: > * Jeroen van Wolffelaar: > >> Actually, it's rather time-consuming to determine if a security > >> vulnerability has been published. You have to discover the ... -- Today is Boomtime, the 46th day of Confusion in the YOLD 3170 pgpH2o6JYHWJw.pgp Description: signature
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
* Jeroen van Wolffelaar: >> Actually, it's rather time-consuming to determine if a security >> vulnerability has been published. You have to discover the >> publication, and then you have to decide whether it's actually the >> same issue and if it's been disclosed completely. > > The first thing that is being done when a security issue gets to the > security team, is assign a CAN-number after it's verified. Are you sure? In this case, process has changed considerably. CVE originally only dealt with public vulnerabilities. Nowadays, you can get blocks of CANs for later assignment, but assignment still appears to be somewhat ad-hoc and not very systematic. It looks that quite a number of CANs are assigned pretty late during the lifetime of a vulnerability. > CAN entries are either simply 'reserved' and hidden for the general > public, at some time, the content is set open for the public. There is no hidden content at the CVE site. MITRE simply doesn't have this information. They add it from public sources once it is available. > I guess/assume that opening up is mailed to the security team in > some way, or otherwise noticed. The CVE project at MITRE doesn't coordinate disclosure. I'd be surprised if status changes are sent to vendors, especially they haven't been associated with the database entry yet. > Then sending a mail to [EMAIL PROTECTED] with a cut&paste (yank & > put) of the CAN/CVE description shouldn't be that much effort. Are you sure that CVE is updated faster than Debian reacts, generally speaking? This new process is only worth it if (a) there is a significant delay on Debian's part and (b) CVE is considerably faster in providing data, in all but pathological cases. Otherwise, you'd effort (maybe just very little) resources into something that isn't really worth it. > The security team monitors every bugreport tagged security, I had it > happen that the security time responed earlier to a bug like that than I > had the chance... So, they do already. I wasn't sure if the monitoring is systematic. Is there some pre-filtered mailing list I could subscribe to? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Sat, Jul 10, 2004 at 12:29:11PM +0200, Florian Weimer wrote: > * Adrian von Bidder: > > > I think Jeroen is thinking about security problems the security team > > already knows about but has not yet had time to handle (and which have > > already been made public somewhere else.) Stupid if somebody has to > > search the sources *again* if the security team already has the > > information. > > Actually, it's rather time-consuming to determine if a security > vulnerability has been published. You have to discover the > publication, and then you have to decide whether it's actually the > same issue and if it's been disclosed completely. The first thing that is being done when a security issue gets to the security team, is assign a CAN-number after it's verified. CAN entries are either simply 'reserved' and hidden for the general public, at some time, the content is set open for the public. I guess/assume that opening up is mailed to the security team in some way, or otherwise noticed. Then sending a mail to [EMAIL PROTECTED] with a cut&paste (yank & put) of the CAN/CVE description shouldn't be that much effort. But, this all IMHO, and it is still a wishlist request. > Filing bug reports about public issues is something any DD or user can > do. I don't think this should be added to the duties of the security > team. I'd appreciate if they commented on new security bugs that are > tagged woody, though. The security team monitors every bugreport tagged security, I had it happen that the security time responed earlier to a bug like that than I had the chance... So, they do already. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
* Adrian von Bidder: > I think Jeroen is thinking about security problems the security team > already knows about but has not yet had time to handle (and which have > already been made public somewhere else.) Stupid if somebody has to > search the sources *again* if the security team already has the > information. Actually, it's rather time-consuming to determine if a security vulnerability has been published. You have to discover the publication, and then you have to decide whether it's actually the same issue and if it's been disclosed completely. Filing bug reports about public issues is something any DD or user can do. I don't think this should be added to the duties of the security team. I'd appreciate if they commented on new security bugs that are tagged woody, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Wednesday 07 July 2004 18.28, Matt Zimmerman wrote: > On Wed, Jul 07, 2004 at 01:17:01PM +0200, Jeroen van Wolffelaar wrote: > > On Wed, Jul 07, 2004 at 02:49:54AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > > > Why does the security team have to do this? Anybody can do it. > > Not without spending lots of time crawling through security lists, > > CAN/CVE's, bugtraq, verifying whether debian has the offending > > version, etc. > How do you think the security team does it? We do not have a magic > filter which shows us only issues which affect Debian stable; this is > all done by hand. I think Jeroen is thinking about security problems the security team already knows about but has not yet had time to handle (and which have already been made public somewhere else.) Stupid if somebody has to search the sources *again* if the security team already has the information. greetings -- vbi -- featured product: SpamAssassin - http://spamassassin.org pgpXqgOaGf4BX.pgp Description: signature
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Wed, Jul 07, 2004 at 01:17:01PM +0200, Jeroen van Wolffelaar wrote: > On Wed, Jul 07, 2004 at 02:49:54AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > > Why does the security team have to do this? Anybody can do it. > > Not without spending lots of time crawling through security lists, > CAN/CVE's, bugtraq, verifying whether debian has the offending version, etc. How do you think the security team does it? We do not have a magic filter which shows us only issues which affect Debian stable; this is all done by hand. It is helpful if users spend the time collecting information about a vulnerability and forward a complete report to the Security Team with everything they need. This section in the Developer's Reference: http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-bug-security describes what information should be provided about a vulnerability. Note that, as the FAQ says, it is not helpful to simply forward a message from BUGTRAQ or full-disclosure, because we already receive those. However, if you are able to track down additional information, such as confirming the vulnerability in stable and finding an appropriate patch, that _is_ helpful. Since we are talking about publicly-known vulnerabilities, those wishing to help out should feel free to CC their communications with the security team to this (debian-security) mailing list, so that others do not duplicate their work, and can see the status of the issue. > Well, since usually the maintainer is informed about such an issue, the > maintainer _can_ submit such a bugreport when the issue is public. Maybe > that is a better solution then, but yet, one depends on the maintainer in > that case. Debian has a lot of MIA maintainers; if the maintainer is active, in touch with upstream, and willing to help the security team, security problems with the package in stable don't stagnate. It is the stagnant issues that generally need help, because the maintainer, upstream or both are not responsive. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Wed, Jul 07, 2004 at 02:49:54AM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: > > Hi, > > > > As I promised in [1], a suggestion for the Debian security team. > > > > Since the security team is generally very busy sorting out any kind of > > vulnerability, sometimes fixes can take a little bit longer than usual, > > especially if the impact is relatively low. > > Funny, you are observing that the security team is overworked and you > suggest adding "Yet Another Thing To Do" (tm) to their list. Yes, that's a paradox, but since the security team simply has a list with 'open issues that are already public', and nobody else has it readily available, they are about the only ones able to do this well. Matt Zimmerman provided me yesterday with a list of such issues, it would be very hard for a non-security member to make that list. I'll forward it to this list soon now. > > Therefore, I'd like to ask the security team to file grave bugs with > > security+woody on packages for which a vulnerability has been made > > public, and a security announcement isn't nearly-ready. I can't imagine > > this would interfere too much with the issue tracker or whatever the > > security team internally uses to track issues. > > Why does the security team have to do this? Anybody can do it. Not without spending lots of time crawling through security lists, CAN/CVE's, bugtraq, verifying whether debian has the offending version, etc. Well, since usually the maintainer is informed about such an issue, the maintainer _can_ submit such a bugreport when the issue is public. Maybe that is a better solution then, but yet, one depends on the maintainer in that case. > I know that the security team will probably appreciate if all this work is > done for publicly known vulnerabilities. A bug submitter should make an > effort (if he wants to help out the security team and not hinder it) to > provide more info than just a Bugtraq post (which are in many cases > incomplete or are simply not correct/true/relevant). He should also made an > effort to review http://www.debian.org/security/nonvulns-woody and see if > the issue has already been determined _not_ to affect woody. Like this for example: http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=squirrelmail&include=woody --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl pgpCYNS3Aub0F.pgp Description: PGP signature
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 11:51:21PM +0200, Jeroen van Wolffelaar wrote: security issues. I'll post a list of a few of such issues here later tonight, that are exactly issues that could have been filed in the BTS. If you really have so much time I'm sure you can find better things to do than post lists of things that could have been filed in the BTS. Such as, for example, filing a patch in the BTS? Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: > Hi, > > As I promised in [1], a suggestion for the Debian security team. > > Since the security team is generally very busy sorting out any kind of > vulnerability, sometimes fixes can take a little bit longer than usual, > especially if the impact is relatively low. Funny, you are observing that the security team is overworked and you suggest adding "Yet Another Thing To Do" (tm) to their list. > Therefore, I'd like to ask the security team to file grave bugs with > security+woody on packages for which a vulnerability has been made > public, and a security announcement isn't nearly-ready. I can't imagine > this would interfere too much with the issue tracker or whatever the > security team internally uses to track issues. Why does the security team have to do this? Anybody can do it. BTS reports can serve as a reminder or as a way to inform both the maintainer and the security team for known vulnerabilities. It also helps users who might track bugs related to woody and, even now in a time close to release, it might help track bugs in sarge so that we don't ship a new release with software that includes security vulnerabilities. Actually, the security team will probably appreciate bug submitters to do the following: 1.- include a CVE name (in order to discriminate vulnerabilities to previous ones). After all we _are_ CVE compatible (almost all DSAs include CVE names) 2.- tag the bug based on the version that is vulnerable (woody, sarge, sid, or all/some of them). Sometimes you might need to actually check out the code to see if the version in stable is vulnerable. 3.- provide a patch for the stable release I know that the security team will probably appreciate if all this work is done for publicly known vulnerabilities. A bug submitter should make an effort (if he wants to help out the security team and not hinder it) to provide more info than just a Bugtraq post (which are in many cases incomplete or are simply not correct/true/relevant). He should also made an effort to review http://www.debian.org/security/nonvulns-woody and see if the issue has already been determined _not_ to affect woody. > Or is there some reason filing bugs like I described here isn't > wanted? None I know of. Actually, there are bugs open in the BTS tagged 'security' that might get a DSA when the security team finds the time to do it. There are priorities regarding which packages should get DSAs first and there are some packages, like the kernel, which are not that easy to publish DSAs for. The security team will probably appreciate people giving a hand in debugging these issues in detail (as opposed to just forwarding a Bugtraq mail) Regards Javier PS: I don't imply that I do this myself correctly every time, I've probably reported security bugs incorrectly a number of times, these are just some "good practice guidelines" I believe bug submitters should adhere to. signature.asc Description: Digital signature
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 10:39:09PM +0200, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > mdz told me this isn't done for practical reasons: the BTS isn't very > > suitable for tracking which versions are affected, and a sid upload can > > close such a bug while it's still in woody. While I think it'd still be > > possible without too much hassle, if they don't want to do so, I'm not > > going to interfere in that. > > Well, I guess anybody is free to open bugs against packages if they hear > about vulnerabilities. I guess this even might help in some cases. But I > dont think security team can "publish" received vendor alerts before going > public date. Effectively this is "hiding", but on the other hand it is also > respecting the wishes and requests of others. And not honoring them will > quickly lead to debian beeing cut-off from those alerts. So thats why > unpublished alerts are not posted. I'm only talking about published issues, of course, unpublished ones shouldn't go into the BTS. Having the security team file bugs for _published_ issues, will make part of the work of the security team, managing which vulernabilities exist and apply to woody, and aren't fixed yet, also available to non-security team members, who then can possibly more effectively help on security issues. I'll post a list of a few of such issues here later tonight, that are exactly issues that could have been filed in the BTS. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
In article <[EMAIL PROTECTED]> you wrote: > mdz told me this isn't done for practical reasons: the BTS isn't very > suitable for tracking which versions are affected, and a sid upload can > close such a bug while it's still in woody. While I think it'd still be > possible without too much hassle, if they don't want to do so, I'm not > going to interfere in that. Well, I guess anybody is free to open bugs against packages if they hear about vulnerabilities. I guess this even might help in some cases. But I dont think security team can "publish" received vendor alerts before going public date. Effectively this is "hiding", but on the other hand it is also respecting the wishes and requests of others. And not honoring them will quickly lead to debian beeing cut-off from those alerts. So thats why unpublished alerts are not posted. Greetings Bernd -- eckes privat - http://www.eckes.org/ Project Freefire - http://www.freefire.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 09:13:18PM +0200, Jeroen van Wolffelaar wrote: > On Tue, Jul 06, 2004 at 03:08:38PM -0400, Michael Stone wrote: > > On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: > > >As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all > > >three not yet solved in woody, but also not filed in the BTS (hm, two of > > >them directly refer to a patch[2][3] solving it...). > > > > Go ahead and file the bug. > > mdz told me this isn't done for practical reasons: the BTS isn't very > suitable for tracking which versions are affected, and a sid upload can > close such a bug while it's still in woody. While I think it'd still be > possible without too much hassle, if they don't want to do so, I'm not > going to interfere in that. > > For those two bugs, I'm simply mailing the security team myself, maybe > also file a bug, don't know yet. You are free to file a bug, and sometimes this helps to get a response from the maintainer; just note that these bugs will generally not be used by the security team for tracking the status of the vulnerabilities. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 03:08:38PM -0400, Michael Stone wrote: > On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: > >As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all > >three not yet solved in woody, but also not filed in the BTS (hm, two of > >them directly refer to a patch[2][3] solving it...). > > Go ahead and file the bug. mdz told me this isn't done for practical reasons: the BTS isn't very suitable for tracking which versions are affected, and a sid upload can close such a bug while it's still in woody. While I think it'd still be possible without too much hassle, if they don't want to do so, I'm not going to interfere in that. For those two bugs, I'm simply mailing the security team myself, maybe also file a bug, don't know yet. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/suggestion for security team w.r.t. published vulerabilities
On Tue, Jul 06, 2004 at 08:06:36PM +0200, Jeroen van Wolffelaar wrote: As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all three not yet solved in woody, but also not filed in the BTS (hm, two of them directly refer to a patch[2][3] solving it...). Go ahead and file the bug. Mike Stone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Proposal/suggestion for security team w.r.t. published vulerabilities
Hi, As I promised in [1], a suggestion for the Debian security team. Since the security team is generally very busy sorting out any kind of vulnerability, sometimes fixes can take a little bit longer than usual, especially if the impact is relatively low. Taking the Social Contracts 'We will not hide problems', and those vulerabilities that have already been made public, I think it'd be a good idea if the security team, once a vulnerability is already made public, for example via a Bugtraq or something, or some other vendor/upstream announced it, files a bug (tag woody usually I guess) in the BTS about it. There is no longer reason to hide the problem, i.e., keep it away from the BTS once it is published. This also enables other people to 1) see there is a security defect in that package in woody 2) help solving it by adding patches, so the security team only has to check the patches As an example, take CAN-2004-0519, CAN-2004-0520 and CAN-2004-0521, all three not yet solved in woody, but also not filed in the BTS (hm, two of them directly refer to a patch[2][3] solving it...). Therefore, I'd like to ask the security team to file grave bugs with security+woody on packages for which a vulnerability has been made public, and a security announcement isn't nearly-ready. I can't imagine this would interfere too much with the issue tracker or whatever the security team internally uses to track issues. Or is there some reason filing bugs like I described here isn't wanted? --Jeroen [1] http://lists.debian.org/debian-security/2004/07/msg00030.html [2] http://marc.theaimsgroup.com/?l=squirrelmail-cvs&m=108532891231712 [3] http://marc.theaimsgroup.com/?l=squirrelmail-cvs&m=108309375029888 -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
