Re: faster tracker data processing

[Michael S Gilbert]

On Fri, 02 Oct 2009 08:37:23 -0500 Raphael Geissert wrote:
> We could actually try to write some sort of automated system to contact the
> maintainer(s) when a new issue is published regarding their package. But I
> guess we would need a blacklisting system to avoid spamming some people or
> teams who are usually aware of those issues in advance (kernel sec team
> maybe? people working on the tracker, etc)

this would be good, but there is a danger of the bot going haywire and
potentially flooding the bts (i suppose you could set a shutoff limit
that would kill the bot if it submitted more than X per minute).  also,
maintainers may find a bot unfriendly or potentially offensive?  but it
may be worth trying it.

> >> If that's not desirable, maybe a concept of "HINT"s could be introduced,
> >> where the script that updates the CVE/list file from the CVE db
> >> automatically adds HINTs of possibly affected packages based on the
> >> embedded-code-copies files, the technique used by the check-new-issues
> >> (apt-cache search), and a simple file that could be used to associate
> >> full project names with a package name (say "Alvaro's Messenger" with
> >> "amsn"). The tracker would of course display the CVE as affecting the
> >> HINTed packages until the hints are removed from CVE/list.
> > 
> > this seems like a good idea, but i would be cautious.  taking people out
> > of the loop may be dangerous if not done correctly. i would suggest that
> > the final product of such a script would be at most a 'TODO:
> > check , , ... (not comprehensive)' so someone will
> > have a good starting point, but will be aware that the bot's output
> > isn't a complete list of potentially vulnerable packages.
> 
> I actually meant something more like:
> 
> CVE-2009-1234 (heap overflow in Alvaro's Messenger could...)
> TODO: check
> HINT: amsn
> CVE-2009-2345 (incorrect handling of null-terminated strings in foo...)
> TODO: check
> HINT: foo (if such a package existed)

i don't think its necessary to invent a new tag.  i meant:

  CVE-2009-1234 (heap overflow in Alvaro's Messenger could...)
  TODO: check amsn (and other packages)
  CVE-2009-2345 (incorrect handling of null-terminated strings in foo..)
  TODO: check foo (and other packages)

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: faster tracker data processing

[Michael S Gilbert]

On Wed, 30 Sep 2009 23:49:54 -0500 Raphael Geissert wrote:

> Hi,
> 
> I haven't had much time lately to actively audit and fix vulnerabilities,
> but I usually take a look at the commits and there are times I see that a
> new CVE id was assigned to some app shipped on Debian.
> 
> What is the general opinion of for example when finding such entries add a
> simple '- package ' entry and leave the 'TODO: check' around?

this is a good start, but since your time is limited, it would be wise
to pass the buck to the maintainer (who should have time to work issues
in their packages) via a bug report. you can then add a 'TODO:
follow-up with maintainer (asked to check whether  affected)'
or something like that. of course 99% of the time, the maintainer will
do nothing, and one of the other security team members will have to
come back to it, but at least the current state is pretty clear when
they get to it.

> If that's not desirable, maybe a concept of "HINT"s could be introduced,
> where the script that updates the CVE/list file from the CVE db
> automatically adds HINTs of possibly affected packages based on the
> embedded-code-copies files, the technique used by the check-new-issues
> (apt-cache search), and a simple file that could be used to associate full
> project names with a package name (say "Alvaro's Messenger" with "amsn").
> The tracker would of course display the CVE as affecting the HINTed packages
> until the hints are removed from CVE/list.

this seems like a good idea, but i would be cautious.  taking people out
of the loop may be dangerous if not done correctly. i would suggest that
the final product of such a script would be at most a 'TODO:
check , , ... (not comprehensive)' so someone will
have a good starting point, but will be aware that the bot's output
isn't a complete list of potentially vulnerable packages.

inject-embedded-code-copies is an existing script that automatically
inserts TODOs for embedded code copies.  it could be set up to run on
every commit, but i need to finish triaging the existing issues to
prevent a deluge of TODOs to begin with.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: testing vs. stable on the tracker: n-th round

[Michael S Gilbert]

On Sun, 6 Sep 2009 00:55:58 +0200 Francesco Poli wrote:

> Hi all!
> 
> Once again, a lenny update was issued.
> Once again, there are vulnerabilities in the tracker that show up as
> fixed in lenny (or lenny security), and as unfixed in squeeze, despite
> the package version is the *same* in the two branches:
> 
> http://security-tracker.debian.net/tracker/CVE-2009-0040
> http://security-tracker.debian.net/tracker/CVE-2009-0352
> http://security-tracker.debian.net/tracker/CVE-2009-0353
> http://security-tracker.debian.net/tracker/CVE-2009-0652
> http://security-tracker.debian.net/tracker/CVE-2009-0771
> http://security-tracker.debian.net/tracker/CVE-2009-0772
> http://security-tracker.debian.net/tracker/CVE-2009-0773
> http://security-tracker.debian.net/tracker/CVE-2009-0774
> http://security-tracker.debian.net/tracker/CVE-2009-0776
> http://security-tracker.debian.net/tracker/CVE-2009-1302
> http://security-tracker.debian.net/tracker/CVE-2009-1303
> http://security-tracker.debian.net/tracker/CVE-2009-1307
> http://security-tracker.debian.net/tracker/CVE-2009-1392
> http://security-tracker.debian.net/tracker/CVE-2009-1832
> http://security-tracker.debian.net/tracker/CVE-2009-1836
> http://security-tracker.debian.net/tracker/CVE-2009-1838
> http://security-tracker.debian.net/tracker/CVE-2009-1841
> http://security-tracker.debian.net/tracker/CVE-2009-2210 (twice)
> http://security-tracker.debian.net/tracker/CVE-2009-2446
> http://security-tracker.debian.net/tracker/CVE-2009-2654
> http://security-tracker.debian.net/tracker/CVE-2009-2726
> 
> Please fix these inconsistencies.

these should be fixed now.  the tracker is not set up to automatically
handle the stable point release -> testing automatic transitions, so you
can expect this with every new point release, and we will have to fix
it manually.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSA-188[01]-1 vs. tracker

[Michael S Gilbert]

On Mon, 7 Sep 2009 22:25:09 +0200 Francesco Poli wrote:

> Hi everyone,
> I noticed a problem with the tracker page [1] for DSA-1880-1 [2].
> The problem is the lack of the epoch in lenny (security) fixed version,
> and in squeeze/sid fixed version (see individual CVE tracker pages).
> 
> [1] http://security-tracker.debian.net/tracker/DSA-1880-1
> [2] http://lists.debian.org/debian-security-announce/2009/msg00199.html
> 
> Moreover, there's no tracker page [3] for DSA-1881-1 [4].
> 
> [3] http://security-tracker.debian.net/tracker/DSA-1881-1
> [4] http://lists.debian.org/debian-security-announce/2009/msg00200.html
> 
> Please fix these inconsistencies.
> Thanks for your time.

done.  thanks for spotting.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: No tracker page for DSA-1870-1

[Michael S. Gilbert]

On Thu, 20 Aug 2009 15:24:59 +0200, Francesco Poli wrote:
> Hi everyone!
> 
> There seems to be no tracker page for DSA-1870-1 [1].
> Please add it by hand, if the automatic mechanism failed.

done.


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: No tracker page for DSA-1861-1

[Michael S Gilbert]

On Fri, Aug 14, 2009 at 4:02 PM, Florian Weimer wrote:
> * Michael S. Gilbert:
>
>> On Fri, 14 Aug 2009 00:58:46 +0200 Francesco Poli wrote:
>>> Hi all!
>>>
>>> I cannot yet find any tracker page for DSA-1861-1 [1].
>>> Please add it by hand, if the automatic mechanism failed somehow.
>>
>> done.
>
> By the way, usually, you can pipe the DSA through dsa2list, and it
> will produce a proper entry.  It downloads the .dsc files to get the
> correct version numbers, so it's pretty reliable.

thanks for the tip.

> I don't know why Thijs' auto-updater fails, perhaps it's because the
> .dsc is not yet avaiable (dak being rather sluggish lately).

it seems that when it doesn't kick in right away after the DSA that it
never will.  so, i'd say if you don't see his update within a few
minutes, do it manually.  also, sometimes the DSAs don't quite adhere
to the template, and dsa2list will fail.

mike


--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: No tracker page for DSA-1861-1

[Michael S. Gilbert]

On Fri, 14 Aug 2009 00:58:46 +0200 Francesco Poli wrote:
> Hi all!
> 
> I cannot yet find any tracker page for DSA-1861-1 [1].
> Please add it by hand, if the automatic mechanism failed somehow.

done.


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSA-1858-1 and lenny on the tracker

[Michael S. Gilbert]

On Tue, 11 Aug 2009 15:33:45 +0200, Francesco Poli wrote:
> On Mon, 10 Aug 2009 19:46:52 -0400 Michael S. Gilbert wrote:
> 
> > On Mon, 10 Aug 2009 23:32:22 +0200, Francesco Poli wrote:
> [...]
> > > The tracker [2] seems to fail to correctly provide information about
> > > lenny, since it seems to think that all CVEs are fixed for lenny in
> > > version 7:6.3.7.9.dfsg2-1~lenny3 (while this is true for the last one
> > > only, as the other ones are already fixed in current lenny version,
> > > rather than in a security update).
> [...]
> > > Please fix these inconsistencies, if possible.
> > 
> > this is a flaw in the tracker.  we don't have the ability to separate
> > out CVEs per release in the DSA list, so we end up with this problems
> > like this. i've been meaning to look into fixing this, and i may find
> > the time, but until then, there is no sane way to correct the problem.
> 
> That's unfortunate.
> There's a difference in etch-backports information, though: how is it
> obtained?

*-backports tracking is not entered via the DSA list, so it isn't prone
to that problem.  however, i've never seen anyone actually do any
specific tracking for backports, so i think that the tracker is
deriving that information automatically from unstable (i.e. if the
backports version is greater than or equal to the unstable version that
was fixed, then the backports version is also considered fixed). anyone
else have a better idea on how that works?

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSA-1858-1 and lenny on the tracker

[Michael S. Gilbert]

On Mon, 10 Aug 2009 23:32:22 +0200, Francesco Poli wrote:
> Hi all!
> 
> According to DSA-1858-1 [1], a number of imagemagick vulnerabilities
> only affect etch (CVE-2007-1667 CVE-2007-1797 CVE-2007-4985
> CVE-2007-4986 CVE-2007-4987 CVE-2007-4988 CVE-2008-1096 CVE-2008-1097),
> while one affects etch and lenny (CVE-2009-1882).
> The latter (CVE-2009-1882) was fixed for lenny in version
> 7:6.3.7.9.dfsg2-1~lenny3.
> 
> The tracker [2] seems to fail to correctly provide information about
> lenny, since it seems to think that all CVEs are fixed for lenny in
> version 7:6.3.7.9.dfsg2-1~lenny3 (while this is true for the last one
> only, as the other ones are already fixed in current lenny version,
> rather than in a security update).
> Moreover, the tracker seems to be still unaware of a
> 7:6.3.7.9.dfsg2-1~lenny3 security update for lenny (maybe because it
> has not yet been uploaded? see [3]).
> 
> Please note that, on the other hand, etch, squeeze, and sid information
> seems to be OK in the tracker.
> 
> Please fix these inconsistencies, if possible.

this is a flaw in the tracker.  we don't have the ability to separate
out CVEs per release in the DSA list, so we end up with this problems
like this. i've been meaning to look into fixing this, and i may find
the time, but until then, there is no sane way to correct the problem.

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] r12552 - data/CVE

[Michael S. Gilbert]

On Mon, 10 Aug 2009 20:24:10 +0200, Nico Golde wrote:
> Hi,
> * Michael S. Gilbert  [2009-08-10 20:18]:
> > On Mon, 10 Aug 2009 18:09:16 +, Nico Golde wrote:
> [...] 
> > > -CVE-2009-2414
> > > +CVE-2009-2414 [libxml2 stack recursion]
> > >   RESERVED
> > > + - libxml2  (medium; bug #540865)
> > > + [etch] - libxml 
> > 
> > i thought  tags for stable releases were discouraged?
> 
> Hmm. I wasn't pretty sure how to mark this. In this case 
> only etch contains libxml. Would be adding  tags 
> for lenny and unstable (or is only lenny required in this 
> case) a better solution in this case? Florian?

i think you would want to do

- libxml 
[etch] - libxml  (backport not feasible)

or something like that.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: No tracker page for DSA-1855-1, no TEMP for DSA-1856-1

[Michael S. Gilbert]

On Sun, 9 Aug 2009 15:20:17 +0200 Francesco Poli wrote:
> There's no tracker page for DSA-1855-1 [1], yet.
> Please add it by hand, if the automatic mechanism failed somehow.
> 
> Moreover, there's the usual problem with the CVE-less DSA-1856-1 [2],
> no!, worse: the tracker page is present, but there seems to be no TEMP
> vulnerability name for the issue [3]. Please add it by hand, if
> possible.

both fixed.  thanks for reporting.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSA-1852-1 vs. tracker

[Michael S Gilbert]

fixed.

On Fri, Aug 7, 2009 at 4:44 PM, Francesco Poli wrote:
> Hi all!
>
> DSA-1852-1 [1] claims that CVE-2009-2666 is fixed for sid in
> fetchmail/6.3.9~rc2-6, but the tracker [2] seems to disagree.
>
> [1] http://lists.debian.org/debian-security-announce/2009/msg00168.html
> [2] http://security-tracker.debian.net/tracker/CVE-2009-2666
>
> Please fix this inconsistency on the tracker.
>
> --
>  New location for my website! Update your bookmarks!
>  http://www.inventati.org/frx
> . Francesco Poli .
>  GnuPG key fpr == C979 F34B 27CE 5CD8 DC12  31B5 78F4 279B DD6D FCF4
>


--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Can the tracker fetch version information from the BTS?

[Michael S. Gilbert]

On Mon, 3 Aug 2009 15:24:58 +0200, Francesco Poli wrote:
> I thought I could be smarter than the tracker and sent a message to the
> control bot, marking the bug as fixed in the security-update versions:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=17;bug=537977
> 
> Almost one day has passed, and this new information still fails to show
> up in  http://security-tracker.debian.net/tracker/537977
> 
> What's wrong?
> I thought the tracker could fetch version information from the BTS,
> when a vulnerability is associated with a BTS bug...
> Was I too optimistic?   ;-)

the tracker is not integrated with the bts at all.  someone manually
enters the associated bug number and the tracker generates an http
link on the appropriate page. that is the extent of how they are
linked.

this is a problem with how the tracker handles non-numbered issues.
the security team recently met to discuss workflow problems like this,
and i think the outcome was that we will be able to assign CVEs from a
pool alloted to debian, but i don't think the "how to do" this has been
worked out yet.

in the meantime, i will manually enter the information.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Another stable vs. testing inconsistency

[Michael S. Gilbert]

On Wed, 29 Jul 2009 22:00:46 +0200, Francesco Poli wrote:
> Hi all!
> 
> I found another vulnerability in the tracker that shows up as fixed in
> lenny, and as unfixed in squeeze, despite the package version is the
> *same* in the two branches.
> 
> http://security-tracker.debian.net/tracker/CVE-2009-2584

fixed.  i keep overlooking squeeze when i do these updates.  i will
force myself to remember next time.

> BTW, the fix seems to be
> http://lkml.org/lkml/2009/7/20/348
> which, IIUC, has not yet been applied to the upstream mainline kernel
> 
> I haven't even found a Debian BTS bug report: should an important (?)
> bug be filed?

the vulnerable code was introduced after 2.6.26, so only unstable's
kernel is affected. the kernel-sec team is aware and tracking the
problem, so a report is not necessary.

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] r12286 - data/CVE

