embargo ends Sept 11th 2013. Requires coordination with CVE-2013-4288 as the fix to CVE-2013-4311 depends on it.
It's past the embargo date you specified and there is no information in this bug as to which package has a vulnerability, much less any information about the vulnerability. It defeats the purpose of having a restricted bug. Unrestricting the bug and will close it invalid in 48 hours if more information is not provided.
(In reply to Sean Amoss from comment #1) > It's past the embargo date you specified and there is no information in this > bug as to which package has a vulnerability, much less any information about > the vulnerability. It defeats the purpose of having a restricted bug. > > Unrestricting the bug and will close it invalid in 48 hours if more > information is not provided. Embargo has been pushed back to Sept 18th by the vendor. I would provide some information on the bug that I can but now that its unrestricted I can't.
(In reply to Doug Goldstein from comment #2) > Embargo has been pushed back to Sept 18th by the vendor. I would provide > some information on the bug that I can but now that its unrestricted I can't. We are talked about this issue. Unless you provide some useful info, this bug will be marked as INVALID. Reporting restricted bugs about some vulnerability in some product is counter-productive. Either provide info in RESTRICTED bug, which contents we, as a security team will keep in private for a certain date, or do not file such bugs at our bugzilla at all.
Let's all relax. What I agreed to said I would not disclose any information to people not on the list which apparently no one from security@gentoo.org is on. I needed clarification before I could fill details in, telling me that you won't disclose information is not good enough until I got clarification. By the time I did this bug was marked unrestricted so I couldn't add any information. This is the first time I'm getting back to it now that its toggled restricted again. This bug was primarily made not for security@gentoo.org but for me to coordinate with the maintainer of polkit, on bug #484486. This bug is for libvirt. We'll have this be to stabilize libvirt-1.1.2-r2.
(In reply to Doug Goldstein from comment #4) > Let's all relax. What I agreed to said I would not disclose any information > to people not on the list which apparently no one from security@gentoo.org > is on. I needed clarification before I could fill details in, telling me > that you won't disclose information is not good enough until I got > clarification. By the time I did this bug was marked unrestricted so I > couldn't add any information. This is the first time I'm getting back to it > now that its toggled restricted again. > > This bug was primarily made not for security@gentoo.org but for me to > coordinate with the maintainer of polkit, on bug #484486. > > This bug is for libvirt. We'll have this be to stabilize libvirt-1.1.2-r2. Ok, but there is still certain information that you can provide without divulging the super-top-secret details of the vulnerability. The package name is a good start. I don't see a libvirt-1.1.2-r2 commited yet, so I assume you are working on an ebuild? Or are we still waiting for a fix and this should be [upstream]?
Embargo over.
The CVE was reissued and now the new fix is in place. Stabilize libvirt-1.1.2-r3
amd64 stable
x86 stable
Thanks for your work GLSA request filed
CVE-2013-4311 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4311): libvirt 1.0.5.x before 1.0.5.6, 0.10.2.x before 0.10.2.8, and 0.9.12.x before 0.9.12.2 allows local users to bypass intended access restrictions by leveraging a PolkitUnixProcess PolkitSubject race condition in pkcheck via a (1) setuid process or (2) pkexec process, a related issue to CVE-2013-4288.
This issue was resolved and addressed in GLSA 201406-27 at http://security.gentoo.org/glsa/glsa-201406-27.xml by GLSA coordinator Chris Reffett (creffett).
