Improving browser security | Hacker News Reader

Improving browser security

marc.info

51 pointsstsp13 comments

I wonder if he's aware of this NDSS 2015 paper: http://www.internetsociety.org/doc/exploiting-and-protecting...

TL;DR version: the JIT becomes a separate process that maps the code cache as RW, while the browser itself only sees a RX mapping. They also discuss why flipping between RW and RX in the same process is insecure (basically, TOCTTOU attacks from different threads).

So, this note says that browser JITs are the main thing that typically needs writable and executable memory right now, and the author (Ted Unangst) is going to try to fix that.

It seems natural to think that JITs would want that feature (so they can compile things into native code and then jump into it). Can someone who has worked with DOM rendering or Javscript interpreters opine on whether it's plausible to get rid of the use of write+execute memory segments without sacrificing a lot of performance?

On Firefox and WebKit (but not Chrome) you can already do that, by disabling the JIT and thereby only running in the interpreter.

You do lose a large amount of speed on sites that have JS doing heavy things. However, on a lot of the web, you don't need heavy JS, so you might not notice it on a news site or your email site. Try to play a game, though, and it'll be obvious.

No the idea is you set memory to write permission only, write out the jitted code, and switch the memory to execute, no write before you execute it. It simply means more calls to change memory protection, which is on page size granularity so may mean using a whole page for each jitted fragment.

How do you support self-modifying code like ICs then?

When patching IC, first set code page to W. Patch. Then set code page to X.

It sounds expensive, and it is. ~3% regression on SunSpider is reported. Mozilla is probably not okay with that, but OpenBSD probably is.

Nearly every browser engine has or had patches at one time to accomplish this. Its a call to mprotect/VirtualProtect after writing native code to memory. Theres a performance hit to JIT engines that update emitted code often due to dynamic JS typing. You could always just turn off the JIT engine and execute the slower bytecode. But thanks for coming down from the mountain to enlighten us, again.

Heres Chris Leary's patch for Firefox. A bit dated at this point though https://bugzilla.mozilla.org/show_bug.cgi?id=677272

Did you even read the email? It is explicitly stated that W^X modifiable with mprotect is something they are seeking to eliminate.

Due to timing issues its essentially impossible for the concept you laid out to ever provide reliable mitigation inside a program that is throwing mprotect around in a multi-threaded environment anyways.

Not just browsers. Some other common packages that also use JIT include:

Java Python (PyPy) Qemu Valgrind PCSX Yabause Mupen64plus

Fixing open source JITs to support Windows x64 SEH properly is on my wishlist for MS Open Tech.

> The policy has remained advisory because many JIT engines use such memory and enforcing mandatory W^X would mean such programs no longer run on OpenBSD

It really annoys me to see something like this. "Oh, well we didn't upgrade our OS to that much more secure feature because it would've meant breaking compatibility with a few popular apps...2 decades ago".

My point is whether it breaks compatibility or not is irrelevant. The solution is simple: set a reasonable but very clear deadline for when you'll adopt that feature and those apps will stop working unless they adapt. You could make it 1 year, 2 years or even 5 years, depending on how big of a change you're requiring of those developers.

But not doing it at all because it would break compatibility with some apps is just inexcusable to me. I'm also quite disappointed Microsoft hasn't implemented all the EMET features into Windows 10 and may not even consider doing it until Windows 12.

Mozilla doesn't care if Firefox works on OpenBSD or not.

Reply on news.ycombinator.com