AMD Is Served: Class Action Lawsuit Launched Over Spectre Vulnerabilities

[bug]

Sure, it's unusual that vulnerabilities let you reach across VMs, but the vulnerabilities themselves have nothing to do with VMs. That is a very important distinction.
Any code running on a machine can in theory exploit this. Including the 100 apps on your phone, Java applets and in theory JavaScript in your web browser.

Perhaps ironically, phones a bit safer this time. Anything below SD8xx is only using low-power, in-order CPUs. Go figure.

 

[efikkan]

I would expect that to be far less likely because memory in Java is isolated to the JVM and you can't do the required operations to get Specrte to occur in Java or any language that runs on the JVM without altering and recompiling the JVM itself. You kind of need a language that gives you access to C-level binding in order to do this in a higher level language. JavaScript on the other hand (in particular Node,) is a lot closer to hardware than one might think and that any number of extensions written in C for it could be used to do this.

No, Java virtual machines were one of the first proof of concept which was presented.
Any piece of code which is able to trigger the right system calls with timing and precision will be able to exploit it. Nearly every language, even scripts, interface with low-level functionality through libraries.

 

[FordGT90Concept]

I guess they can be mad about the statement AMD made that there is a near zero chance spectre could infect the AMD architecture but still AMD made those test's known to the public and proved them self's wrong but still being mad about the near zero announcement is stupid in my opinion, but that is my opinion.

AMD mislead investors: they gave investors confidence so they moved shares from Intel to AMD only for AMD to later announce they're effected too. The investors can claim they were damaged. AMD can point to the "near" qualifier in their statement in defense.

 

[Aquinus]

No, Java virtual machines were one of the first proof of concept which was presented.

No, it wasn't. Google's first PoCs for this were written in C... and being able to capture that memory requires direct memory access which you can only do through a lower level language unless the code to do it was already in the VM which it likely isn't.
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

 

[efikkan]

No, it wasn't. Google's first PoCs for this were written in C... and being able to capture that memory requires direct memory access which you can only do through a lower level language unless the code to do it was already in the VM which it likely isn't.

No, then you've proven you lack the basic understanding of how code is executed. Any code, even the most abstracted scripting language, is either compiled, JIT compiled or interpreted into assembly code. All abstractions and encapsulations are translated into normal memory addresses(pointers) which in turn is moved back and forth between memory and CPU registers. Any language is executed as normal ALU, FPU, conditionals, jumps, etc. on the machine code level. All the abstractions you see when you type your code is gone when it's actually executed on the CPU.

The abstractions in a language does not protect you when a CPU or a kernel have undefined behavior. And when there is a bug causing information leakage due to speculative execution, it doesn't matter if you control your memory allocation or not, since these exploits are about tricking the CPU to write privileged memory back to your unprivileged memory.

So it doesn't matter if your code is written in PHP, JavaScript, Python, Go, Rust, Java or whatever. As long as you either directly or indirectly can trigger the right system calls and the right operations within a timeframe after that, either directly or indirectly, the language is irrelevant. It's this kind of ignorance which causes people to claim their applications is "safe because it's written in language ___"…

These exploits are not limited to languages like C, there have been examples from Java and JavaScript (both Chrome and Firefox)

Attacks using JavaScript.
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.

 

[Aquinus]

No, then you've proven you lack the basic understanding of how code is executed. Any code, even the most abstracted scripting language, is either compiled, JIT compiled or interpreted into assembly code. All abstractions and encapsulations are translated into normal memory addresses(pointers) which in turn is moved back and forth between memory and CPU registers. Any language is executed as normal ALU, FPU, conditionals, jumps, etc. on the machine code level. All the abstractions you see when you type your code is gone when it's actually executed on the CPU.

The abstractions in a language does not protect you when a CPU or a kernel have undefined behavior. And when there is a bug causing information leakage due to speculative execution, it doesn't matter if you control your memory allocation or not, since these exploits are about tricking the CPU to write privileged memory back to your unprivileged memory.

So it doesn't matter if your code is written in PHP, JavaScript, Python, Go, Rust, Java or whatever. As long as you either directly or indirectly can trigger the right system calls and the right operations within a timeframe after that, either directly or indirectly, the language is irrelevant. It's this kind of ignorance which causes people to claim their applications is "safe because it's written in language ___"…

These exploits are not limited to languages like C, there have been examples from Java and JavaScript (both Chrome and Firefox)

It was probably unnecessary to make this personal, but it's your prerogative to look like an ass.

For Spectre to actually be exploited you need to basically fake a branch that will cause an exception and it only sometimes works and depends on several factors. The way the JVM works makes this hard to exploit because of how Java bytecode gets executed. It is completely dependent on the JVM and there isn't really any way to use Java or any other JVM language to change that so, unless there is already an internal instruction in the JVM that not only causes this exploit to occur, but stores the value for you, then you're already out of luck. You can't just tell Java to access a memory location because you don't have that kind of control in the JVM, period, end of story. In fact you can't due to the nature of how the JVM works because the level at which you would have enough control is inside the JVM itself and the only way to get there is by recompiling the JVM. JavaScript on the other hand is a very different animal and is much closer to hardware than Java is because every aspect of it hasn't been abstracted away like it has been with Java. In fact, libraries for Node.js can be written in C to accelerate workloads and this is common for libraries in Node.js that demand performance. You can't really do that with Java short of using C bindings which are already a wonky thing in the JVM and are arguably still not as fast... it's also still going back to C to do it.

The amount of abstraction does in fact determine what you can do to the underlying host and it's very much so the case that JavaScript has far fewer abstractions between JS code itself and when it gets run on hardware... and as you said, timing for this bug is crucial and languages with more abstractions are even less likely to behave within the very short window you have to do something while a predicted branch is being preemptively executed and the amount of extra stuff something like the JVM does makes that window even smaller if it even gives the opportunity at all.

These exploits are not limited to languages like C, there have been examples from Java and JavaScript (both Chrome and Firefox)

Your quote talks about JavaScript, not Java, and the difference between the two platforms is important to understand why one is more vulnerable than the other. Simply put, JIT compilation in the JVM isn't fast enough for it to be a likely candidate for exploitation. You need better timing than what it offers and JavaScript JIT compiling in browsers these days are pretty damn fast and is far easier to control timing to be able to exploit spectre... and that does have a whole lot to do with why it is a better target than the JVM but, no higher level language will be more effective than using C because of how the exploit comes about.

...but please, continue to make this personal.

 

[R-T-B]

These law suits will just get thrown out of court or appealed then lost, its not like AMD has a hardware flaw like Intel CPU's have that can never be fixed.

Spectre is the one that can pretty much "never be fixed" not meltdown.