Re: [Qemu-devel] QEMU's CVE Procedures

[Stefano Stabellini]

On Fri, 5 Jun 2015, John Snow wrote:
> ----- Topal: Output generated on Mon Jun  8 11:48:03 BST 2015
> ----- Topal: GPG output starts -----
> gpg: Signature made Fri 05 Jun 2015 23:16:30 BST using RSA key ID AAFC390E
> gpg: Can't check signature: public key not found
> ----- Topal: GPG output ends -----
> ----- Topal: Original message starts -----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi, everyone:
> 
> ("Oh no, what monolith did John type up this time? /Golly Dang He's
> really giving Markus a run for his money/")
> 
> Prompted by the recent CVE-2015-3456 ("VENOM") issue, it seems to me
> that our CVE handling procedure is a little more ad-hoc than it should
> reasonably be. This is not the first attempt to help rectify our CVE
> process -- see Peter Maydell's 2.3 post-mortem.
> 
> Our Security Process page ( http://wiki.qemu.org/SecurityProcess )
> details a list of persons one may contact when confronted with a
> security issue, but it's not a mailing list of trusted persons, only a
> handful of contacts. The only email list mentioned here is actually a
> Red Hat list, not an upstream one.
> 
> 
> (1) Would it be worth creating an upstream non-public list as a single
> point of contact to be able to reach out to? It could include all of
> the names printed here (And -- hey! Why is Peter Maydell not on this
> list? ...) to make it secure and easy to grab hold of the right people
> who understand the security policies.

+1


> (2) What is our CVE management policy for maintainers?
> This policy page also doesn't specify what maintainers should do or
> how they should handle CVEs if they are approached by e.g. the Red Hat
> security team, so our policy should expand a little to include
> instructions for some of the maintainers and sub-maintainers.
> 
> Not that the procedure should be complicated, but spelling it out
> can't hurt. Specific policy questions follow below.

I think that this is the point that is going to be harder to write. Feel
free to take a look at the Xen security process for inspiration:

http://www.xenproject.org/security-policy.html

Xen maintains its own pre-disclosure list, but aside from that, the rest
should be pretty reusable.


> (3) How do maintainers get reviews? Who do they ask?
> CVEs by nature are handled behind closed doors during the embargo
> period, so patches can't just be posted to the list at large. So there
> needs to be a review process in place for sub-maintainers that we can
> follow to get patches properly reviewed in a secure and private manner
> before the embargo date.
> 
> We could leave this process "ad-hoc" and trust that maintainers know
> who to ask for reviews, but I do not want anyone accused of "slipping
> in fixes" away from the eyes of the list, so a more formal procedure
> will help prevent any accusations of impropriety.
> 
> We likely need a list or mechanism where we can query a portion of
> developers who have agreed to assist with CVE patch reviews. This
> could include the existing security team, Peter Maydell, other
> sub-maintainers, developers with a lot of general experience and/or
> experience with the subsystem in question.
> 
> This could be perhaps the same email list as above (expanded to
> include a couple of reviewers) and those reviewers could loop in other
> developers on a case-by-case basis to get appropriate reviews, or we
> could create a wiki page with GPG keys and so forth of trusted
> reviewers that sub-maintainers can reach out to for reviews on a
> case-by-case basis.
> 
> Anything would be better than "Guess and go for it."

This should be easy: I think that people in the security list should
include anybody they feel would be able to contribute, as long as they
previously agree on the terms of the embargo.


> (4) How much review is sufficient?
> 
> A CVE patch should probably get at least one review from someone who
> is not Peter Maydell or the subsystem maintainer.
> 
> After it's been looked over by these 2-3 people it should be handed
> over to Peter Maydell to pre-approve prior to the embargo date being
> lifted so that the patch can be pulled promptly after disclosure is
> public.
>
> (5) What should be posted on embargo day?
> 
> A pull request of the patch(es) with all of the ACKs and R-Bs acquired
> during the embargo period alongside the patch being posted to
> qemu-devel and qemu-stable simultaneously seems sufficient.
> 
> Any additional review or changes incurred after the embargo date can
> be handled publicly and in the normal manner in response to the patch.
> 
> 
> (6) What about qemu-stable?
> 
> Our stable process is somewhat lacking with respect to the CVE
> process. It is good that we occasionally publish stable fix roundups
> that downstream maintainers can base their work off of, but it would
> be good to have a branch where we can have CVE fixes posted promptly.

+1


> (7) How long should we support a stable branch?
> 
> We should figure out how many stable release trees we actually intend
> to support: The last two releases? The last three?
> 
> My initial guess is "Any stable branch should be managed for at least
> a year after initial release."
> 
> This would put our current supported releases as 2.1, 2.2 and 2.3, so
> about ~3 managed releases seems sane as an initial effort.

I would like to see a more formal stance on how long the stable trees
will be maintained. It would also be nice if the trees were maintained
for longer period of times compared to now, without necessarily getting
into the business of maintaining them for years.


> 
> (8) What should our procedure for tagging stable branches be?
> 
> I am suggesting that we /can/ and *should* apply bug-fixes to the
> stable branches untagged to allow people to check out and build what
> are essentially "preview" builds of the upcoming stable release.
> 
> Peter has suggested that any CVE patch in particular should force a
> new stable tag and cause an accompanying source tarball release
> without waiting for a roundup.
> 
> This is in contrast to our current rhythm where we only push new
> patches periodically as part of the roundup and tag the new stable
> release then. This is undesirable because it means that users may not
> be able to get bugfixes and security patches in a timely manner from
> upstream -- they currently HAVE to rely on downstream maintainers.

I am not sure whether a new tag is important, as long as the CVE fixes
are applied to the stable trees right away.



> (9) Who is going to manage these stable branches?
> 
> Currently it looks like Michael Roth, although he's not actually
> listed in the MAINTAINERS file. The maintainers file lists a bunch of
> apparently unsupported and orphaned stable branches, too -- we should
> cull these and update the file with newer information.
> 
> Perhaps it would be pertinent (If Michael is unwilling) to give each
> stable branch to a different maintainer to help keep the maintenance
> burden low. Of course, the more people we ask to manage these
> releases, the more complicated each individual CVE becomes, because it
> increases the necessary communication between the different stable
> branch maintainers.
> 

I am not volunteering for maintaining the QEMU stable trees (not enough
bandwidth), but I am happy to help providing backports, given that most
of the times I need to do that anyway for the qemu-xen stable trees and
they should be reusable as is.


> Anyway, my apologies for the wall of text. I wanted to take this
> opportunity post-venom to ask some questions to the list to see if the
> interest is there in revamping our CVE policy which is in need of, at
> the very least, some clarifications.
> 
> See you all next CVE :)
> 
> - --js
> 
> 
> (Oh, and have a good weekend!)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJVch++AAoJEH3vgQaq/DkOiugP/REQCM6H3q7O5CnomtEq0Gtw
> WrrQ/8qyCaqRSb6VcO97wO0hQUMEy01SQ1B+HhOzHEWcO1BmhjC0GyNQpAD7JAl6
> gRcYpoKa+regPCNc1Sa4eCgI7c8RoC9qygzmrRxgXYI9vGvJn3pideGJB3ubd0ej
> uX8SqjxhJKMp7gLnKcBdasYfNTrazvc+8Co5I+VXj68gdSHz+qlw3/Ebgf9FIIez
> jHT+jH5t98XlZ1R3zL/iQMKTJDEtrF8zAwW5IZxA3cxcl8dW3K06bWx2RQd59PGB
> CQVWCelPg74JiU5d4WX06GiTf863t56K2q0JuO0pGLBhMfP0ILF5CHf9h4lG3bnJ
> dtsYMrs45eJfNfQj4C54tRdXN8GVBc0XAih1QCgDP52B+rw28wZNg4CvIyYr3uCV
> s9j+0+dtiQ9nX0WIkTs2sCpdhTd3Of3x3Pi/i8FlI7c53mQVoa8hW3wYpUsfnWms
> LRyuMjQ0g7oxZMYlWn9XWfgmvGTk3TwP/zKRI9Bh6HqldYqhzJDsz7lzKKJsWuRG
> 1KFfmJWbAo96uTWFM7p/2UJSGrlN970tU+cpBXpVMsEc8F7xfqup4/6dlqX1ZX0Z
> r8u9NP7jwUHcP66ZrtbrHvGOhxQiKjNiGAgXcwJWlDA4rEv90nt9IXBs6hYRd61S
> QSlU9M5OTcbyskOmm7lh
> =Jepd
> -----END PGP SIGNATURE-----
> ----- Topal: Original message ends -----
>