[Michael S. Gilbert]

On Mon, 6 Jul 2009 16:32:42 +1000 Steffen Joeris wrote:

> On Mon, 6 Jul 2009 12:55:48 pm Michael Gilbert wrote:
> > Author: gilbert-guest
> > Date: 2009-07-06 02:55:48 + (Mon, 06 Jul 2009)
> > New Revision: 12286
> >
> > Modified:
> >data/CVE/list
> > Log:
> > syncing some kernel info from kernel-sec tracker
> Is there a way that this could be done automatically? Maybe with some post-
> commit script from the kernel-sec tracker (which I am not aware about).

this is probably possible, but i would rather see kernel-sec merge with
secure-testing.  why should two trackers be maintained separately?
Dann Frazier has some concerns with secure-testing, but i think they
can be reasonably addressed with some minor additions.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux kernel vulnerabilities in unstable

[Michael S. Gilbert]

On Tue, 7 Jul 2009 23:32:57 +0200, Francesco Poli wrote:
> I think that *introducing* (that is to say, as a regression) a security
> hole that allows a denial of service attack (crash) and/or a privilege
> escalation attack *does* have serious consequences. 

priviledge escalations are considered release-critical,
denial-of-services are not.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux kernel vulnerabilities in unstable

[Michael S. Gilbert]

