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 18:47:57 +0200 Message-ID: <4FFEFFBD.5070502@invisiblethingslab.com> References: <4FF93711.6020108@invisiblethingslab.com> <4FFAC0FF.6040206@invisiblethingslab.com> <20120709135101.GA83420@ocelot.phlegethon.org> <4FFAE5C4.8010600@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1554883855308927363==" 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) --===============1554883855308927363== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA57B94EDBE0B67DB78177A4" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA57B94EDBE0B67DB78177A4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 conferences, etc)= you >>>>> > >> > certainly know the right people who would be delight to buy = exploits >>>>> > >> > from you, believe me ;) Probably most Xen developers don't f= it into this >>>>> > >> > crowd, true, but then again, do you think it would be so har= d for an >>>>> > >> > interested organization to approach one of the Xen developer= s on the >>>>> > >> > pre-disclousure list? How many would resist if they had a ch= ance to cash >>>>> > >> > in some 7-figure number for this (I read in the press that h= ot >>>>> > >> > 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 the same kin= d of >>> > > price as a unknown attack that can be kept for later. >> >=20 >> > Depending on the type of an exploit. For client-side exploits, perha= ps >> > you're right. But for infrastructure attacks it's a different story = -- >> > having an exploit such the Rafal's one, I could have *silently* expl= oit >> > lots of AWS machines and install backdoors in their hypervisors/dom0= =2E >> > 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 h= as >> > been compromised? Most people don't use any form of trusted boot, bu= t >> > even if they did, it's not a silver bullet as we have demonstrated 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. Even if y= ou >> > are allowed to reboot the machine and boot "good known binaries", wh= ich >> > often you cannot do, are you going to manually audit all the firmwar= e, >> > ACPI tables, etc? Not to mention about the integrity of the actual V= Ms, >> > that might have also got compromised (and checking for integrity 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 such an >> > advanced attack. In this respect, it would be probably beneficial to= >> > keep the embargo period as short as possible (that still allows >> > 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 "important= > players". How do we define an "important player"? > If we decide that important players are the big ones, suddenly big > players become the only ones that can be entrusted with sentive > informations. >=20 > Any distros can join linux-distros, no matter the size. 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 others (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 least it shouldn't in most cases). 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 the "important" service providers could be brought in on a case-by-case basis= =2E joanna. --------------enigDA57B94EDBE0B67DB78177A4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP/v+9AAoJEDaIqHeRBUM01akH/0C5Oh3JJBu95vLjAAzzdh8y 6CqpICzGz4R76uZnUgWFe4Y0Jwz2rJ20ffHE0mWiqMmtMaZ1B1zwE2cPZtqbAd/z AVgLY1w2SNXOYj5gJA8PYenvEZNJqwRYQbd2le9Moq2cz3e/VI5+a1ILqdEp94SA ZzEKxIfot9fVkMfXtgLAyBqV+rJ7wx8B4eT93v2aHOgU7I6wKoT2xigPY2A758H4 pWRMVtG2IulvuwE8R/iXnQg92wglX2k/oLHkJDDRXXh3s0VWM5ZI6hBUiMMcQKWd 9fhxy1fnyIxj+Xk8FhCYoAZNthvM3oAhn2biJolTSBv5SEWKkw8JaxXMhti0OW4= =MeCX -----END PGP SIGNATURE----- --------------enigDA57B94EDBE0B67DB78177A4-- --===============1554883855308927363== 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 --===============1554883855308927363==--