Hi all, FYI: Debian has assigned three CVE ids for three vulnerabilities present in all released versions (except for 1.0.1, which was released together with the patches). See: http://www.openttd.org/en/news/126 http://security.openttd.org/en/CVE-2010-0401 http://security.openttd.org/en/CVE-2010-0402 http://security.openttd.org/en/CVE-2010-0406 Gr. Matthijs
Hi, While working on an update for lxr the following commit by upstream that fixes an XSS vulnerability in the search page was found: > Fix XSS exploit in title string http://lxr.cvs.sourceforge.net/viewvc/lxr/lxr/lib/LXR/Common.pm?r1=1.63&r2=1.64 It does not seem to be covered by CVE-2009-4497. Please assign an id. Thanks in advance. Kind regards, -- -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net
I discovered and reported this bug at the same time as two other XSS issues, including the one covered by CVE-2009-4497. While the commit may be a few days apart for some of these, I think they can safely fall under the same CVE, unless it's standard practice to assign CVEs for each of several related minor issues. The description at cve.mitre.org covers an XSS bug in the "ident" parameter. It does not mention a second XSS bug which was also fixed in the search body, which is separate from a third bug, the search title, fixed here. -Dan On Mon, May 3, 2010 at 2:24 AM, Raphael Geissert <geissert@...> wrote: > Hi, > > While working on an update for lxr the following commit by upstream that > fixes an XSS vulnerability in the search page was found: > >> Fix XSS exploit in title string > http://lxr.cvs.sourceforge.net/viewvc/lxr/lxr/lib/LXR/Common.pm?r1=1.63&r2=1.64 > > It does not seem to be covered by CVE-2009-4497. > > Please assign an id. Thanks in advance. > > Kind regards, > -- > Raphael Geissert - Debian Developer > www.debian.org - get.debian.net(Continue reading)
On Mon, 3 May 2010 09:31:16 -0400 Dan Rosenberg <dan.j.rosenberg@...> wrote: > I discovered and reported this bug at the same time as two other XSS > issues, including the one covered by CVE-2009-4497. While the commit > may be a few days apart for some of these, I think they can safely > fall under the same CVE, unless it's standard practice to assign CVEs > for each of several related minor issues. Several XSS-vulnerabilities can have one CVE at least when those vulnerabilities are fixed at the same time. Can someone verify what is the policy by the book? --- Henri Salo
----- "Henri Salo" <henri@...> wrote: > On Mon, 3 May 2010 09:31:16 -0400 > Dan Rosenberg <dan.j.rosenberg@...> wrote: > > > I discovered and reported this bug at the same time as two other XSS > > issues, including the one covered by CVE-2009-4497. While the commit > > may be a few days apart for some of these, I think they can safely fall > > under the same CVE, unless it's standard practice to assign CVEs for > > each of several related minor issues. > > Several XSS-vulnerabilities can have one CVE at least when those > vulnerabilities are fixed at the same time. > In this instance, I would assign it a new ID, as the old one already exists and doesn't note both XSS fixes (it is possible someone fixed just the one XSS and not both in an update). I've CC'd Steve Christey, for a second opinion. Thanks -- -- JB
On Mon, 3 May 2010 13:34:05 -0400 (EDT) Josh Bressers <bressers@...> wrote: > ----- "Henri Salo" <henri@...> wrote: > > > On Mon, 3 May 2010 09:31:16 -0400 > > Dan Rosenberg <dan.j.rosenberg@...> wrote: > > > > > I discovered and reported this bug at the same time as two other > > > XSS issues, including the one covered by CVE-2009-4497. While > > > the commit may be a few days apart for some of these, I think > > > they can safely fall under the same CVE, unless it's standard > > > practice to assign CVEs for each of several related minor issues. > > > > Several XSS-vulnerabilities can have one CVE at least when those > > vulnerabilities are fixed at the same time. > > > > In this instance, I would assign it a new ID, as the old one already > exists and doesn't note both XSS fixes (it is possible someone fixed > just the one XSS and not both in an update). > > I've CC'd Steve Christey, for a second opinion. > > Thanks My sentence was for normal cases. I have seen several reports with multiple XSS-vulnerabilities. This usually is the case when someone audits web-applications.(Continue reading)
----- "Raphael Geissert" <geissert@...> wrote: > Hi, > > While working on an update for lxr the following commit by upstream > that > fixes an XSS vulnerability in the search page was found: > > > Fix XSS exploit in title string > http://lxr.cvs.sourceforge.net/viewvc/lxr/lxr/lib/LXR/Common.pm?r1=1.63&r2=1.64 > > It does not seem to be covered by CVE-2009-4497. > > Please assign an id. Thanks in advance. > Please use CVE-2010-1448 for this. Thanks. -- -- JB
Just to clarify, two XSS bugs were fixed with a single release (new version 0.9.8), and then ten days later, an update was included to resolve a third XSS bug. The original CVE was originally requested for "multiple XSS vulnerabilities", but the description only covers one of them. -Dan On Mon, May 3, 2010 at 1:49 PM, Henri Salo <henri@...> wrote: > On Mon, 3 May 2010 13:34:05 -0400 (EDT) > Josh Bressers <bressers@...> wrote: > >> ----- "Henri Salo" <henri@...> wrote: >> >> > On Mon, 3 May 2010 09:31:16 -0400 >> > Dan Rosenberg <dan.j.rosenberg@...> wrote: >> > >> > > I discovered and reported this bug at the same time as two other >> > > XSS issues, including the one covered by CVE-2009-4497. While >> > > the commit may be a few days apart for some of these, I think >> > > they can safely fall under the same CVE, unless it's standard >> > > practice to assign CVEs for each of several related minor issues. >> > >> > Several XSS-vulnerabilities can have one CVE at least when those >> > vulnerabilities are fixed at the same time. >> > >> >> In this instance, I would assign it a new ID, as the old one already >> exists and doesn't note both XSS fixes (it is possible someone fixed >> just the one XSS and not both in an update).(Continue reading)
On Wed, Feb 24, 2010 at 08:41:01AM +0800, Eugene Teo wrote: > http://marc.info/?l=linux-sparc&m=126662196902830&w=2 > http://marc.info/?l=linux-sparc&m=126662159602378&w=2 > > sparc64: Fix sun4u execute bit check in TSB I-TLB load. > > TSB I-tlb load code tries to use andcc to check the _PAGE_EXEC_4U bit, > but that's bit 12 so it gets sign extended all the way up to bit 63 > and the test nearly always passes as a result. > > Use sethi to fix the bug. > > I'm not requesting a CVE for this as this does not affect any of our > kernels. But just a heads-up for those not aware of this. hey Steven, Can we get a CVE allocated for this one? -- -- dann frazier
Please use CVE-2010-1451
Thanks.
--
JB
----- "dann frazier" <dannf@...> wrote:
> On Wed, Feb 24, 2010 at 08:41:01AM +0800, Eugene Teo wrote:
> > http://marc.info/?l=linux-sparc&m=126662196902830&w=2
> > http://marc.info/?l=linux-sparc&m=126662159602378&w=2
> >
> > sparc64: Fix sun4u execute bit check in TSB I-TLB load.
> >
> > TSB I-tlb load code tries to use andcc to check the _PAGE_EXEC_4U
> bit,
> > but that's bit 12 so it gets sign extended all the way up to bit 63
> > and the test nearly always passes as a result.
> >
> > Use sethi to fix the bug.
> >
> > I'm not requesting a CVE for this as this does not affect any of our
>
> > kernels. But just a heads-up for those not aware of this.
>
> hey Steven,
> Can we get a CVE allocated for this one?
>
> --
(Continue reading)
RSS Feed159 | |
|---|---|
244 | |
237 | |
322 | |
214 | |
157 | |
186 | |
185 | |
232 | |
207 | |
150 | |
127 | |
235 | |
209 | |
292 | |
188 | |
333 | |
144 | |
239 | |
204 | |
133 | |
162 | |
258 | |
224 | |
155 | |
354 | |
319 | |
168 | |
149 | |
136 | |
187 | |
84 | |
175 | |
137 | |
117 | |
141 | |
115 | |
118 | |
122 | |
94 | |
72 | |
74 | |
105 | |
122 | |
102 | |
98 | |
84 | |
59 | |
96 | |
114 | |
75 | |
81 | |
89 | |
108 | |
127 | |
123 | |
127 | |
126 | |
149 | |
112 | |
136 | |
143 | |
103 | |
103 |