On Tue, 7 Jul 2009 19:51:16 +0200, Francesco Poli wrote:
> Well, if I see correctly, by "plenty" you mean 5:
> 
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linux-2.6&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious&repeatmerged=no
> 
> Moreover, please note that all of these bugs are already present in
> testing, as far as the BTS version tracking knows (unless I am
> misinterpreting the BTS HTML output): as a consequence, none of them
> should block the migration to testing.

by all means, go ahead and file the bugs; just make sure that the
consequences are serious or greater before filing as RC. there is some
new relevant discussion on -devel [1] indicating intent get the
unstable kernel moving into testing soon (primarily to move d-i
development forward).

mike

[1] http://lists.debian.org/debian-devel/2009/07/msg00196.html


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux kernel vulnerabilities in unstable

[Michael S. Gilbert]

On Tue, 7 Jul 2009 00:24:16 +0200 Francesco Poli wrote:
> Should a grave bug be filed against the linux-2.6 source package, in
> order to prevent its migration to testing until this regression is
> fixed (or confirmed to be already fixed)?
> Are you willing to do that, or do you prefer that I file the bug by
> myself?

the kernel-sec team is already aware of these issues [1].  filing a bug
may be useful to increase visibility, and to provide another place to
discuss the problem; but not really necessary.

i believe kernel migration is a manual process (not entirely sure), and
there are already plenty of RC bugs on the kernel, so 2.6.30 isn't
migrating any time soon.

