Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Correct me if I'm wrong, but won't Meltdown/Spectre bug allow people to jailbreak pretty much any os/device that has CPU that "supports" these bugs? This could potentially open a lot of currently closed devices to people.


AIUI (and I am not an expert):

- Meltdown, on affected processors (...basically anything from Intel), gets you the ability to read anywhere in memory, whether you could legally map it or not (e.g. you can read from kernel, user, or w/e memory as an unprivileged user, albeit on the order of bytes per second)

- Spectre affects approximately anything with a cache and speculative execution, but only buys you reading anywhere that you could legally map, e.g. you can read anything the process you're in could legally read, but you can't, say, read kernel memory with it as an unprivileged user.

Either way, you don't get an arbitrary write, but you could maybe use it to make another exploit more reliable with the additional information you get (a big danger of the Spectre family is using it to help you read data outside your sandbox but still in your "process", e.g. stealing password auto-fill data from inside JavaScript, or using it to defeat ASLR on your sandbox, or ...).


Spectre also allows reads from places you can't map, as long as you can mistrain the branch predictor for some other code that can.


Which is to say, the set of attacks allows Kernel memory to be read from userspace:

> If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time.

https://googleprojectzero.blogspot.com/2018/01/reading-privi...


Spectre also applies to other address spaces, not just the kernel.


True, but sometimes just getting private key from the memory will be enough to gain access to the system as it could give researchers ability to build executable that will look like they came from the manufacturer/developer.


Modern design seems to be moving these sorts of keys from CPU addressable memory into "protected enclaves" and co-processors of various sorts.


Potentially.

The problem with X360 is it can’t run arbitrary native code, it only can run code digitally signed by MS. The hypervisor refuses to run an unsigned code, and the key never leaves the CPU i.e. very hard to tamper with.

X360 can execute JavaScript in the web browser, and .NET in (now discontinued?) XNA. I’m not sure if it’s possible to exploit the bug if you can only run JavaScript or .NET, both are very high level and have strong security model on top of what’s in the hardware/OS/hypervisor.


Surely they use asymmetric crypto, so the private key needed to sign code isn't present on the console at all?

Spectre might make it possible to dump the public keys but they're not very useful to us.


You could have exploited this using XNA, potentially, yes. But I don't think the software for running your own builds on the hardware works anymore, so the threat has passed. These attacks certainly reduce the likelihood of a similar service appearing on current-gen consoles.


The paper for Spectre includes a Javascript proof of concept - https://spectreattack.com/spectre.pdf, though I don't know if the version of IE on the 360 supports web workers (though, unpatched, it's exceedingly like there's a way to exploit it from javascript that doesn't involve web workers).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: