Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 20 Aug 2015 01:33:26 -0400
From: sophia <sophia@...ilofbits.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE request - Processor side channels using out of order execution

Hi,

Thanks for the reminder, the URL to the material for the out-of-order-exploitation setup is below:

http://sophia.re/side_channel_material <http://sophia.re/side_channel_material>

- Sophia

> On Aug 19, 2015, at 5:26 PM, Solar Designer <solar@...nwall.com> wrote:
> 
> Sophia, Kurt, all -
> 
> This is an old-fashioned mailing list, not business correspondence.
> Top-posting and over-quoting are discouraged.  Also discouraged are what
> I call thanks-only postings.  It's polite to thank the person, but
> unless you have something valuable to add, those postings are not worth
> distributing to all the list subscribers.
> 
> To make my own posting more valuable (rather than moderation-only):
> 
>>> On Wed, Aug 19, 2015 at 2:29 PM, sophia <sophia@...ilofbits.com> wrote:
>>>> Just wondering how to get more information about the process for
>>>> requesting a CVE for this vulnerability.
> 
> Kurt provided that, but more importantly: you should be patient.  MITRE
> are often slow at assigning CVE IDs.  It's only been a week.  They often
> need several weeks, unfortunately.  (In contrast, Kurt is usually quick
> to assign CVE IDs on the distros list, but this only works for not yet
> public issues and is only acceptable if those issues are disclosed to
> the distros list primarily for the purpose of informing the distros
> rather than for acquiring a CVE ID.  Having a CVE ID is too unimportant
> to be worth the risk.)
> 
>>>> On Aug 12, 2015, at 12:24 PM, sophia <sophia@...ilofbits.com> wrote:
>>>>> The vulnerability definitely applies to hypervisors as used by popular
>>>>> commercial cloud platforms. These hypervisors try to guarantee that one
>>>>> user's processes in a VM are meant to be isolated from another VM's.
>>>>> Isolation is referenced as a feature multiple times in Xen's spec:
>>>>> http://www-archive.xenproject.org/files/Marketing/WhyXen.pdf.
> 
> WhyXen.pdf does mention isolation, but it doesn't mention covert
> channels, leaving it ambiguous (to those of us aware of the possibility
> of covert channels) what level of isolation is actually intended.  Maybe
> they need to revise the document to explicitly exclude covert channels.
> 
> Historically, access control didn't automatically imply lack of covert
> channels.  For example, per the Orange Book covert channels weren't even
> considered for the lower classes such as C1 and C2, where typical and
> "Trusted" multi-user systems fell.  They are only considered starting
> with B2 and B3, which rarely applied:
> 
> https://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria#Divisions_and_classes
> 
> Once again, to avoid misunderstanding, I only use this as a historical
> reference.
> 
>>>>> Also, I will release all of my code on my website when I get back to my
>>>>> server later today.
> 
> Have you?  Please post the URL in here.
> 
> Thank you!
> 
> Alexander


Content of type "text/html" skipped

Download attachment "smime.p7s" of type "application/pkcs7-signature" (3833 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