i hope the idea is to stick with the lenny kernels for the time being
since they are getting reasonably quick security updates (but, again,
i'm not sure if this is the plan or not).

mike

[1] http://svn.debian.org/wsvn/kernel-sec


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux kernel vulnerabilities in unstable

[Michael S Gilbert]

On 7/5/09, Francesco Poli wrote:
> http://security-tracker.debian.net/tracker/CVE-2007-6514
> commit ???
> applied to upstream version ???
> see ???
> fix present in upstream version 2.6.30: I don't know
>help!  the CVE mitre page does not link to any fix, it seems

the attack vector for this one is so obscure: the worst that can
happen is disclosure of scripts hosted on an apache server serving
those scripts, and only if those scripts are on a windows share.  i'd
almost be inclined to say no-dsa for this one (or issue a dsa that
says don't host your apache scripts on a windows share).  it's hardly
worth worrying about.

> http://security-tracker.debian.net/tracker/CVE-2008-6107
> commit 94d149c34cda933ff5096aca94bb23bf68602f4e
> applied to upstream version 2.6.26
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.26
> fix present in upstream version 2.6.26: yes
> fix present in upstream version 2.6.30: it seems to be present

94d149c34cda933ff5096aca94bb23bf68602f4e looks to be for
CVE-2008-1673, so i disagree here.

> http://security-tracker.debian.net/tracker/CVE-2009-0029
> commit ???
> applied to upstream version ???
> see ???
> fix present in upstream version 2.6.30: I don't know
>   help!  the CVE mitre page links to this lkml message from Linus
>   Torvalds, who seems to discuss about some aspect, but where's
>   the fix?
>   http://marc.info/?l=linux-kernel&m=123155111608910&w=2

patches are here: https://bugzilla.redhat.com/show_bug.cgi?id=479969.
this one is a mess.  it's highly likely in 2.6.30, but it's going to
take some work to confirm this.

> http://security-tracker.debian.net/tracker/CVE-2009-1914
> commit 192d7a4667c6d11d1a174ec4cad9a3c5d5f9043c
> applied to upstream version 2.6.29
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.29
> fix present in upstream version 2.6.30: yes

confirmed.

> http://security-tracker.debian.net/tracker/CVE-2009-1961
> commit 7bfac9ecf0585962fe13584f5cf526d8c8e76f17
> applied to upstream version 2.6.30
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30
> fix present in upstream version 2.6.30: yes

this code has been significantly refactored, so i can't confirm this.

> http://security-tracker.debian.net/tracker/CVE-2009-2287
> commit 59839dfff5eabca01cc4e20b45797a60a80af8cb
> applied to upstream version [none yet]
> see [no changelog]
> fix present in upstream version 2.6.30: no

this is probably already commited to 2.6.31 and will need to be backported.

thanks so much for helping out with this triage.  it was imensely helpful.

cheers,
mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Linux kernel vulnerabilities in unstable [was: Re: stable vs. testing: same versions, different status]

[Michael S Gilbert]

On 7/5/09, Francesco Poli wrote:
> http://security-tracker.debian.net/tracker/CVE-2009-0834
> commit 8776fc989b070d4a323793502365acae6851d936
> applied to upstream version 2.6.28.8
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28.8
> fix present in upstream version 2.6.30: yes

confirmed.

> http://security-tracker.debian.net/tracker/CVE-2009-0835
> commit 1ab4bad21786384ff68dc6576d021acd4e42d8ce
> applied to upstream version 2.6.28.8
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28.8
> fix present in upstream version 2.6.30: yes

confirmed.

> http://security-tracker.debian.net/tracker/CVE-2009-1242
> commit 16175a796d061833aacfbd9672235f2d2725df65
> applied to upstream version 2.6.29.1
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.29.1
> fix present in upstream version 2.6.30: yes

confirmed

> http://security-tracker.debian.net/tracker/CVE-2009-1338
> commit d25141a818383b3c3b09f065698c544a7a0ec6e7
> applied to upstream version 2.6.28
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28
> fix present in upstream version 2.6.30: yes

confirmed.

> http://security-tracker.debian.net/tracker/CVE-2009-1630
> commit ???
> applied to upstream version ???
> see ???
> fix present in upstream version 2.6.30: no?!?
>   help!  the fix seems to be
>   http://bugzilla.linux-nfs.org/show_bug.cgi?id=131
>   but fs/nfs/dir.c in linux-2.6_2.6.30.orig.tar.gz does not seem to be fixed
>   I could not even find the fix in linux-2.6_2.6.26-17.diff.gz: is this bug
>   really fixed in Debian stable and Debian testing?!?

upstream patch is 7ee2cb7f32b299c2b06a31fde155457203e4b7dd
and it is indeed integrated in 2.6.30.

> http://security-tracker.debian.net/tracker/CVE-2009-1633
> commit 7b0c8fcff47a885743125dd843db64af41af5a61
> commit 968460ebd8006d55661dec0fb86712b40d71c413
> commit 27b87fe52baba0a55e9723030e76fce94fabcea4
> applied to upstream version 2.6.29.4
> see http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.29.4
> fix present in upstream version 2.6.30: it seems to be present

7b0c8fcff47a885743125dd843db64af41af5a61 confirmed.  you have to be
careful, this code has been changed since 2.6.29 and now does the
smart thing using UNICODE_NAME_MAX.

968460ebd8006d55661dec0fb86712b40d71c413 confirmed but should be
double checked.  this code has been completely refactored (and renamed
and some of it is now in cifs_unicode.c), but it doesn't look like the
original problematic code is still present.

27b87fe52baba0a55e9723030e76fce94fabcea4 confirmed but also slightly refactored.

i'm going to defer this one since there has been so much refactoring.

> http://security-tracker.debian.net/tracker/CVE-2009-1758
> commit ???
> applied to upstream version ???
> see ???
> fix present in upstream version 2.6.30: I don't know
>   help!  the fix seems to be
>   http://lists.xensource.com/archives/html/xen-devel/2009-05/msg00561.html
>   but arch/i386/kernel/entry-xen.S is not even present in
>   linux-2.6_2.6.30.orig.tar.gz

this is a xen patch, which i haven't really dealt with before.  i'll
have to ask around to figure out how xen is integrated.

tracker updated.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: CVE-2009-0935 and 2.6.30 kernel

[Michael S. Gilbert]

On Fri, 03 Jul 2009 20:28:15 +0200 Laurent Bonnaud wrote:
> I was looking at this security issue:
> 
>   http://security-tracker.debian.net/tracker/CVE-2009-0935
> 
> and noticed that linux 2.6.30 is marked as vulnerable, whereas as fix
> has been applied to version 2.6.28.3:
> 
>   http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28.3
> 
> (commit 4b9e1bfac4c90ee6c67b8375dc3606ae08a5ffb8)
> 
> Could someone please fix this ?

thanks for spotting this.  i have just checked the 2.6.30 code in
unstable, and this patch has indeed been applied.  tracker updated.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Fri, 3 Jul 2009 22:52:35 +0200 Francesco Poli wrote:
>> the issue is not necessarily manpower itself, but rather the value of
>> volunteers' time.  it makes little sense to duplicate work for testing
>> and unstable when unstable will eventually overwrite testing.
>
> The same reasoning (on a larger scale) could be applied to stable and
> would lead to the conclusion that security updates make little sense,
> since a new stable release will eventually replace the current stable on
> end-users' boxes (e.g.: etch replaced sarge, lenny replaced etch, and
> so forth).
> 
> I am not convinced that this would be a reasonable conclusion...

this line of reasoning is a converse accident logical fallacy [1].
stable security support is not testing security support (they are both
separate special cases of a logical concept "security support"), so the
same rules/philosophy should not apply to both.

mike

[1] http://en.wikipedia.org/wiki/Converse_accident


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSA-1825-1 vs. tracker

[Michael S. Gilbert]

On Sat, 4 Jul 2009 16:34:56 +0200 Francesco Poli wrote:
> I think I found another little inconsistency between a DSA and the
> security tracker.
> 
> DSA-1825-1 [1] claims that CVE-2009-2288 is fixed in old stable by
> nagios2/2.6-2+etch3, the DSA tracker page [2] agrees, but the CVE
> tracker page [3] disagrees.

fixed.


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Sat, 4 Jul 2009 17:33:08 +0200 Francesco Poli wrote:
> I was going to file an RC bug against linux-2.6 for the following 7
> vulnerabilities that are fixed in testing, but not in unstable,
> according to the security tracker:
> 
> http://security-tracker.debian.net/tracker/CVE-2009-1758
> http://security-tracker.debian.net/tracker/CVE-2009-1633
> http://security-tracker.debian.net/tracker/CVE-2009-1630
> http://security-tracker.debian.net/tracker/CVE-2009-1338
> http://security-tracker.debian.net/tracker/CVE-2009-1242
> http://security-tracker.debian.net/tracker/CVE-2009-0835
> http://security-tracker.debian.net/tracker/CVE-2009-0834
> 
> However, while reviewing the CVE descriptions on http://cve.mitre.org/,
> I noticed that all of them seem to only affect Linux kernel upstream
> versions < 2.6.30.
> 
> Could someone check that linux-2.6/2.6.30-1 (currently in unstable) is
> really fixed w.r.t. to the above-mentioned CVEs and possibly update the
> security tracker to reflect reality?

this kind of triage would really help out the kernel-sec team, but i
don't think i'll be able to find the time to do it myself soon.  it
would be great if you could help out with this.  it should be fairly
straightforward:

1. download the debian kernel source package from unstable
2. find the relevant patch (this is the diff link on the git.kernel.org
page linked from the mitre CVE page)
3. compare patch to debian kernel source and make sure that it is
present
4. file RC bugs for unfixed issues and send a message with your findings

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: CVE-2009-1192 and 2.6.30 kernel

[Michael S. Gilbert]

On Thu, 02 Jul 2009 19:11:24 +0200, Laurent Bonnaud wrote:
> Hi,
> 
> I was looking at this security issue:
> 
> http://security-tracker.debian.net/tracker/CVE-2009-1192
> 
> and noticed that linux 2.6.30 is marked as vulnerable, whereas a patch
> exists:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59de2bebabc5027f93df999d59cc65df591c3e6e
> 
> and has been integrated into version 2.6.30:
> 
> http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30
> 
> Could somebody fix this ?

thanks for spotting this.  i've checked the 2.6.30 source, and this
patch is indeed applied, so i've updated the tracker with the
correct info.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Tue, 30 Jun 2009 01:12:44 +0200, Francesco Poli wrote:
> How can we make sure that those Debian patches, as long as they are
> still needed, are retained for new upstream versions, when they are
> packaged?

this is mostly a matter of trusting the maintainer to do the requisite
background work (applying patches from the old version if they are still
relevant) when preparing a new upstream version.  this isn't
policyified, but one would also hope that other maintainers/users are
reviewing the changes to make sure regressions don't happen.

> Moreover, how can we make sure that packages fixed in stable and
> testing, but not in unstable, get fixed in unstable too, before a new
> version migrates from unstable to testing?
> Maybe by filing appropriate RC bugs?

yes, if unstable is missing a security fix that is in the testing
or stable packages, then that is a regression, and a serious bug should
be filed.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Mon, 29 Jun 2009 20:14:59 +0200, Francesco Poli wrote:
> Great!
> Only
> 
> http://security-tracker.debian.net/tracker/CVE-2009-1392
> http://security-tracker.debian.net/tracker/CVE-2009-0146
> 
> seem to be unfixed, now.

should be fixed now.

> As far as sid is concerned, I think vulnerabilities should be marked as
> fixed too, as appropriate (or does this have bad consequences?):

yes these should be fixed, and i have done so.  there should be no
negative consequences as long as the maintainers make sure to retain the
debian patches for this when new upstream versions are brought in.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S Gilbert]

On 6/28/09, Francesco Poli wrote:
> BTW, since a point release was issued yesterday, I've just seen the
> stable-update --> testing,unstable migration happen for a number of
> packages (including linux-2.6).
> This caused a number of new "same versions, different status"
> inconsistencies in the tracker:

these should all be fixed now.  let me know if i missed anything.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Sun, 28 Jun 2009 18:48:17 +0200 Francesco Poli wrote:
> That's why I am trying to figure out how the manpower issue can be
> solved: because I would love to see DTSAs and all the full security
> support for Debian testing, even when it is apparently harder (i.e.:
> immediately after a release).

the issue is not necessarily manpower itself, but rather the value of
volunteers' time.  it makes little sense to duplicate work for testing
and unstable when unstable will eventually overwrite testing. 

because it is hard for any volunteer to justify doubling their work,
your best bet for better testing security support is to step up to the
plate yourself or to pay someone to do so for you.

> Indeed, but I don't see a "Do not use testing unless we are a few weeks
> from next release" warning.
> And I think that there should *not* be such a warning and that the
> reasons for such a warning should be fought and defeated by the Testing
> Security team.

testing is just too much of a moving target.  the track record for
full support is not a few weeks before release, but rather six months
or so, which is fairly significant chunk of time.  in the meantime a
recomendation to use stable seems a reasonable position to me.

> If users don't use Debian testing, no one will report bugs for packages
> in testing, and bugs won't be discovered until a new release is out,
> that is to say, until it's too late...

