An amusing security compromise is explained at
https://scarybeastsecurity.blogspot.co. ... sktop.html

The root cause is lazy and unsafe (or, high performance!) coding of banked ROM emulation in a NES emulator, which is, rather surprisingly, made widely available as part of a music playing library.

As noted in the article:
- 6502 is fun!
- there are many ways the risk could be removed or reduced by better system-level configuration choices
- there's really no need for such a niche capability to be installed so widely, especially based on a library known to be of indifferent quality
- the library need not have such unsafe coding in the first place

(via Kam-Yung Soh on gplus)

Thanks for sharing, that's a really cool exploit.

The part at the end about 6502 code as a "scripting language" and the prevalence of various languages in all sorts of places you wouldn't expect makes one think. There has to be an enormous attack surface here that gets little scrutiny.

I wouldn't expect that security is the top priority for many people, and allowing one's language or bytecode to poke around in memory is something that probably gets added for debugging reasons whether the application needs it or not.

I suspect security is the bottom priority!

I don't think the problem is usually that the scripting language intentionally gives too much access to the system - it's that when there is some tiny defect in the language or a library which allows even a single byte to be written when it shouldn't, it's the scripting language which gives the leverage to use the defect to make a full exploit.

How tiny a defect? Even a single character overflow, even if it's always just a '1', might be exploitable!
https://daniel.haxx.se/blog/2016/10/14/ ... n-exploit/

Sounds interesting, I will check that out.

Since we're already off topic, my favorite is this clever attack against a Java VM that assumes no conventional write access at all:

Using Memory Errors to Attack a Virtual Machine (PDF, sorry)

It works by allocating lots of objects in a way that basically fills memory with special bit patterns, and then waits for an external event to cause a single-bit memory corruption which it can exploit to get general write access. In their experiments, they were able to make it work using heat:



All typos mine. The entire thing is worth reading, the paper is written in a pretty clear style.

Ah, these days you don't even need heat! It turns out a lot of RAMs are vulnerable to bitflips caused by adjacent rows being flipped. It's called rowhammer. Even ECC doesn't save you - just makes it a bit harder. See for example
https://events.ccc.de/congress/2015/Fah ... /7197.html
where it turns out even a JavaScript program in your browser can provoke a disturbance and exploit it gain control of your machine. (Again, this is not a problem with JavaScript the language, or with the interpreter, rather it's a problem of leaky abstractions. Ideally your browser sandboxes each tab's activity, your OS implements protection between processes, and your memory acts like a memory ought to.)

You don't need heat for the JVM attack either, that was just the mechanism they used to speed up the process; the shocking aspect of it is that in theory the same attack should work without any physical access or leaky abstractions if you can just leave it for long enough to have a stray cosmic ray do its thing. Or a more practical approach, spread the exploit code to lots of machines and let the 0.01% on which it succeeds report back.

Rowhammer certainly did come up a lot in the first twenty tries to find an URL for the JVM attack though! :-)

I do recall that JVM research - it was remarkable that a single random bitflip could be exploited. As you say, could be parallelised too. But rowhammer changes the game somewhat. I suppose, as you say, even if and when RAM production is much less vulnerable to that, there will always be subatomic upsets to deal with.

I wonder if an approach using a dual RAM setup would protect against this. Or ideally, triple RAM. Use the two RAM sections that agree with each other, if no agreement, handle as RAM error. Maybe there should also be subtle differences in how this is set up, with either different RAM technology, or RAM placed so that there would be significant temperature differences.

I think the combination of ECC and more robust RAM technology should do it. I gather some brands and some models of RAM are (or were) more vulnerable to RowHammer. If ECC makes corruption one or two orders of magnitude less likely to be effective, that's significant.
I suppose it's also true that the application (or even OS) could add some checking code. (Indeed, I'm reminded of NetApp hard drives, which have (or had) custom firmware putting an extra CRC on every data block. In this case a sector holds 520 bytes.)
Defence in depth!