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: Mon, 09 Jul 2012 13:31:11 +0200 Message-ID: <4FFAC0FF.6040206@invisiblethingslab.com> References: <4FF93711.6020108@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3619091803606907098==" 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: George Dunlap Cc: Stefano Stabellini , Lars Kurth , Jan Beulich , Matt Wilson , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============3619091803606907098== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58FA4743A6BF51AE502028A6" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58FA4743A6BF51AE502028A6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 07/09/12 11:23, George Dunlap wrote: > On Sun, Jul 8, 2012 at 8:30 AM, Joanna Rutkowska > wrote: >> On 07/06/12 18:46, George Dunlap wrote: >>> Another question has to do with robustness of enforcement. If there >>> is a strong incentive for people on the list to break the rules >>> ("moral hazard"), then we need to import a whole legal framework: how= >>> do we detect breaking the rules? >> >> 1) Realizing that somebody released patched binaries during embargo is= >> simple. >> >> 2) Detecting that somebody patched their systems might be harder (afte= r >> all we're not going to perform pen-tests on EC2 systems and the likes,= >> right? ;) >> >> 3) Detecting that somebody sold info about the bug/exploit to the blac= k >> market might be prohibitively hard -- the only thing that might >> *somehow* help is the use of some smart water marking (e.g. of the pro= of >> of concept code). Of course, if a person fully understands the >> bug/exploit, she would be able to recreate it from scratch herself, an= d >> then sell to the bad guys. >> >> On the other hand, the #2 above, seems like the least problematic for >> the safety of others. After all if the proverbial AWS folks patch thei= r >> systems quietly, it doesn't immediately give others (the bad guys) >> access to the info about the bug, because nobody external (normally >> should) have access to the (running) binaries on the providers machine= s. >> So, perhaps #3 is of biggest concern to the community. >=20 > The reason I brought up the issue above didn't so much have to do with > the risk of people leaking it, but to help evaluate the proposals that > had "No roll-out is allowed until the patch date". There's probably > little incentive or ability for the average programmer / IT person to > sell the bug on the black market. (I have no idea how I would begin > to go about it, for instance.) 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 fit into this crowd, true, but then again, do you think it would 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 the press that hot bugs/exploits sell for this amount actually)? US gov apparently invested lots of money in creating stuxnet and flame (and probably other malware) -- don't you think the Chinese would not be interested in owning some of the AWS machines in return? > However, if we had a "no roll-out > during embargo period" rule, there would be a huge incentive for > people or organizations to "cheat" by rolling it out early, giving > them an advantage over those either not on the list, and those on the > list but not cheating. So from a security perspective, of course #3 > is the most important; but as a community project with a wide range of > users (many of whom are both small and active), #2 is what I am most > concerned about. >=20 Ah, I see, so you're concerned about an unfair advantage that a large Xen-based service company (that happens to be on the list) might have over the others? Sure, I agree. But then, on the other hand, it seems to me that an attack against some large service provider, such as AWS, might be quite fatal in consequences. So, letting them patch their systems (especially given the fact that this shouldn't "leak out" info about the bug to the world) might be a reasonable compromise... As a normal citizen I think I would sleep better knowing that important players can patch before the others. > BTW, Joanna, do you have any opinions / input on the argument that > disclosure does not significantly increase risk, because patched > systems means that the vulnerability has reduced value to black hats? >=20 I'm not quite sure if I understand this question? Can you elaborate? joanna. --------------enig58FA4743A6BF51AE502028A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP+sD/AAoJEDaIqHeRBUM0YEUIAKv9prMRSvQNTZvwawutAigC LqYirqCQjIiwWsqHHL7Jy6M042/P0X149gvTeRPCHwYiGVifSIX/pmGFtcLoXpjR itr2VjFzdNH7WZy76hEk47Trs+eH4C0ZBgJz9reyLNbM2yUj+c8H5UtgLumw+VEa OrdqqFoZEOHrv2YVm4YJBqces46tq1QDIen647/Nlv85ngDDAXTTZpULFGFx7zCq DfiY93Au3SdQV7geiR8MzN4y4yrKSVhJFP4PghFbxfUS3MOXaclOgPq1M+1Crs/P VWeHlBji8qFjINnnuuMweA8an7FLO4rhvAdNTzolgGBiE4YW5pOGLK4m0HIc/mc= =GgnC -----END PGP SIGNATURE----- --------------enig58FA4743A6BF51AE502028A6-- --===============3619091803606907098== 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 --===============3619091803606907098==--