regardless of non-expedient security support, plenty of people use
testing and report issues.  in fact the majority of users do not base
any of their decisions on security; hence, this is an extreme
conclusion to draw.  besides, testing is indeed security-supported, it's
just slow.

> I think it should be done automatically at archive level.
> 
> An automatic stable-update --> testing,unstable migration mechanism is
> already in place for point releases, as stated by Nico Golde in
> http://lists.debian.org/debian-security-tracker/2009/06/msg9.html
> 
> A similar automatic stable-security --> testing-security migration
> mechanism should be implemented, IMHO.

even though there is an existing solution, my argument for it as the
only option is counter-productive; and i do not wish to say no just to
say no.  i would suggest talking to the ftp-masters and the security
team (t...@security.debian.org) about whether they would be interested
in implementing your idea.

> BTW, since a point release was issued yesterday, I've just seen the
> stable-update --> testing,unstable migration happen for a number of
> packages (including linux-2.6).
> This caused a number of new "same versions, different status"
> inconsistencies in the tracker:

started fixing these; will fix the rest tomorrow.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSA-182[34]-1 vs. tracker

[Michael S Gilbert]

On 6/26/09, Francesco Poli wrote:
> Hi all!
> I noticed a couple of tracker inconsistencies.
>
> DSA-1823-1 [1] claims that CVE-2009-1886 does not affect etch, squeeze
> or sid, and is fixed in lenny by samba/3.2.5-4lenny6. The tracker
> disagrees, as it claims that lenny (security) is still vulnerable [2]
>
> [1] http://lists.debian.org/debian-security-announce/2009/msg00135.html
> [2] http://security-tracker.debian.net/tracker/CVE-2009-1886
>
> DSA-1824-1 [3] claims that CVE-2009-1151 is fixed in etch by
> phpmyadmin/2.9.1.1-11, in lenny by 2.11.8.1-5+lenny1, and in
> squeeze/sid by 3.1.3.1-1. The tracker disagrees, as it claims that etch
> (security) and lenny (security) are still vulnerable [4].
>
> [3] http://lists.debian.org/debian-security-announce/2009/msg00136.html
> [4] http://security-tracker.debian.net/tracker/CVE-2009-1151
>
> Please fix these inconsistencies.

fixed!  thanks for spotting these.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Fri, 19 Jun 2009 13:36:37 -0400 Michael S Gilbert wrote:
> yes, you are on the right track, but since the security team is not
> supporting testing right now, they likely aren't looking much at the
> testing pages on the secure-testing website. maybe there needs to be a
> big warning, "NOT SECURITY SUPPORTED", added to the testing pages
> making it clear that this is the case.

since i chose poor wording for this paragraph, i feel the need to
clarify. of course testing is indeed supported by the security team
(and they do look at the testing pages); however, it is not the same
level of support as would be expected for stable. the big warning
should say something along the lines of "EXPECT LONG DELAYS FOR TESTING
SECURITY UPDATES: PLEASE DO NOT USE TESTING IF YOU ARE CONCERNED ABOUT
UNADRESSED SECURITY VULNERABILITIES AND WEAKNESSES".

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Sat, 20 Jun 2009 00:35:28 +0200 Francesco Poli wrote:
> You seem to say: "since testing is not officially supported, there's no
> reason to do *anything* that would improve its security".
> What's next step, then?  Intentionally introduce vulnerabilities into
> testing, since it's not officially supported anyway?!?   ;-)

not really what i was saying; my point is that security fixes will
automatically propagate from unstable, it just takes time -- but it will
happen. and since the security team's time is a scarce resource, it is
folly to duplicate effort on both testing and unstable when the changes
in unstable will shortly overwrite all the work previously done on
testing.

> You seem to reason as if security were an all-or-nothing,
> black-or-white thing.
> I think that there are several gray scales between an ideal 100 %
> secure system (which is unfortunately impossible to obtain in the real
> world) and a miserable (security) failure.
> As a consequence, I think that *anything* that could be done to push
> Debian testing in the direction of a more secure system, is worth doing.
> Even *some* DTSAs are better than *no* DTSAs.
> Even *some* efforts from the Testing Security team, are better than
> *nothing*.

time is scarce, and there is already a clear policy statement about
expectations for testing security.  see the "Limitations" section at
http://secure-testing-master.debian.net.

> Make no mistake, I am *not* saying that the Testing Security team is
> doing nothing.
> As I told in this same thread, I was happy to see a pair of DTSAs and I
> am pretty sure that many other actions are taken (in a less visible
> way) to make sure that important security-related fixes are applied to
> unstable and migrate from unstable to testing as fast as possible.
> This is *greatly* appreciated, especially if lack of manpower is taken
> into account!

right, DTSAs are happening at a low-level, which is at least something
(and will likely continue at a similar rate until the squeeze freeze).
however, a better user-side policy is to not use testing if you are
concerned about full security support because that is not happening
(and does not need to happen) so far away from a release. maybe
something like this should be issued as an official statement from the
secure-testing team?

> I just think that the goal of the Debian Testing Security team should
> be to officially support Debian testing *always*, and not only for a
> few months before a stable release.

again, time is scarce, and this is not necessarily the best use of
manpower.

> That's why I was wondering what could be done to improve the situation:
> a new call for help perhaps, 

even if there were more help (which i'm sure would be appreciated), it
would likely be directed toward stable and unstable since it makes
little sense to duplicate effort.

> and, at the same time, an automatic
> mechanism to re-use some DSAs as DTSAs which would be useful,
> especially early after a stable release, i.e. when it is apparently
> more difficult to provide good Debian testing security support...

like i've already described, there is an existing solution.  maybe it
needs to be more user-friendly and documented, but it's available now.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Fri, 19 Jun 2009 20:17:18 +0200, Francesco Poli wrote:
> I am aware of this distinction, I just considered the start of (more or
> less) regular DTSA publishing as a sign of Debian Testing Security team
> activity on the testing suite.
> 
> Having a (more or less regular) DTSA flow is certainly not enough to
> claim that Debian testing is officially supported security-wise, but
> it's certainly better than not even having DTSAs...  ;-)

agreed, but it may be more useful to actually look at flow (e.g.
DTSAs/month over similar time frames). however, is there any reason to
issue DTSAs when testing is not officially security-supported anyway?
it seems like more work than necessary, especially since eventually the
fixed unstable packages will transition into testing automatically
(without any effort on anyone's part).

this may just be a natural change in workflow based on past experience.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S Gilbert]

On 6/14/09, Francesco Poli wrote:
> The security tracker is not useful to assess the security of a
> particular box, but I think it's (or it should be) useful as a sort of
> (auxiliary) to-do list for the security teams, telling which
> vulnerabilities should be addressed with the greatest urgency and which
> vulnerabilities are already fixed.
> Or am I completely off-track?

yes, you are on the right track, but since the security team is not
supporting testing right now, they likely aren't looking much at the
testing pages on the secure-testing website. maybe there needs to be a
big warning, "NOT SECURITY SUPPORTED", added to the testing pages
making it clear that this is the case.

> Debian sarge was released in June 2005.
> I remember seeing the first DTSAs for etch in September 2005, if not
> before (OK, that could not be considered as full security support for
> testing, but it was better than nothing).
>
> Debian etch was released in April 2007.
> I remember seeing the first DTSA for lenny in May 2007.
>
> Debian lenny was released in February 2009.
> As of now (June 2009), I still have to see the first DTSA for squeeze.
>
> It seems to me that things are going worse for squeeze than for lenny...
> There's lack of manpower, I know: but was there more manpower while
> lenny was testing and etch was stable?

the security team will push out DTSAs as they find the time
(especially for latently vulnerable issues in ill-maintained
packages), but that does not indicate the initiation of security
support for that release.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Wed, 10 Jun 2009 20:22:39 +0200, Francesco Poli wrote:
> > the best course of action here is to use stable-security with a higher
> > pin-priority than testing;
> 
> I think it would work correctly with the *same* pin-priority as used
> for testing and testing-security.

agreed.  i didn't fully think through the implications because i've
never thought about this sort of configuration before.

> > of course this is a less-than-desirable situation because most users
> > won't go through the trouble.
> 
> I think this solution could be viable, but should be considered
> sub-optimal, as it would require suggesting all (Debian testing)
> end-users to modify their sources.list.

or if the testing installer does it, then it is automatic.

> Moreover, the security-tracker would not be aware of this possibility
> and would thus go on considering those vulnerabilities as unfixed for
> testing.

the web tracker shouldn't be the definitive source for the security of
your particular configuration.  use debsecan.  it takes into account the
specific versions of the packages you have installed.

> On the other hand, my proposed automatic stable-security ->
> testing-security migration mechanism would fix a number of
> vulnerabilities (especially in the first post-release times) for all
> Debian testing end-users, in a "gratuitous" manner (from a Debian
> Testing Security team point of view, since it would re-use the Debian
> Stable Security team effort).

if you are interested in this feature, then by all means, volunteer
and implement it.  if you are interested in assisting the security
team, then they will be happy to have you help; regardless of whether
or not you don't exactly meet the qualifications.  everyone can learn.

however, i think that the feature is here now (via stable-security), and
i personally don't see the need to implement this harder solution
(especially since testing is not currently considered security
supported anyway).

based on the track record for lenny, you can probably expect full
testing security support sometime within 6 months to a year before
squeeze's release (i.e. around 18 months after lenny's release or over a
year from now).

