All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joanna Rutkowska <joanna@invisiblethingslab.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Lars Kurth <lars.kurth@xen.org>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Matt Wilson <msw@amazon.com>, Jan Beulich <JBeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: Security discussion: Summary of proposals and criteria (was Re: Security vulnerability process, and CVE-2012-0217)
Date: Mon, 09 Jul 2012 15:25:38 +0200	[thread overview]
Message-ID: <4FFADBD2.6070502@invisiblethingslab.com> (raw)
In-Reply-To: <4FFAC0FF.6040206@invisiblethingslab.com>


[-- Attachment #1.1: Type: text/plain, Size: 2707 bytes --]

On 07/09/12 13:31, Joanna Rutkowska wrote:
> On 07/09/12 11:23, George Dunlap wrote:
>> > On Sun, Jul 8, 2012 at 8:30 AM, Joanna Rutkowska
>> > <joanna@invisiblethingslab.com> 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 (after
>>> >> 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 black
>>> >> market might be prohibitively hard -- the only thing that might
>>> >> *somehow* help is the use of some smart water marking (e.g. of the proof
>>> >> of concept code). Of course, if a person fully understands the
>>> >> bug/exploit, she would be able to recreate it from scratch herself, and
>>> >> 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 their
>>> >> 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 machines.
>>> >> So, perhaps #3 is of biggest concern to the community.
>> > 
>> > 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)?

(Correction: I meant a 6-figure number)


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2012-07-09 13:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-06 16:46 Security discussion: Summary of proposals and criteria (was Re: Security vulnerability process, and CVE-2012-0217) George Dunlap
2012-07-08  7:30 ` Joanna Rutkowska
2012-07-09  9:23   ` George Dunlap
2012-07-09 11:31     ` Joanna Rutkowska
2012-07-09 13:25       ` Joanna Rutkowska [this message]
2012-07-09 13:35         ` Keir Fraser
2012-07-09 13:40           ` Joanna Rutkowska
2012-07-09 13:51       ` Tim Deegan
2012-07-09 14:08         ` Joanna Rutkowska
2012-07-12 16:34           ` Stefano Stabellini
2012-07-12 16:47             ` Joanna Rutkowska
2012-07-12 17:00               ` Stefano Stabellini
2012-07-12 17:22                 ` Joanna Rutkowska
2012-07-13 18:15                   ` Stefano Stabellini
2012-07-14  0:18 ` Security discussion: Summary of proposals and criteria Matt Wilson
2012-07-16 17:56   ` George Dunlap
2012-08-03 17:31 ` Security discussion: Summary of proposals and criteria (was Re: Security vulnerability process, and CVE-2012-0217) George Dunlap
2012-08-06  6:55   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FFADBD2.6070502@invisiblethingslab.com \
    --to=joanna@invisiblethingslab.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=lars.kurth@xen.org \
    --cc=msw@amazon.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.