

Improving browser security - stsp
http://marc.info/?l=openbsd-misc&m=142523501726732&w=2

======
ahomescu1
I wonder if he's aware of this NDSS 2015 paper:
[http://www.internetsociety.org/doc/exploiting-and-
protecting...](http://www.internetsociety.org/doc/exploiting-and-protecting-
dynamic-code-generation)

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).

------
schoen
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?

~~~
azakai
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.

~~~
justincormack
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.

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

~~~
sanxiyn
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.

------
chrisrohlf
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.

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

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

Java Python (PyPy) Qemu Valgrind PCSX Yabause Mupen64plus

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

------
higherpurpose
> 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.

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

