571–580 of 639 posts
Earlier quoted context omitted.
I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...
I thought it was supposed to be exploitable by javascript? If you can get to the machine and run c code, well, that doesn't seem like an exploit?
Earlier quoted context omitted.
We'll have to dig a time machine out and go back to 1998 then. I'm being a facetious ass. But you know I'm not wrong, either.
You are wrong. Install the NoScript extension and you can see your site without js. NoScript also allows you to selectively enable js per site on a temporary or permanent basis. This is the default way that I and many other people browse the web. https://noscript.net/
Earlier quoted context omitted.
They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor. See the section "Reading host memory from a KVM guest / Locatin…
I've tried reading it and I still find all of this very confusing. Could you ELI5?
Earlier quoted context omitted.
They test how a series of branches are predicted after returning from a hypercall, which lets them basically dump out the state of the BTB. From that, and knowledge of where the branches are in the hypervisor binary (the binaries themselves aren't really a secret, only the relocated load address is) they can figure out the load address of the hypervisor. See the section "Reading host memory from a KVM guest / Locatin…
But if you use AMD ASID it blocks this as memory mappings for VM guests are in a completely separate address space. What I was wondering was for local OS user mode to local OS root / kernel mode access; i.e. user to kernel privilege escalation.
Earlier quoted context omitted.
I don't think you understand the bug here. 1) https://spectreattack.com/ : "Spectre tricks other applications into accessing arbitrary locations in their memory. " Spectre does not let you execute code in another guest 2) Spectre is not javascript specific. I am not sure why you think it is, beyond the fact a PoC was written in js
I don't think you understand my point. You should reread my post, especially the first sentence. It's first and alone for a reason; not sharing hardware is an effective mitigation against vulnerabilities in shared hardware. Obviously it's not just a js bug, there are other PoCs in other languages. I never said anything about executing code in another guest, not sure where you got that from.
You have no reason to care about a neighbor VM executing Spectre on the same physical server, since they're only hurting themselves, not you.
>Add in that Spectre specifically is a js bug so in order to be vulnerable your server would need to execute untrusted JavaScript and I think we can assume the threat surface of this specific bug is smaller outside the cloud...
"Spectre specifically is a js bug"
Has Google the best security team in the world? It seems like Google security is in a complete different league. I cannot imagine how this impacts companies handling fiat money or cryptocurrencies in the cloud like Coinbase in AWS.
Project Zero is very well known for things exactly like this. Partially, it's because they are incredibly talented, but there are also talented people in academia and in other security consultancies. The biggest difference with Project Zero is that their primary [0] goal is altruistic: find vulnerabilities, and let people who can fix them know (vs publishing papers, securing paying clients, auctioning zero-days, etc)…
Suppose your company also has a team that inspects public bridges to make sure they don't collapse.
Is it really altruistic, or given your market share is it a cost of business?
Earlier quoted context omitted.
I don't think so. My understanding from the paper is that you don't need to explicitly send a memory address to the victim, you just need a way to communicate with it (e.g. via a socket or some other API) in a way that causes it to do a branch. Before you trigger the victim process, you perform some steps in your own, hostile, process that teaches the branch predictor where a particular branching operation will likel…
this still seems off to me. I get that the victim process' branch prediction can be messed with. But if my victim process is: password = "password" secret = "magic BTC wallet secret key" while True: password_attempt = input() if constant_time_compare(password, password_attempt): print(secret) And my input is something like: result = "" while sys.stdin.peek() not in ['\n', EOF]: result += sys.stdin.get() Then at no po…
Earlier quoted context omitted.
From the Spectre whitepaper: > In addition to violating process isolation boundaries using native code, Spectre attacks can also be used to violate browser sandboxing, by mounting them via portable JavaScript code. We wrote a JavaScript program that successfully reads data from the address space of the browser process running it. The whitepaper doesn't contain example JS code however
This whitepaper describes the Javascript exploit in Section IV. I'm struggling to understand it though: http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf
Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.
I am not sure what "the process in which it runs" means here ... do they mean private memory from within chrome ? Or within the child process spawned from chrome, or within the spawned JS sandbox or ... what ?
Practically speaking, I worry about a browser pageview that can read memory from my terminal process. Or from my 'screen' or 'sshd' process.
I think that is not a risk here, yes ?
Papers describing each attack: https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf From the spectre paper: >As a proof-of-concept, JavaScript code was written that, when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs (cf. Listing 2). Scary stuff.
I've thrown the C code in the Spectre paper up if anyone wants to feel the magic: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9...