From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Re: Security discussion: Summary of proposals and criteria (was Re: Security vulnerability process, and CVE-2012-0217) Date: Thu, 12 Jul 2012 19:22:58 +0200 Message-ID: <4FFF07F2.8090709@invisiblethingslab.com> References: <4FF93711.6020108@invisiblethingslab.com> <4FFAC0FF.6040206@invisiblethingslab.com> <20120709135101.GA83420@ocelot.phlegethon.org> <4FFAE5C4.8010600@invisiblethingslab.com> <4FFEFFBD.5070502@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1745259452761504253==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Jan Beulich , George Dunlap , "Tim (Xen.org)" , "xen-devel@lists.xen.org" , Lars Kurth , Matt Wilson List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1745259452761504253== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig171D298A49180814EA9274CA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig171D298A49180814EA9274CA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/12/12 19:00, Stefano Stabellini wrote: > On Thu, 12 Jul 2012, Joanna Rutkowska wrote: >> > On 07/12/12 18:34, Stefano Stabellini wrote: >>> > > On Mon, 9 Jul 2012, Joanna Rutkowska wrote: >>>>> > >> > On 07/09/12 15:51, Tim Deegan wrote: >>>>>>> > >>> > > At 13:31 +0200 on 09 Jul (1341840671), Joanna Rutkowska= wrote: >>>>>>>>>>> > >>>>> > >> > If you're into security industry (going to con= ferences, etc) you >>>>>>>>>>> > >>>>> > >> > certainly know the right people who would be d= elight to buy exploits >>>>>>>>>>> > >>>>> > >> > from you, believe me ;) Probably most Xen deve= lopers don't fit into this >>>>>>>>>>> > >>>>> > >> > crowd, true, but then again, do you think it w= ould be so hard for an >>>>>>>>>>> > >>>>> > >> > interested organization to approach one of the= Xen developers on the >>>>>>>>>>> > >>>>> > >> > pre-disclousure list? How many would resist if= they had a chance to cash >>>>>>>>>>> > >>>>> > >> > in some 7-figure number for this (I read in th= e press that hot >>>>>>>>>>> > >>>>> > >> > bugs/exploits sell for this amount actually)? >>>>>>> > >>> > > I think the argument is that an exploit that's going to= be public (and >>>>>>> > >>> > > patched) in the next couple of weeks would not fetch th= e same kind of >>>>>>> > >>> > > price as a unknown attack that can be kept for later. >>>>> > >> >=20 >>>>> > >> > Depending on the type of an exploit. For client-side exploit= s, perhaps >>>>> > >> > you're right. But for infrastructure attacks it's a differen= t story -- >>>>> > >> > having an exploit such the Rafal's one, I could have *silent= ly* exploit >>>>> > >> > lots of AWS machines and install backdoors in their hypervis= ors/dom0. >>>>> > >> > The fact that they will patch the bug two weeks later might = be >>>>> > >> > irrelevant then. >>>>> > >> >=20 >>>>> > >> > After all, how are you going to check whether your physical = server has >>>>> > >> > been compromised? Most people don't use any form of trusted = boot, but >>>>> > >> > even if they did, it's not a silver bullet as we have demons= trated a few >>>>> > >> > times in a row. And if you don't have trusted boot, as most = people, you >>>>> > >> > have very little chances to detect a custom-made backdoor. E= ven if you >>>>> > >> > are allowed to reboot the machine and boot "good known binar= ies", which >>>>> > >> > often you cannot do, are you going to manually audit all the= firmware, >>>>> > >> > ACPI tables, etc? Not to mention about the integrity of the = actual VMs, >>>>> > >> > that might have also got compromised (and checking for integ= rity of a >>>>> > >> > running OS, such as Linux or Windows, is just undoable). >>>>> > >> >=20 >>>>> > >> > Having that said, 2 weeks might be a bit short to prepare su= ch an >>>>> > >> > advanced attack. In this respect, it would be probably benef= icial to >>>>> > >> > keep the embargo period as short as possible (that still all= ows >>>>> > >> > important players to patch before others). 1 week perhaps? >>> > > I agree on the short embargo period and I am not against having a= list. >>> > >=20 >>> > > However I don't think that the list should be limited to the "imp= ortant >>> > > players". How do we define an "important player"? >>> > > If we decide that important players are the big ones, suddenly bi= g >>> > > players become the only ones that can be entrusted with sentive >>> > > informations. >>> > >=20 >>> > > Any distros can join linux-distros, no matter the size. >> >=20 >> > I didn't say the list should be limited to the important players -- = I >> > said it likely makes no harm, from the security standpoint, if we >> > allowed select "important" _service providers_ to patch before other= s >> > (because, again, the world doesn't see what Xen binaries are running= on >> > their servers, and so this doesn't leak out info about the bug, at l= east >> > it shouldn't in most cases). >> >=20 >> > I think that the list should essentially contain only some core Xen >> > devels and all the software vendors that _are known_ to build and >> > distribute products on top of Xen (such as qubes-os.org ;) Perhaps t= he >> > "important" service providers could be brought in on a case-by-case = basis. > I understand now. This is very similar to having two list, one for > software vendors and another one for service providers. >=20 > While all the security issues would be discussed in the software vendor= s > list, only the most critical ones would be sent to the service provider= s > list? >=20 Now, when you mentioned it, I thought that perhaps it would be a better idea to have one list only for core Xen developers, and the other list for Xen users, i.e. software vendors such as qubes-os.org, an perhaps also for some providers. Perhaps the users from the 2nd list could be informed only when the specific vulnerability affects their product. As an example, say there is a bug in qemu reported to the primary list. Now, a query can be send to all the members of the 2nd list whether any of them are interested in getting info about the bug, something like: "There's been a bug found in the qemu used by Xen X.X.X, if you believe this might affect your product/infrastructure security, reply to this message with YES, and you will get more info". The catch is, of course, that if it could be later proven that some vendors answered YES, although their products were not affected (e.g. by design), those vendors should be somehow banned from the list. E.g. if I replied YES to the above query, you should know I went on the dark side of the force, as Qubes OS keeps qemu outside of the TCB, and so we shouldn't be caring about such things :) This is somehow problematic with Xen providers, as opposed to software vendors, as it's might not be clear how Xen has been deployed by a particular provider, and thus whether e.g. a bug in pygrub affects them or not... > But the key question remain: would we allow a small service provider to= > join the service providers list? I think that we should. It would probably be very easy for the proverbial Chinese to setup a small service provider and join the list just to get prompt info about bugs they can exploit in order to 0wn the proverbial AWS... joanna. --------------enig171D298A49180814EA9274CA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP/wfyAAoJEDaIqHeRBUM0qzUIALZr5oAOV6qvYaMw8+OK0xHe YXwc2ZAcfAwxVgpNjSNi4IdCKAfD5YsEcX6HNzQhlfBlQzLBrhZz0ym/JG0XyE08 d6HDXoqIgp3q0YqxALd1FMZ7ltGDBvDrDjSnKELp/bLrPTFtFBgUc0DjLRdh6sG7 IIWrgvHGWWkjnnXSSRfWNceZtjxKm1woOAWclTOncRIIBxGI5QTJJrgb1MrLz5wB BS8JZK24NHH71c2AUVf25XOfBnojjremMq3vaZfUfVaP3uyC15UbbmkUDs59PH5U F12HL25+z3AX62ol76OBcSv6YfSB2P+F4IaykoQwJv4DaKyPo+iii7gONJZocg4= =O+Ew -----END PGP SIGNATURE----- --------------enig171D298A49180814EA9274CA-- --===============1745259452761504253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1745259452761504253==--