Re: [Secure-testing-commits] r11636 - data/CVE
Michael Gilbert wrote: > On Wed, Apr 29, 2009 at 3:21 PM, Kees Cook wrote: > > The sync of NFUs seems to be generally accepted, so we'll continue to do > > that. Should we continue to attempt to open entries for stuff > > that is not yet listed in the Debian tracker? > > note this is in response to a post from a year ago. > > i've implemented a tag called for issues such as this. > if you would like to use that and include a "TODO: check", i think > that would be a very useful contribution back to debian. I agree that would be useful. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100511171443.gc2...@inutil.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Wed, Apr 29, 2009 at 3:21 PM, Kees Cook wrote: > The sync of NFUs seems to be generally accepted, so we'll continue to do > that. Should we continue to attempt to open entries for stuff > that is not yet listed in the Debian tracker? note this is in response to a post from a year ago. i've implemented a tag called for issues such as this. if you would like to use that and include a "TODO: check", i think that would be a very useful contribution back to debian. also, have you had any chance to think about further modifying your workflow that would help debian even more? my original suggestion is reproduced below: 1. discover an issue in ubuntu that you plan to issue a USN for. 2. check status of CVE in debian (debsecan could be used for this). 3a. if no existing debian report, submit bug to bugs.debian.org (note that bin/report-vuln in secure-testing svn makes this semi-automated), and preferably include a link to the launchpad report so the debian maintainer can make use of your existing work. 3b. if there is an existing debian report, submit email to bug with links to your launchpad report and patches. i noticed that this was sort of followed for a couple of the recent texlive issues, which was helpful. best wishes mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/t2w8e2a98be1005101713q2d23be17kee7cb186b6453...@mail.gmail.com
Re: [Secure-testing-commits] r11636 - data/CVE
On Fri, 8 May 2009 18:20:08 -0400 Michael S. Gilbert wrote: > 1. discover an issue in ubuntu main that you plan to issue a USN for. > 2. check status of CVE in debian (debsecan could be used for this). > 3. if no existing debian report, submit bug to bugs.debian.org (note > that bin/report-vuln in secure-testing svn makes this semi-automated), > and preferably include a link to the launchpad report and patches so the > debian maintainer can make use of your existing work. > wait for email from > the debian bts with bug # and update data/CVE/list with this info. i've been thinking about this, and i don't think that ubuntu should be burdened with updating the debian tracker. we can easily do this ourselves since we get copied when new security-related bugs are submitted. hence, i would remove this last sentance from item 3. would the ubuntu security team be willing to commit to the reduced steps 1-4? > 4. if there is an existing debian report submit email to that bug with > links to your launchpad report and patches. -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Wed, 29 Apr 2009 12:21:17 -0700 Kees Cook wrote: > Hi, > > On Sun, Apr 19, 2009 at 05:05:14PM -0400, Michael S. Gilbert wrote: > > hence, i think the following would be a good process for ubuntu > > security triagers: > > > > 1. triage issue in ubuntu > > 2. check status of CVE in debian (debsecan could be used for this) > > 3. submit bug report to launchpad (with link to debian bug report if > > it already exists) > > 4. update ubuntu security tracker > > 5. if no existing debian report, submit bug to bugs.debian.org (note > > that bin/report-vuln in secure-testing svn makes this semi-automated), > > and preferably include a link to the launchpad report so the debian > > maintainer can make use of your existing work > > 6. wait for email from the debian bts with bug # and update > > data/CVE/list with this info > > I should probably describe the two hats I wear: I'm employed by Canonical > to work on Ubuntu's "main" repository, and I'm a Debian Developer with some > of my free time. Wearing my Debian hat, my time is limited, so I focus > on areas of Debian that interest me. As it happens, I don't tend to spend > a large amount of my Debian time on security issues, since that's my day > job. :) > > Now, with my Canonical hat on, my role is the same as the other two > Canonical-employed Ubuntu Security Team folks: we are mandated to work on > security issues in "main" and to help facilitate work on "universe". To > this end, our current workflow for "step 1" above is to map CVEs to > packages in general, and if the package is in "main", we dig further to > identify specifically which versions of packages are affected, etc. I > would call this "mapping" and "triage". Since we only triage a subset of > Debian's repository, we are not in a good position to triage everything > for which there is a CVE assigned. However, since we do mapping for the > entire repository, that's the part of our workflow I've been trying to get > fed back into Debian. I've been doing this for some time now with NFUs. > > I feel that both "mapping" and "triage" are non-trivial tasks and had > assumed that helping with the "mapping" part would be a good thing. > Since the Ubuntu team has many priorities and tasks to juggle beyond > strictly triage work, we cannot commit to doing full triage of everything. > It's not because we don't want to help, but rather because our work > priorities demand our attention in other places. I do, however, want to > try to help in ways that are useful to Debian, obviously. > > The sync of NFUs seems to be generally accepted, so we'll continue to do > that. Should we continue to attempt to open entries for stuff > that is not yet listed in the Debian tracker? i completely understand where you are coming from, and i do appreciate the fact that you have a limited amount of time to work non-ubuntu issues. however, ubuntu is deriving a whole lot of value (i've heard that canonical is now close to turning a profit) from the volunteer work that goes on inside of debian, and i would hope to see a reasonable amount of emphasis on returning some of that favor. i personally am not looking for you to triage the whole set of packages in the debian archive, but instead that when you do triage an issue in ubuntu main that you provide some reasonable assistance (bug report and patches) back to debian so that we can make use of your work and hopefully push out updates for the issue at the same time (with the goal of closing the time gap between DSAs and USNs for the same CVE). we want to try to collaborate and reduce duplication of work. hence, what i would really like to see are your patches and discussion pushed into the related debian bug report so that we have an record what's going on on your end. hence, i propose a modified ubuntu workflow: 1. discover an issue in ubuntu main that you plan to issue a USN for. 2. check status of CVE in debian (debsecan could be used for this). 3. if no existing debian report, submit bug to bugs.debian.org (note that bin/report-vuln in secure-testing svn makes this semi-automated), and preferably include a link to the launchpad report so the debian maintainer can make use of your existing work. wait for email from the debian bts with bug # and update data/CVE/list with this info. 4. if there is an existing debian report submit email to bug with links to your launchpad report and patches. hopefully you can convince your management that this type of feedback to debian is beneficial and worth your time and effort. as an alternative, i am planning to get up to speed with the ubuntu-cve-tracker, and maybe i can derive this information from the work that you are already doing. mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
Hi, On Sun, Apr 19, 2009 at 05:05:14PM -0400, Michael S. Gilbert wrote: > hence, i think the following would be a good process for ubuntu > security triagers: > > 1. triage issue in ubuntu > 2. check status of CVE in debian (debsecan could be used for this) > 3. submit bug report to launchpad (with link to debian bug report if > it already exists) > 4. update ubuntu security tracker > 5. if no existing debian report, submit bug to bugs.debian.org (note > that bin/report-vuln in secure-testing svn makes this semi-automated), > and preferably include a link to the launchpad report so the debian > maintainer can make use of your existing work > 6. wait for email from the debian bts with bug # and update > data/CVE/list with this info I should probably describe the two hats I wear: I'm employed by Canonical to work on Ubuntu's "main" repository, and I'm a Debian Developer with some of my free time. Wearing my Debian hat, my time is limited, so I focus on areas of Debian that interest me. As it happens, I don't tend to spend a large amount of my Debian time on security issues, since that's my day job. :) Now, with my Canonical hat on, my role is the same as the other two Canonical-employed Ubuntu Security Team folks: we are mandated to work on security issues in "main" and to help facilitate work on "universe". To this end, our current workflow for "step 1" above is to map CVEs to packages in general, and if the package is in "main", we dig further to identify specifically which versions of packages are affected, etc. I would call this "mapping" and "triage". Since we only triage a subset of Debian's repository, we are not in a good position to triage everything for which there is a CVE assigned. However, since we do mapping for the entire repository, that's the part of our workflow I've been trying to get fed back into Debian. I've been doing this for some time now with NFUs. I feel that both "mapping" and "triage" are non-trivial tasks and had assumed that helping with the "mapping" part would be a good thing. Since the Ubuntu team has many priorities and tasks to juggle beyond strictly triage work, we cannot commit to doing full triage of everything. It's not because we don't want to help, but rather because our work priorities demand our attention in other places. I do, however, want to try to help in ways that are useful to Debian, obviously. The sync of NFUs seems to be generally accepted, so we'll continue to do that. Should we continue to attempt to open entries for stuff that is not yet listed in the Debian tracker? -Kees -- Kees Cook Ubuntu Security Team -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
Hi Michael, On Sun, Apr 26, 2009 at 07:30:06PM -0400, Michael S. Gilbert wrote: > have you had time to contemplate the above triage process (and/or We've not forgotten. :) Last was the release of Ubuntu Jaunty, so we were rather busy with various duties. I'll be sure to comment on this during the coming week. Thanks, -Kees -- Kees Cook Ubuntu Security Team -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Sun, 19 Apr 2009 17:05:14 -0400 Michael S. Gilbert wrote: > hence, i think the following would be a good process for ubuntu > security triagers: > > 1. triage issue in ubuntu > 2. check status of CVE in debian (debsecan could be used for this) > 3. submit bug report to launchpad (with link to debian bug report if > it already exists) > 4. update ubuntu security tracker > 5. if no existing debian report, submit bug to bugs.debian.org (note > that bin/report-vuln in secure-testing svn makes this semi-automated), > and preferably include a link to the launchpad report so the debian > maintainer can make use of your existing work > 6. wait for email from the debian bts with bug # and update > data/CVE/list with this info dear ubuntu security team, have you had time to contemplate the above triage process (and/or improvements to it)? it would be very helpful to the debian security team (and in fact to the overall security of both debian and ubuntu) if you are able to commit to a closer working relationship. best regards, mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
Kees Cook wrote:
> On Fri, Apr 17, 2009 at 09:48:47AM -0400, Michael S. Gilbert wrote:
> > i have one request to improve the process: please submit a 'NOTE' with
> > a link to the ubuntu patch whenever you issue a fix that hasn't been
> > issued by debian yet. this will help to increase the debian security
> > team's awareness of the work that has already been done, and hopefully
> > make it easier/faster to issue fixes. in fact, it would be preferable
> > to get this information during the process of preparing the patch,
> > rather than after the USN is issued.
>
> I think this would be do-able. We don't really have the best integration
> for our -security pocket when it comes to patch extraction. Right now the
> Ubuntu build-thing ("Soyuz") generates debdiff per-upload, but it gets
> easily confused by the -security pocket (i.e. it generate a diff against
> release, not -security origin). I have bugs open for them to get it fixed,
> so this will improve.
>
> Assuming I can generate a URL with a patch (and we'd have up to 5 patch
> URLs, depending on which of our releases were affected), the logic would
> be: if and patch URL exists, add NOTE:. Sounds right?
Sounds right, but please don't invest too much time of it. In most cases,
we use the same patch as provided by upstream or through vendor-sec and the
time needed to verify that a backport is correct is almost identical to
backporting it myself (with a few exceptions, of course). Still, that would
be very nice for review of one's own work.
For Debian we're planning a mailing list, where debdiffs of all source
packages issued through the security-archive are sent to. This way,
any user can review the patches post-release.
> > btw, it's great that you're now pushing your nfu's to debian. at least
> > that work will now get split between the two distros, rather than
> > duplicating the effort. thanks!
>
> Absolutely! I've been doing it for quite a while now, actually. I really
> do want to reduce work for both teams, and this was the lowest hanging
> fruit. Next lowest was putting in entries where Debian still had
> "TODO: check". Not really clear on what's next, though. :)
You can join the Debian Security Team, if you like.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Fri, 17 Apr 2009 08:43:27 -0700 Kees Cook wrote:
> On Fri, Apr 17, 2009 at 09:48:47AM -0400, Michael S. Gilbert wrote:
> > i have one request to improve the process: please submit a 'NOTE' with
> > a link to the ubuntu patch whenever you issue a fix that hasn't been
> > issued by debian yet. this will help to increase the debian security
> > team's awareness of the work that has already been done, and hopefully
> > make it easier/faster to issue fixes. in fact, it would be preferable
> > to get this information during the process of preparing the patch,
> > rather than after the USN is issued.
>
> I think this would be do-able. We don't really have the best integration
> for our -security pocket when it comes to patch extraction. Right now the
> Ubuntu build-thing ("Soyuz") generates debdiff per-upload, but it gets
> easily confused by the -security pocket (i.e. it generate a diff against
> release, not -security origin). I have bugs open for them to get it fixed,
> so this will improve.
>
> Assuming I can generate a URL with a patch (and we'd have up to 5 patch
> URLs, depending on which of our releases were affected), the logic would
> be: if and patch URL exists, add NOTE:. Sounds right?
a better logic would be: if no DSA issued yet for the particular CVE
add 'NOTE: ubuntu bug \n NOTE: ubuntu patch '
on second thought, i'm not sure if this information would be so useful
in the tracker. it would be more useful to transmit directly to the
debian maintainer via a new bug report or as additional information in
an existing bug report. note that this could be fairly automated: you
could retrieve the bug number from debian's secure-testing svn, and
send an automatic mail to that bug number.
> > also, would it be possible to coordinate security notices better? it
> > looks bad when one of the distros releases a fix and the other doesn't
> > get the same fix out for days or weeks (i'm not saying to delay the
> > fix, but to work more closely so both distros are ready to release at
> > the same time).
>
> For embargoed issues, this is supposed to happen already, by way of
> vendor-sec. Who all from Debian is on that list, and what are the policies
> and procedures you have in place for contacting maintainers?
>
> The recent udev thing seemed like a failure within Debian to contact
> the udev maintainer. One idea we'd had was to send email to the Debian
> maintainer for stuff we've ranked as "High" or "Critical", with something
> like "there's an embargoed issue with $pkg, please make sure you get
> details from the Debian security team."
i think embargoed issues are handled OK as is.
> For public issues, it's a pretty different arrangement. The bulk of the
> packages in the archive are "community-supported" from Ubuntu's
> perspective, so we do updates when there are volunteers to do debdiffs and
> more importantly, testing. That means we're frequently behind Debian for
> those updates, and I don't see a good way to stay up to date without people
> willing to test 4 stable releases of Ubuntu. For updates we _do_ publish,
> there is such a giant backlog of stuff to fix, we're just trying to get
> stuff out the door as fast as possible. There tends to be very little time
> between our taking an issue, testing, and publishing a fix.
>
> I'm open to ideas; this has traditionally been a tricky area to get right.
i'm more concerned about the issues where ubuntu releases a fix before
debian. during the process of preparing the fix, i would like to see
better coordination with the debian package maintainer and security team
so that they are right there with you and can get the DSA out pretty
much at the same time that you get your USN out.
thanks again for your hard work and interest on this!
mike
--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Sat, 18 Apr 2009 17:01:36 +0200Nico Golde wrote: > * Kees Cook [2009-04-17 18:38]: > > On Fri, Apr 17, 2009 at 10:57:38AM -0400, Michael S. Gilbert wrote: > > > On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote: > > > > * Kees Cook [2009-04-17 09:59]: > > > > > Author: kees > > > > > Date: 2009-04-17 01:25:52 + (Fri, 17 Apr 2009) > > > > > New Revision: 11636 > > > > > > > > > > Modified: > > > > >data/CVE/list > > > > > Log: > > > > > Sync from Ubuntu CVE tracker... > > > > > unfixed: archivemail azureus clamav evolution-data-server ghostscript > > > > > graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 > > > > > libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 > > > > > sun-java5 sun-java6 tomcat5.5 torrentflux typo3-src wireshark > > > > > xulrunner > > > > > fixed: lighttpd tunapie > > > > > > > > Could you please switch that off again? Without prior > > > > discussion I think such bots are not acceptable. I also > > > > don't think that we want automatic fixed entries, this is > > > > way to error prone. Also from what I experienced so far just > > > > adding entries doesn't help that much, usually it > > > > takes very long until someone picks that up and files a bug. > > > > > > > > I want at least a further discussion of this until you > > > > switch this on again. It's not that we were too lazy or to > > > > unskilled so far to play with soap and mark fixed bugs > > > > automatically in the tracker but as far as I can tell this > > > > wasn't done on purpose. > > > > > > if they submitted (semi-automated) bug reports for all of the unfixed > > > issues that they sync up, would that be sufficient to address your > > > concerns? > > No. I see no difference between TODO: check and > other than the knowledge of the package being in Debian. > Adding is not adding any valuable research which > you should do if you state it's unfixed. > > > > i agree that auto-marking fixed issues is quite dangerous and should > > > not be done. > > > > Sorry for not being clear on this; the commit isn't automatic. The tool on > > our side just adds entries, and then we go through and clean up > > stuff that has been obviously fixed (i.e. entries that have a DSA attached > > to it, etc). > > Ok > > > Since we're highly time-limited, we can't always go hunting through > > Debian changelogs or the BTS to see if a specific CVE is actually fixed. > > This would be as well not sufficient, reading and checking > the code is. Sure there will always be vulnerabilities where > this can't be done just because the fix is too complex, the > code completely changed or for some other reason, but just > following references and adding them this would make our > work useless, this can be fully-automated but is of no real > use. > > > I had made the assumption that marking a "TODO: check" CVE > > with a package and > > "" was more information than leaving it "TODO: check". If this is > > not the case, I'm happy to just disable that part again. I was just trying > > to find a way to sync information from our tracker into Debian's where > > Debian had no information listed. > > I really appreciate your work, especially because of the > often mentioned flame that Ubuntu is not contributing back. > Yes, is more information than a TODO: check but > imho alone not of much use and I tend to prevent it unless I > really don't have the time and I know that other people will > pick it up anyway (e.g. kernel issues). However as mentioned > above my problem with is that most of these issues > won't get picked up by somebody. One reason for this is > check-new-issues, it does check issues with TODO but not > with . > > This maybe worth a discussion but in my personal opinion > doesn't add much value without a corresponding bug > report and research. > > > We could file bugs, but then, I imagine people would be upset about > > duplicates. I figured that a CVE that says "TODO: check" says absolutely > > nothing, and requires a triager to do a full analysis, where-as a CVE that > > has a package listed, marked "unfixed" means a triager would have to only > > examine that single package. > > But unless it's firefox there shouldn't be a difference :) I > think these are really corner-cases and in the vast majority > we need commits that reflect good research. > > > As always, I'm open to any suggestions. I can take the package-adder out > > very easily and just go back to the old NFU-only merger. > > I don't want to represent the official meaning of the > security team, it would be nice to get other peoples opinion > too on this, but I think we should further discuss this. i also don't want to speak for the entire debian security team, but i think that what is really needed is bug reports (at least for your traiged unembargoed issues). this is the only way that the package maintainer gets made aware of security issues (changes to the security tra
Re: [Secure-testing-commits] r11636 - data/CVE
On freed 17 April 2009, Kees Cook wrote: > For embargoed issues, this is supposed to happen already, by way of > vendor-sec. Who all from Debian is on that list, and what are the policies > and procedures you have in place for contacting maintainers? The Security Team is on that list. We do contact maintainers when there's an issue affecting their packages. With udev that went wrong, probably because we had a reduced number of active people due to various VACs. > One idea we'd had was to send email to the Debian > maintainer for stuff we've ranked as "High" or "Critical", with something > like "there's an embargoed issue with $pkg, please make sure you get > details from the Debian security team." I'm not sure if this is a good idea, since some "maintainers" are actually public mailing lists. cheers, Thijs signature.asc Description: This is a digitally signed message part.
Re: [Secure-testing-commits] r11636 - data/CVE
Hi, On Fri, Apr 17, 2009 at 10:57:38AM -0400, Michael S. Gilbert wrote: > On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote: > > * Kees Cook [2009-04-17 09:59]: > > > Author: kees > > > Date: 2009-04-17 01:25:52 + (Fri, 17 Apr 2009) > > > New Revision: 11636 > > > > > > Modified: > > >data/CVE/list > > > Log: > > > Sync from Ubuntu CVE tracker... > > > unfixed: archivemail azureus clamav evolution-data-server ghostscript > > > graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 > > > libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 > > > sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > > > fixed: lighttpd tunapie > > > > Could you please switch that off again? Without prior > > discussion I think such bots are not acceptable. I also > > don't think that we want automatic fixed entries, this is > > way to error prone. Also from what I experienced so far just > > adding entries doesn't help that much, usually it > > takes very long until someone picks that up and files a bug. > > > > I want at least a further discussion of this until you > > switch this on again. It's not that we were too lazy or to > > unskilled so far to play with soap and mark fixed bugs > > automatically in the tracker but as far as I can tell this > > wasn't done on purpose. > > if they submitted (semi-automated) bug reports for all of the unfixed > issues that they sync up, would that be sufficient to address your > concerns? > > i agree that auto-marking fixed issues is quite dangerous and should > not be done. Sorry for not being clear on this; the commit isn't automatic. The tool on our side just adds entries, and then we go through and clean up stuff that has been obviously fixed (i.e. entries that have a DSA attached to it, etc). Since we're highly time-limited, we can't always go hunting through Debian changelogs or the BTS to see if a specific CVE is actually fixed. I had made the assumption that marking a "TODO: check" CVE with a package and "" was more information than leaving it "TODO: check". If this is not the case, I'm happy to just disable that part again. I was just trying to find a way to sync information from our tracker into Debian's where Debian had no information listed. We could file bugs, but then, I imagine people would be upset about duplicates. I figured that a CVE that says "TODO: check" says absolutely nothing, and requires a triager to do a full analysis, where-as a CVE that has a package listed, marked "unfixed" means a triager would have to only examine that single package. As always, I'm open to any suggestions. I can take the package-adder out very easily and just go back to the old NFU-only merger. -Kees -- Kees Cook Ubuntu Security Team -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Fri, Apr 17, 2009 at 09:48:47AM -0400, Michael S. Gilbert wrote:
> i have one request to improve the process: please submit a 'NOTE' with
> a link to the ubuntu patch whenever you issue a fix that hasn't been
> issued by debian yet. this will help to increase the debian security
> team's awareness of the work that has already been done, and hopefully
> make it easier/faster to issue fixes. in fact, it would be preferable
> to get this information during the process of preparing the patch,
> rather than after the USN is issued.
I think this would be do-able. We don't really have the best integration
for our -security pocket when it comes to patch extraction. Right now the
Ubuntu build-thing ("Soyuz") generates debdiff per-upload, but it gets
easily confused by the -security pocket (i.e. it generate a diff against
release, not -security origin). I have bugs open for them to get it fixed,
so this will improve.
Assuming I can generate a URL with a patch (and we'd have up to 5 patch
URLs, depending on which of our releases were affected), the logic would
be: if and patch URL exists, add NOTE:. Sounds right?
> also, would it be possible to coordinate security notices better? it
> looks bad when one of the distros releases a fix and the other doesn't
> get the same fix out for days or weeks (i'm not saying to delay the
> fix, but to work more closely so both distros are ready to release at
> the same time).
For embargoed issues, this is supposed to happen already, by way of
vendor-sec. Who all from Debian is on that list, and what are the policies
and procedures you have in place for contacting maintainers?
The recent udev thing seemed like a failure within Debian to contact
the udev maintainer. One idea we'd had was to send email to the Debian
maintainer for stuff we've ranked as "High" or "Critical", with something
like "there's an embargoed issue with $pkg, please make sure you get
details from the Debian security team."
For public issues, it's a pretty different arrangement. The bulk of the
packages in the archive are "community-supported" from Ubuntu's
perspective, so we do updates when there are volunteers to do debdiffs and
more importantly, testing. That means we're frequently behind Debian for
those updates, and I don't see a good way to stay up to date without people
willing to test 4 stable releases of Ubuntu. For updates we _do_ publish,
there is such a giant backlog of stuff to fix, we're just trying to get
stuff out the door as fast as possible. There tends to be very little time
between our taking an issue, testing, and publishing a fix.
I'm open to ideas; this has traditionally been a tricky area to get right.
> btw, it's great that you're now pushing your nfu's to debian. at least
> that work will now get split between the two distros, rather than
> duplicating the effort. thanks!
Absolutely! I've been doing it for quite a while now, actually. I really
do want to reduce work for both teams, and this was the lowest hanging
fruit. Next lowest was putting in entries where Debian still had
"TODO: check". Not really clear on what's next, though. :)
-Kees
--
Kees Cook@debian.org
--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Fri, 17 Apr 2009 11:30:19 +0200, Nico Golde wrote: > Hi, > * Kees Cook [2009-04-17 09:59]: > > Author: kees > > Date: 2009-04-17 01:25:52 + (Fri, 17 Apr 2009) > > New Revision: 11636 > > > > Modified: > >data/CVE/list > > Log: > > Sync from Ubuntu CVE tracker... > > unfixed: archivemail azureus clamav evolution-data-server ghostscript > > graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2 > > libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5 > > sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner > > fixed: lighttpd tunapie > > Could you please switch that off again? Without prior > discussion I think such bots are not acceptable. I also > don't think that we want automatic fixed entries, this is > way to error prone. Also from what I experienced so far just > adding entries doesn't help that much, usually it > takes very long until someone picks that up and files a bug. > > I want at least a further discussion of this until you > switch this on again. It's not that we were too lazy or to > unskilled so far to play with soap and mark fixed bugs > automatically in the tracker but as far as I can tell this > wasn't done on purpose. if they submitted (semi-automated) bug reports for all of the unfixed issues that they sync up, would that be sufficient to address your concerns? i agree that auto-marking fixed issues is quite dangerous and should not be done. mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
On Thu, 16 Apr 2009 23:40:00 -0700, Kees Cook wrote: > Hi Michael, > > On Thu, Apr 16, 2009 at 11:10:38PM -0400, Michael S. Gilbert wrote: > > would it make sense to integrate ubuntu's security tracker with > > debian's, especially since the two distros are so closely related? > > for example, [intrepid]/[jaunty] tags could be used to track > > ubuntu-specific issues within the debian tracker. > > > > this would greatly reduce duplication of effort and make it clear to > > the other team when the one pushes a fix since everyone will be getting > > updates from the same tracker. it would also make a lot of sense for > > the two teams to work more closely together. > > > > also, debsecan could finally be modified so that its output makes > > sense on ubuntu (a pet peeve of mine). > > > > just a thought. > > It was discussed a lot when we were first building out our tracker, but our > data sets are 4 times larger (we've effectively got 3 oldstables, 1 stable, > and 1 testing). Also, we wanted to have a lot more information represented > in our tracker that didn't really fit the format of the secure-testing > tracker. We modelled our tracker after the kernel-security tracker > instead. Our results are here[1]. > > Our tracker's support tools now both fetch hints from the Debian tracker as > well as push hints from our back out. NFU's have been working for a while > now, but today I finally finished the first pass at noticing "TODO: check" > entries where Ubuntu knows about a possible package match in the Debian > archive. > > So, I'm trying to work as closely as possible, but we've got a lot of > demands for statistics, bug links, credit, and our > Canonical-supported/community-support split. There's a ton of metadata > we're hauling around in our entries, and it seemed like it wouldn't be much > fun to jam all that into the Debian tracker. this seems very well-reasoned. i have one request to improve the process: please submit a 'NOTE' with a link to the ubuntu patch whenever you issue a fix that hasn't been issued by debian yet. this will help to increase the debian security team's awareness of the work that has already been done, and hopefully make it easier/faster to issue fixes. in fact, it would be preferable to get this information during the process of preparing the patch, rather than after the USN is issued. also, would it be possible to coordinate security notices better? it looks bad when one of the distros releases a fix and the other doesn't get the same fix out for days or weeks (i'm not saying to delay the fix, but to work more closely so both distros are ready to release at the same time). btw, it's great that you're now pushing your nfu's to debian. at least that work will now get split between the two distros, rather than duplicating the effort. thanks! mike -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
Hi Michael, On Thu, Apr 16, 2009 at 11:10:38PM -0400, Michael S. Gilbert wrote: > would it make sense to integrate ubuntu's security tracker with > debian's, especially since the two distros are so closely related? > for example, [intrepid]/[jaunty] tags could be used to track > ubuntu-specific issues within the debian tracker. > > this would greatly reduce duplication of effort and make it clear to > the other team when the one pushes a fix since everyone will be getting > updates from the same tracker. it would also make a lot of sense for > the two teams to work more closely together. > > also, debsecan could finally be modified so that its output makes > sense on ubuntu (a pet peeve of mine). > > just a thought. It was discussed a lot when we were first building out our tracker, but our data sets are 4 times larger (we've effectively got 3 oldstables, 1 stable, and 1 testing). Also, we wanted to have a lot more information represented in our tracker that didn't really fit the format of the secure-testing tracker. We modelled our tracker after the kernel-security tracker instead. Our results are here[1]. Our tracker's support tools now both fetch hints from the Debian tracker as well as push hints from our back out. NFU's have been working for a while now, but today I finally finished the first pass at noticing "TODO: check" entries where Ubuntu knows about a possible package match in the Debian archive. So, I'm trying to work as closely as possible, but we've got a lot of demands for statistics, bug links, credit, and our Canonical-supported/community-support split. There's a ton of metadata we're hauling around in our entries, and it seemed like it wouldn't be much fun to jam all that into the Debian tracker. -Kees [1] https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master -- Kees Cook@debian.org -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Secure-testing-commits] r11636 - data/CVE
would it make sense to integrate ubuntu's security tracker with
debian's, especially since the two distros are so closely related?
for example, [intrepid]/[jaunty] tags could be used to track
ubuntu-specific issues within the debian tracker.
this would greatly reduce duplication of effort and make it clear to
the other team when the one pushes a fix since everyone will be getting
updates from the same tracker. it would also make a lot of sense for
the two teams to work more closely together.
also, debsecan could finally be modified so that its output makes
sense on ubuntu (a pet peeve of mine).
just a thought.
mike
On Fri, 17 Apr 2009 01:25:52 +
Kees Cook wrote:
> Author: kees
> Date: 2009-04-17 01:25:52 + (Fri, 17 Apr 2009)
> New Revision: 11636
>
> Modified:
>data/CVE/list
> Log:
> Sync from Ubuntu CVE tracker...
> unfixed: archivemail azureus clamav evolution-data-server ghostscript
> graphicsmagick iceape iceweasel jbossas4 libapache2-mod-perl2
> libstruts1.2-java linux-2.6 ntp openjdk-6 python2.4 python2.5 sun-java5
> sun-java6 tomcat5.5 torrentflux typo3-src wireshark xulrunner
> fixed: lighttpd tunapie
>
>
> Modified: data/CVE/list
> ===
> --- data/CVE/list 2009-04-16 21:14:13 UTC (rev 11635)
> +++ data/CVE/list 2009-04-17 01:25:52 UTC (rev 11636)
> @@ -163,15 +163,15 @@
> - php4 (the JSON extension was introduced in php5.2)
> - php-json-ext
> CVE-2009-1269 (Unspecified vulnerability in Wireshark 0.99.6 through 1.0.6
> allows ...)
> - TODO: check
> + - wireshark
> CVE-2009-1268 (The Check Point High-Availability Protocol (CPHAP) dissector
> in ...)
> - TODO: check
> + - wireshark
> CVE-2009-1267 (Unspecified vulnerability in the LDAP dissector in Wireshark
> 0.99.2 ...)
> - TODO: check
> + - wireshark
> CVE-2009-1266
> RESERVED
> CVE-2009-1265 (Integer overflow in rose_sendmsg (sys/net/af_rose.c) in the
> Linux ...)
> - TODO: check
> + - linux-2.6
> CVE-2009-1264 (Frontend User Registration (sr_feuser_register) extension
> 2.5.20 and ...)
> NOT-FOR-US: Frontend User Registration (sr_feuser_register) extension
> CVE-2009-1263 (SQL injection vulnerability in sub_commententry.php in the
> BookJoomlas ...)
> @@ -193,7 +193,7 @@
> CVE-2009-1255
> RESERVED
> CVE-2008-6679 (Buffer overflow in the BaseFont writer module in Ghostscript
> 8.62, and ...)
> - TODO: check
> + - ghostscript
> CVE-2008-6678 (SQL injection vulnerability in asp/includes/contact.asp in
> QuickerSite ...)
> NOT-FOR-US: QuickerSite
> CVE-2008-6677 (Unrestricted file upload vulnerability in ...)
> @@ -239,7 +239,7 @@
> CVE-2008-6657 (Cross-site request forgery (CSRF) vulnerability in index.php
> in Simple ...)
> NOT-FOR-US: Simple Machines Forum
> CVE-2007-6725 (The CCITTFax decoding filter in Ghostscript 8.60, 8.61, and
> possibly ...)
> - TODO: check
> + - ghostscript
> CVE-2009- [roundup: insufficient access checks in web frontend]
> - roundup (bug #518768)
> [etch] - roundup 1.2.1-10+etch1
> @@ -259,10 +259,10 @@
> - clamav 0.94.dfsg.2-1~volatile2 (medium; bug #523016)
> CVE-2009-1254 (James Stone Tunapie 2.1 allows remote attackers to execute
> arbitrary ...)
> {DSA-1764-1}
> - TODO: check
> + - tunapie 2.1.17-1
> CVE-2009-1253 (James Stone Tunapie 2.1 allows local users to overwrite
> arbitrary ...)
> {DSA-1764-1}
> - TODO: check
> + - tunapie 2.1.17-1
> CVE-2009-1252
> RESERVED
> CVE-2009-1251 (Heap-based buffer overflow in the cache manager in the client
> in ...)
> @@ -360,7 +360,7 @@
> CVE-2008-6622 (SQL injection vulnerability in choosecard.php in WEBBDOMAIN
> Post Card ...)
> NOT-FOR-US: WEBBDOMAIN Multi Languages WebShop Online
> CVE-2008-6621 (Unspecified vulnerability in GraphicsMagick before 1.2.3
> allows remote ...)
> - TODO: check
> + - graphicsmagick
> CVE-2008-6620 (Multiple cross-site scripting (XSS) vulnerabilities in ...)
> NOT-FOR-US: GraFX miniCWB
> CVE-2008-6619 (Unrestricted file upload vulnerability in class/ApplyDB.php
> in ...)
> @@ -421,7 +421,7 @@
> CVE-2008-6595 (SQL injection vulnerability in the pmk_rssnewsexport
> extension for ...)
> NOT-FOR-US: pmk_rssnewsexport extension for TYPO3
> CVE-2008-6594 (SQL injection vulnerability in the cm_rdfexport extension for
> TYPO3 ...)
> - TODO: check
> + - typo3-src
> CVE-2008-6593 (SQL injection vulnerability in LightNEasy/lightneasy.php in
> LightNEasy ...)
> NOT-FOR-US: LightNEasy SQLite
> CVE-2008-6592 (thumbsup.php in Thumbs-Up 1.12, as used in LightNEasy
> "no database" ...)
> @@ -435,13 +435,13 @@
> CVE-2008-6588 (Aztech ADSL2/2+ 4-port router has a default "isp"
> account with a ...)
> NOT-FOR-US: Aztech port router
> CVE-2008-6587 (Cross-site request forgery (CSRF) vulnerability in index.tmpl
> in Vuze ...)
