Coverity scanned X.org code and reported a few bugs, one of which has serious security consequences (local privilege escalation). This is (confidential) X.Org bug #6213 Proposed embargo date set to April 6th.
Created attachment 81903 [details, diff] CVE-2006-0745.diff Patch demonstrating the issue.
Setting status
Ccing maintainer. Donnie, this is very confidential and will stay that way until April 6th. We should prepare packages outside of portage (attch ebuilds to this bug) so that arch security liaisons can test them and be ready for the release date.
(In reply to comment #3) > Ccing maintainer. > Donnie, this is very confidential and will stay that way until April 6th. We > should prepare packages outside of portage (attch ebuilds to this bug) so that > arch security liaisons can test them and be ready for the release date. Damn, this means I have to touch the monolith again. You don't need to tell me it's confidential. Mind if I add josh_b to CC?
Well, if you *really* need him, add him. But keep in mind that security team will come and kill you and him if this gets leaked.
OK, rain on my parade. I'll just tell him there's a security issue coming up and withhold the details.
OK, just learned that the date was moved forward to next Monday (Mar. 20). As a result, I'll try to get ebuilds up by tomorrow or so.
The affected code has never been in Gentoo outside of package.mask, as it was introduced in the 6.8.99 series and modular X is also still masked. Do you still want a GLSA for it?
If it the affected package has never been stable we don't normally issue GLSAs.
Created attachment 82269 [details, diff] xorg-server-1.0.1-CVE-2006-0745.patch
Created attachment 82270 [details] xorg-server-1.0.1-r5.ebuild
Note that this won't actually be added to the portage tree, because we're expecting a new upstream release. But it should be sufficient for testing the patch under modular X. I'll also add 6.9.0 for those 6.8.99.x users, but I'm not going to post it on this bug.
When this bug goes public. Can you add the new version and remove all old (vuln) ebuilds so no new installs of xorg can only be done without the vuln code.
(In reply to comment #13) > When this bug goes public. Can you add the new version and remove all old > (vuln) ebuilds so no new installs of xorg can only be done without the vuln > code. Yep, that's the plan. Vulnerable are xorg-x11-6.8.99.15-r4.ebuild and xorg-server-1.0.1-r4.ebuild, which will be replaced by xorg-x11-6.9.0.ebuild and (probably) xorg-server-1.0.2.ebuild.
This may be delayed again. From: Daniel Stone <daniel@fooishbar.org> To: Matthieu Herrb <matthieu.herrb@laas.fr> Cc: xorg_security@x.org, vendor-sec@lst.de, Jesse Keating <jkeating@j2solutions.net> Subject: Re: [Xorg_security] Re: [vendor-sec] X.Org 6.9/7.0 local root - found by coverity Date: Thu, 16 Mar 2006 16:44:06 +0200 (09:44 EST) On Thu, Mar 16, 2006 at 03:38:01PM +0100, Matthieu Herrb wrote: > Jesse Keating wrote: > >On 03/15/2006 Matthieu Herrb wrote: > >>Fedora project is going to release FC5 on March 20, but they'll start to > >>push the packages to their mirrors tomorrow, thurday 16. So this should > >>be considered as public starting at this date. > > > >Thats actually not true. We were hoping to, but we just didn't get > >enough communication in time. We will be releasing this as a 0-day > >update for Fedora, but it will not make the shipping CDs. > > So back to March 20, 14:0O UTC for the official disclosure, or did > someone already disclose it today? Given that 1400 UTC was 43 minutes ago, I think we should wait until Monday so we have the chance to write a sensible advisory and whatnot. I'll handle this, unless someone else really wants to.
(In reply to comment #15) > This may be delayed again. ... > > So back to March 20, 14:0O UTC for the official disclosure, or did > > someone already disclose it today? > > Given that 1400 UTC was 43 minutes ago, I think we should wait until > Monday so we have the chance to write a sensible advisory and whatnot. > I'll handle this, unless someone else really wants to. That doesn't look like a delay at all, it looks like staying where it was at March 20.
They appeared to be speeding up the release day then pulled back if nobody had released the patch yet.
(In reply to comment #8) > The affected code has never been in Gentoo outside of package.mask, as it was > introduced in the 6.8.99 series and modular X is also still masked. > > Do you still want a GLSA for it? No. There won't be a GLSA for it if the stable version isn't/wasn't affected. So let's downgrade severity...
Now public on xorg lists and BugTraq. Feel free to commit :)
We should be all set on this.
Thx Donnie. Closing without GLSA as this has never been outside of package.mask.
*** Bug 127289 has been marked as a duplicate of this bug. ***