in the meantime, if you are interested in security support, you should
stick with stable.  if you are interested in low numbers of security
issues, but not necessarily guaranteed security support, then unstable
is also a reasonable option; and to be honest, it doesn't break much any
more since most potentially dangerous updates are staged in experimental
beforehand.

in my case, i run stable on raw metal, and i run unstable inside of a
virtual machine (kvm) to get access to the latest versions of
applications if i so desire; while concurrently minimizing lossage due
to breakage (i could also set up snapshots just in case, but i haven't
had the need yet). i'm fairly pleased with this set up.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Wed, 10 Jun 2009 00:47:08 +0200, Francesco Poli wrote:
> > this would be nice, but it is usually a short timeframe for which there
> > exist testing and stable versions that match.  i think it will
> > always have to be a manual process involving DTSAs.
> 
> Short time frame?
> I still see cases where squeeze and lenny versions of a package are
> identical and lenny was released back on February 14th...

relative to the 2 year release cycle, 4 months is a short time frame
(although i see your point since some packages remain almost unchanged
between releases, but they are few and far between).

> I think the above-described automatic mechanism would benefit testing
> security, especially in the first post-release times, i.e. when the
> testing-security team claims that no official testing security support
> can be provided!

the best course of action here is to use stable-security with a higher
pin-priority than testing; that way if testing still contains the
same version as stable, then you get the securitized version from
stable-security instead.

of course this is a less-than-desirable situation because most users
won't go through the trouble.  however, the security team is already
overtaxed, and stable security is much more important than testing so
far away from a release.

maybe the installer could automatically configure testing's sources.list
as described above to partially address the problem.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Tue, 9 Jun 2009 00:12:18 +0200, Francesco Poli wrote:
> Thank you: this one seems to have been left over
> http://security-tracker.debian.net/tracker/CVE-2009-0787

fixed.

> Ah, I thought this stable-security -> testing-security migration was
> already implemented.
> Maybe having this feature could be useful!
> What do others think?

i think it would be good from a user's perspective, but from a "testing
the release perspective," i think that the testing kernel should be
the one proposed for inclusion in the next stable release.

maybe a good compromise would be to use stable-security until the
stable+1 kernel version is decided, then migrate that from unstable.

> BTW, when will testing security support start again?
> Back on February, I was told to wait for some 2 months...
> http://lists.debian.org/debian-security-tracker/2009/02/msg00011.html

i don't know.  can anyone else comment on this?

> I think this should happen automatically.
> 
> This is a good reason to implement an automatic stable-security ->
> testing-security migration mechanism, that is triggered whenever the
> package version in testing (and the package version in
> testing-security, if any) is older than the stable-security one,
> as suggested above.

this would be nice, but it is usually a short timeframe for which there
exist testing and stable versions that match.  i think it will
always have to be a manual process involving DTSAs.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: stable vs. testing: same versions, different status

[Michael S. Gilbert]

On Mon, 1 Jun 2009 17:54:39 +0200, Francesco Poli wrote:
> There are vulnerabilities in the tracker that show up as fixed in
> lenny, and as unfixed in squeeze, despite the package version is the
> *same* in the two suites.

fixed.  for some reason the stable kernel 2.6.26-15 migrated from
stable to testing, which led to these tracking issues.  it is usually
the exact opposite (the testing kernel gets migrated from unstable).

> Moreover, it is my understanding that a security update for stable is
> automatically used for testing too, whenever testing does not have any
> newer version of the package.

this is never the case.  2.6.26-15lenny3 from stable-security has and
will not migrate to testing, so these issues are still present in
squeeze.

if you are running testing at this point, you should probably be using
the kernel from stable-security to make sure you are protected against
the latest known vulnerabilities.

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

[Michael S. Gilbert]

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: [SECURITY] [DSA 1792-1] New drupal6 packages fix multiple vulnerabilities

[Michael S. Gilbert]

On Sat, 09 May 2009 17:55:48 +0200 Florian Weimer wrote:
> 
> 
> There's even a follow-up which mentions FIXED-BY for unnamed issues.

this seems like a very good idea, and could be implemented
imediately with NOTEs (and without requiring any code changes).

> When an issue is assigned a CVE, I suggest to add it after the CVE
> name, preceded by a slash:
> 
> CVE-2009-1572/70212 (The BGP daemon (bgpd) in Quagga 0.99.11 and earlier 
> allows remote ...)
> 
> Before that, the entry would have looked like this:
> 
> DVN-70212 [quagga: bgpd crash with AS paths containing 32-bit ASNs]

