X86 dispatch contention vulnerability CRM:0461068385

[Ryan Carboni]

Apple is a better company than than Microsoft. I ask you this: how does
Microsoft handle wiretap requests? How does Apple handle wiretap requests?

Does Microsoft sign any DLLs that is asked of them? It is curious that no
journalist talks about common procedure. No doubt this “attacker” is
defined the same as according to citizenlab someone acting without “any
legal authorization”.

You dogs can smirk behind your laws, and overlook those violate those laws
in a way pleasing to you, so I ask of the Lord to strike down an Azure
datacenter by what cannot be attributed to any other power!


On Thursday, November 15, 2018, Microsoft Security Response Center <
secure at microsoft.com> wrote:

> Hello,
>
> Thank you for contacting the Microsoft Security Response Center (MSRC). In
> order to investigate your report I will need a valid proof of concept (POC)
> ideally with images or video, the detailed steps to reproduce the problem,
> and how an attacker could use it to exploit another user.
>
>
> When ready, submit a new email to secure at microsoft.com without a CRM
> number in the subject line. Please include:
>
>    - Relevant information previously provided in your initial report
>    - Detailed steps required to consistently reproduce the issue
>    - Short explanation on how an attacker could use the information to
>    exploit another user remotely
>    - Proof-of-concept (POC), such as a video recording, crash reports,
>    screenshots, or relevant code samples
>
> Regards,
>
> Tina
> MSRC
>
>
>
> ------------------- Original Message -------------------
> *From:* ryacko at gmail.com
> *Received:* Wed Nov 14 2018 09:34:48 GMT-0800 (Pacific Standard Time)
> *To:* <Microsoft Security Response Center>; Microsoft Security Response
> Center; Microsoft Security Response Center
> *Cc:* cypherpunks at lists.cpunks.org
> *Subject:* X86 dispatch contention vulnerability CRM:0461068385
>
> While many x86 implementation vulnerabilities in the past involve either
> electromagnetic emissions or cache timing attacks, I have not read anything
> about instruction dispatch contention. According to anger fog’s research,
> Intel’s implementation of the x86 instruction set does not dispatch more
> than three of a single instruction, and it has been so for a long time.
> Irregardless of their design decisions for instruction dispatch, this
> provides a side channel in which two cooperating processes operating on the
> same core can conduct half-duplex communication at the rate of 2 bits per
> cycle by one process attempting to compete with another process for the
> same capacity for dispatches over a single instruction (0, 1, 2, 3). While
> I do not have the resources to know
> x86 processors handles dispatch contention issues, if it is handled in a
> regular and non-random manner, it would reach that theoretical level of
> severity.
>
> This violates certain access controls assumed to be imposed by the kernel.
>
> I suppose I can’t collect my quarter million dollar prize if I publish
> this to the world?
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6637 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20181116/b3e65e0a/attachment.txt>