this is a great idea and would be even better than FIXED-BY.  it seems
like a more rigorous solution. i would suggest keeping the full DVN
name for completeness-sake (maybe reorder to illustrate that the DVN
came before the CVE):

  DVN-70212/CVE-2009-1572 (The BGP daemon (bgpd) in Quagga 0.99.11 ...

also, would it make sense to associate all CVEs with DVNs (a longer
identifier may be required since there are already almost 40,000 CVEs
already in the list)?  perhaps this could be automatically added by the
update scripts?

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSA vs tracker: is CVE-2008-5814 fixed in unstable?

[Michael S. Gilbert]

On Sat, 9 May 2009 17:31:11 +0200 Francesco Poli wrote:
> Hi everyone!
> 
> DSA-1789-1 [1] claims that all the mentioned CVEs are fixed in
> php5/5.2.9.dfsg.1-1 for sid.
> All tracker pages for the mentioned CVEs seem to be consistent, except
> for the one for CVE-2008-5814 [2], which claims that sid is still
> vulnerable.
> 
> [1] http://lists.debian.org/debian-security-announce/2009/msg00100.html
> [2] http://security-tracker.debian.net/tracker/CVE-2008-5814
> 
> Now the question is: is CVE-2008-5814 really fixed in
> php5/5.2.9.dfsg.1-1 ?
> If this is case, the tracker seems to be inconsistent.
> 
> Please clarify and/or fix the inconsistency.

hi,

thanks for pointing out the inconsistency.  this is not yet fixed in
the sid version.  it has been added to the sid php5 git repo and is
currently pending to be uploaded, but has not happened yet.  in fact
CVE-2009-0754 should have the same status; which i've just fixed.

security team,

should the DSA announcement be reissued to correct/clarify?

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

inconsistencies in oldstable synopsis on tracker pages

[Michael S. Gilbert]

hello,

the oldstable synopsis on the security tracker pages is often inconsistent.
for example in [1],  the oldstable synopsis says:

Debian/oldstablepackages php4, php5 are vulnerable

whereas the stable synopsis says:

Debian/stable   package php5 is fixed in stable-security

even though there was a DSA issued that fixed those issues in oldstable.  note 
that the package information displayed in the later portions of that page make 
it clear that oldstable is safe.  i think that the oldstable synopsis should 
say:

Debian/oldstablepackages php4, php5 are fixed in oldstable-security

if you can point me to the code that generates this info, i can look at making 
the necessary changes.

mike

[1] http://security-tracker.debian.net/tracker/CVE-2008-5814


-- 
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

[Michael S. Gilbert]

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: [SECURITY] [DSA 1792-1] New drupal6 packages fix multiple vulnerabilities

[Michael S. Gilbert]

On Wed, 06 May 2009 20:36:24 +0200, Florian Weimer wrote:
> * Michael S. Gilbert:
> 
> > is there any way to do a better job of tracking these non-CVEified
> > issues? for example, there is currently no tracking information for
> > unstable in the CVE list for either of these issues; and no way to
> > link between the CVE and DSA lists for those issues since the automatic
> > scripts will remove those links.
> 
> I had proposed a FIXED-BY: directive some time ago to deal with this
> situation, but it was considered unnecessary at the time.

interesting.  i apologize for missing this, but how would FIXED-BY work?
a link to the previous discussion would very helpful.

> > a quick solution would be to change the way non-CVE issues are named in
> > the CVE list.  for example, use CVE-2009-- and so on so that
> > each non-numbered issue is unique (where  starts at 0001 and gets
> > incremented for each new unique non-numbered issue).
>
> We shouldn't call this CVE, but DVN ("Debian Vulnerability Name") or
> something else.  

this does make more sense, and its shorter.  

> This would be more difficult to implement in the tracker than FIXED-BY:.

wouldn't it just be a matter of converting the CVE-2009- handling
to use DVN-2009-0001, etc. instead?  i'd imagine that for the most part
the CVE name is usually just treated as a string, except for the
conversion to TEMP number; although i'm not familiar with the web
scripts so i could be very wrong.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [SECURITY] [DSA 1792-1] New drupal6 packages fix multiple vulnerabilities

[Michael S. Gilbert]

On Wed, 06 May 2009 15:54:22 +, Noah Meyerhans wrote:
> Package: drupal6
> Vulnerability  : multiple
> Problem type   : remote
> Debian-specific: no
> Debian Bug : 526378
> 
> Multiple vulnerabilities have been discovered in drupal, a web content
> management system.
...

...

...

hello all,

is there any way to do a better job of tracking these non-CVEified
issues? for example, there is currently no tracking information for
unstable in the CVE list for either of these issues; and no way to
link between the CVE and DSA lists for those issues since the automatic
scripts will remove those links.

a quick solution would be to change the way non-CVE issues are named in
the CVE list.  for example, use CVE-2009-- and so on so that
each non-numbered issue is unique (where  starts at 0001 and gets
incremented for each new unique non-numbered issue).  this makes it
possible to link between the CVE and DSA lists for non-numbered
issues.  also, when at some point those issues do get CVE numbers, it
will be easy to go in and make the appropriate changes when since you
can just do a search for 2009--.

maybe someone should also write a script. that generates the next 
to make it less likely to duplicate the .

well, let me know what you think.  it may even be possible to start
doing this now; without any modifications to the scripts (although it
may throw of the security tracker TEMP number generator).

also, don't we have a responsibility to get all of our issues CVEified
so that other distros aren't left vulnerable due to unawareness?

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

bug numbers for not-affected issues

[Michael S. Gilbert]

hello all,

what is the correct way to track not-affected issues so that they stay
connected to the bug number in the security tracker?  once i changed the
ntop issue to not-affected, it got disconnected from the bug number.
see [1].

thanks,
mike

[1] http://security-tracker.debian.net/tracker/TEMP-000-000336


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: No tracker pages for DSA-178[34]-1

[Michael S. Gilbert]

On Sat, 2 May 2009 23:54:15 +0200 Francesco Poli wrote:
> On Thu, 30 Apr 2009 23:58:55 +0200 Francesco Poli wrote:
> 
> > Hi all!
> > 
> > DSA-1783-1 and DSA-1784-1 were issued yesterday and today, respectively.
> > No tracker page has been created for them, yet.
> > Maybe something went wrong with the automatic update...
> > 
> > Please fix that "something"!   ;-)
> 
> Now there are 5 DSAs with missing tracker page (DSA-1783-1 through
> DSA-1787-1)...
> Anyone willing to reactivate the automatic update?

does anyone have any idea what's been going on here?  and any ideas on
how to fix it?


-- 
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

[Michael S. Gilbert]

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: DSA-1771-1 vs. tracker

[Michael S. Gilbert]

On Fri, 17 Apr 2009 22:14:24 +0200 Francesco Poli wrote:

> Hi everyone,
> DSA-1771-1 [1] was issued back on Wednesday, and the corresponding
> tracker page [2] was created.
> 
> I think there are a few inconsistencies, though.
> 
> The DSA refers to two CVEs [3][4] and to one further vulnerability
> with no CVE number yet.
> The DSA tracker page [2] only refers to the two CVEs.
> I think it would be useful to mark the CVE-less vulnerability as fixed,
> as well, maybe by referring to a TEMP, which will later be converted
> into a CVE...

there are some issues with the tracker update scripts where the DSA
links are being removed from non-numbered CVEs.  this has yet to be
addressed (i.e. the script needs to be made to be more intelligent about
this type of case).  i'll see if i can find the time to work on it.

> Moreover, the DSA says that the two CVEs are fixed
>  * for etch  in version 0.90.1dfsg-4etch19
>  * for lenny in version 0.94.dfsg.2-1lenny2
>  * for sid   in version 0.95.1+dfsg-1
> On the other hand, the CVE tracker pages [3][4] also claim
> that squeeze is fixed, even though it still has version 0.94.dfsg.2-1.
> Is this good news, or just a mistake on the tracker?

the data was misentered in the tracker.  fixed.


-- 
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

[Michael S. Gilbert]

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

[Michael S. Gilbert]

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 packag

Re: [Secure-testing-commits] r11636 - data/CVE

[Michael S. Gilbert]

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

[Michael S. Gilbert]

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

[Michael S. Gilbert]

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 ...)

Re: Submitting multiple CVEs in the same bug report

[Michael S. Gilbert]

On Fri, 10 Apr 2009 18:15:06 +0200
sean finney  wrote:

> hi guys,
> 
> On Fri, Apr 10, 2009 at 02:27:46PM +0200, Nico Golde wrote:
> > > I ask because I recently submitted a bug on php5 and got pushback from
> > > the maintainer saying that I should not have submitted multiple
> > > vulnerabilites in one report [1].
> > 
> > I CCed seanius to this as he was the one who said that. In 
> > general there is no consensus about that but just some 
> > maintainers prefer that.
> 
> i think it's probably a preference thing.  however, with php it's a
> very strong preference on my part to have multiple reports:
> 
>  * often the CVE's themselves are "multiple vulnerabilities", so it's
>already kinda hard to track this.
>  * often the CVE's are of wildly different severity
>  * sometimes we neglect to immediatley fix some of the lower severity
>CVE's while closing others.
> 
> > I personally agree with you, it makes our job a lot easier 
> > and the maintainer always has the ability to clone and 
> > retitle bugs. However there are some cases in which I 
> > refrain from reporting one big report. In case you can 
> > subdivide the vulnerabilities in parts which logically fit 
> > in the same category I think it makes more sense to split 
> > them instead of reporting one huge grave bug.
> 
> what's the overhead on the security team's side for this,
> out of curiosity?  if it's just the reporting process, maybe
> some kind of CVE-fetching wrapper script could trim that down?

There isn't a whole lot of overhead (sending multiple emails and
entering multiple different bugs into the tracker instead of just one).
There is also the logistical matter of keeping track of the maintainers
that prefer one or the other way. Also, we get a whole chunk of CVEs at
a time and it's easier to deal with them in bulk.

I'm going to add some wording the the security introduction, and I'll
make a note that per-CVE reports are preferred for php.

Mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Submitting multiple CVEs in the same bug report

[Michael S. Gilbert]

Hello,

What is the modus operandi for submitting multiple CVEs in the same bug
report?

I ask because I recently submitted a bug on php5 and got pushback from
the maintainer saying that I should not have submitted multiple
vulnerabilites in one report [1].

>From my perspective, being able to submit multiple vulns makes the job
of the security team (and assistants) much easier and straightforward.
And if the maintainer prefers to track vulnerabilities individually,
then they always have the option to do so at their own leisure (via
cloning).

It may be useful to state this as the common practice/policy in the
security-tracker overview doc.  If there are no objections, I will
modify the wording to include such a statement.

Thanks,
Mike

[1] http://bugs.debian.org/523028


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSAs really missing from the tracker

[Michael S. Gilbert]

On Thu, 2 Apr 2009 10:59:10 +0200, Thijs Kinkhorst wrote:

> On Wed, April 1, 2009 22:00, Michael S. Gilbert wrote:
> > Even though it's not always daily, this is still a significant
> > improvement over previous years, in which updates would occur once a week
> > or less. For the CVE data updates, our security processes require manual
> > steps as part of a defense-in-depth strategy.
> >
> > it looks like they have no intention of keeping their databases in sync
> > with NVD.  for me, this is strong evidence that a switch to NVD is
> > necessary.
> 
> Yes, this is a known item. I'm fairly certain that we already received
> patches from, I think, Gentoo to our scripts to use NVD. Check out the
> archives of this list and the secure-testing list to find them; I cannot
> do a search for them now but could perhaps find some time tonight to
> retrieve it.

i found the NVD scripts in secure-testing's svn, and they run, but
i haven't checked whether they actually do what we expect.  i will
modify if need be. i will also need to tie these in to the updater,
which should be fairly straightforward.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSAs really missing from the tracker

[Michael S. Gilbert]

On Wed, 1 Apr 2009, Michael S. Gilbert wrote:
> like i said, this gets pulled in automatically from the Mitre database,
> and there really isn't anything debian can do about their tardiness.

fyi, i asked the following question to Mitre:

  The CVE pages and feeds on Mitre's site are very tardy.  They get
  updated days to weeks behind the NVD pages.  Are there any plans to
  improve the timeliness of these updates?

and got the following response:

  Hello,

  Lately, we have been updating the CVE web site about 3 times per week.
  There have been one or two situations where the delay between updates
  has been about once a week, but I think it's fairly rare.  I hope this
  correlates with your experience.

  Even though it's not always daily, this is still a significant
  improvement over previous years, in which updates would occur once a
  week or less. For the CVE data updates, our security processes require
  manual steps as part of a defense-in-depth strategy.

it looks like they have no intention of keeping their databases in sync
with NVD.  for me, this is strong evidence that a switch to NVD is
necessary.

Joey, if you send me the existing Mitre scripts, I will take a look at
modifying them for NVD.

mike


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSAs really missing from the tracker

[Michael S. Gilbert]

On Wed, 1 Apr 2009 20:03:18 +0200, Francesco Poli wrote:
> I can confirm that DSA-1755-1 now seems to be correctly tracked (except
> for etch status: the DSA claims that etch is not affected, but the
> tracker says that etch is vulnerable...).

fixed.

> On the other hand, DSA-1758-1 refers to a CVE still marked as RESERVED
> and hence reports incomplete information about vulnerable and fixed
> versions.

like i said, this gets pulled in automatically from the Mitre database,
and there really isn't anything debian can do about their tardiness.

should debian switch to the NVD feeds [1], which seem to get updated in
a much more timely and consistent manner?  from what i've seen, NVD
pages and feeds actually get updated on the planned disclosure date,
rather than a week or more later for Mitre.

appropos, this has been a primary complaint of mine for a while now.  it
takes debian much too long to start working on issues after they have
been initially disclosed.  switching to NVD would go a long way toward
addressing this problem.

[1] http://nvd.nist.gov/download.cfm#CVE_FEED


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSAs really missing from the tracker

[Michael S. Gilbert]

On Mon, 30 Mar 2009 23:46:10 +0200, Francesco Poli wrote:

> Hi.
> 
> DSA-1756-1 and DSA-1757-1 have been recently issued, but no
> corresponding tracker page is present yet.
> What happened to the automatic creation of DSA tracker pages?

this is a good question.  what triggers generation of these pages?  i
noticed that the DSAs that i just added did not get tracker pages
automatically (for example,
http://security-tracker.debian.net/tracker/DSA-1605).

> Moreover, DSA-1755-1 was issued some days ago, explaining
> CVE-2009-0784, which is however still marked as RESERVED on the
> tracker: I cannot understand what's reserved about something that has
> already been disclosed in a DSA...

CVE descriptions are pulled in automatically from the mitre database.
there can be a delay between disclosure and when they do their updates,
which causes issues such as seen here. regardless, this can be updated
manually, and i will do so.


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: missing DSAs

[Michael S. Gilbert]

On Mon, 30 Mar 2009 15:10:07 -0400, Michael S. Gilbert wrote:
> from what i can gather, this is the first time (ever) that a DSA has
> been issued without including a set of fixed packages, so there is no
> precedent...yet.

i did a little more work and found that dsa-1529, dsa-1604, and
dsa-1605 were also just advisories (they did not include new packages).  
they are also not included in the tracker, just like dsa-1753.

dsa-1529 was an issue in the firebird database that was too complex to backport 
dsa-1604, and dsa-1605 were the recent bind issues that were not backportable 
to bind8 and glibc
  - note that dsa-1605 says "This DSA will be updated when patches for 
hardening 
the stub resolver are available", but this has not happened.  are there any 
plans to do so?

since i am doing security research, i would really like to see these included 
in the
tracker so i can make use of the debian tracking system, rather than coming up 
with my
own special solution just for these issues.

maybe there should be a special tag called "" or something like that?

i can go ahead and add the info myself if no one objects.

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: missing DSAs

[Michael S. Gilbert]

On Mon, 30 Mar 2009 20:07:08 +0200, Thijs Kinkhorst wrote:
> I don't think we've encountered this misimpression in past occurances, so I 
> don't think such a solution would solve a real problem.

from what i can gather, this is the first time (ever) that a DSA has
been issued without including a set of fixed packages, so there is no
precedent...yet.

regardless, i think that the information in the tracker should be as
complete as possible.  if a DSA has been issued, it should be tracked.


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: missing DSAs

[Michael S. Gilbert]

On Mon, 30 Mar 2009 19:04:10 +0200, Thijs Kinkhorst wrote:
> > there are a couple DSAs missing from the security tracker. 
> 
> > DSA-1753 is 
> > the end of life for iceweasel, should any kind of note be made for
> > that in the tracker?
> 
> I don't think so, as there are no issues that entry would mark as fixed it 
> would add no information.
> 
> > also, DSA-1754 is completely missing.  is that a 
> > problem, or is something still in preparation?
> 
> It's in preparation, see:
> http://www.debian.org/security/faq#missing

thanks for the info.   missing info could give people the impression
that something is awry.  maybe some sort of note should be added.  for
example:

  [23 Mar 2009] DSA-1753-1 iceweasel - end of security support in etch
  NOTE: no package upload
  NOTE: DSA issued as an end of security support notice for iceweasel in 
etch

regards,
mike


--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

missing DSAs

[Michael S. Gilbert]

there are a couple DSAs missing from the security tracker.  DSA-1753 is
the end of life for iceweasel, should any kind of note be made for
that in the tracker?  also, DSA-1754 is completely missing.  is that a
problem, or is something still in preparation?


-- 
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Severity of application launcher issues

[Michael S. Gilbert]

I submitted the recent application launcher issues into the tracker with
medium urgency, and the severity was subsequently reduced to low.  I
had followed the categorization guidelines [1], and medium seemed like
a better fit since malicious code execution is possible with user
interaction:

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.

Just curious about the logic so I can better categorize issues in the
future.

Best Regards,
Mike

[1]
http://svn.debian.org/wsvn/secure-testing/doc/narrative_introduction?op=file&rev=0&sc=0


--
To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org