Hacker News Reader

Hacker News

Comment by kpcyrd | Hacker News Reader

Full thread

kpcyrd

In other news, the next firefox release is going to have W^X

https://www.mozilla.org/en-US/firefox/46.0beta/releasenotes/

http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-...

View on HN

W^X stands for "writable xor executable":

> What this means is that each page holding JIT code is either executable or writable, never both at the same time.

For anybody, like me, who didn't already know :)

Forgive my ignorance -- what does this achieve?

If an attacker is able to write arbitrary code through to memory, they won't then be able to actually execute that code.

It's a solid security enhancement.

Forgive my naivete, isn't that feature provided by the operating system?

It is provided by the operating system, but you can't just naively enable it by default, especially in an application like Firefox (which has a JIT compiler for Javascript, and therefore needs to be aware of and able to manage which pages are writable and which pages are executable).

Software has to play nice and not request WX pages. If they do, the OS does as its asked.

See also, Theo de Raadt's recent comment on why OSes can't enforce W^X on userland (yet): https://marc.info/?l=openbsd-misc&m=145943630726937&w=2

That you can't have a bug in your code that lets an attacker overwrite data (aka a buffer overflow writes into memory) AND have that part of memory executed. It's either data (which can be overwritten) or code (which can't be overwritten).

It's not a fool proof mitigation for buffer overflow attacks, though. You can still write a bogus return address in a stack overflow and use return oriented programming (ROP) to do exploits with W^X. There are ways to work around address space layout randomization (ASLR) too.

No methodology in Infosec is every 100% prefect. You nest your defenses like Russian Dolls.

Each layer of protection fends off another class of attackers.

An attacker with infinite determination, money, or time will always push past your defenses.

in reality, at some point it's just not cost effective anymore (for the attacker) and other targets become more promising.

None of these mitigations is perfect. But how do you combine a exploit that has to deal with W^X, ASLR, randomized stack gap, stack cookie, randomized location of shared libraries and static programs. Seems pretty hard to me.

> In other news, the next firefox release is going to have W^X

That's nice and all, but if the people behind firefox keep on taking away the features that convince people to use it (Panorama, for starters) then these little accomplishments don't accomplish much.

It's always been Firefox's position that features that don't get used by very many people are better off as add-ons. That way you don't end up with a browser with 1,000 features each of which adds complexity and slows development. The official recommendation is to use this add-on, which was created from the original Firefox Panorama code. http://fasezero.com/addons/

Edit: The page that made the above recommendation https://support.mozilla.org/en-US/kb/tab-groups-removal

That's fine, until they decided to neuter their add-on API.

As long as they're committed to maintaining the feature add-ons under the new API I couldn't care less how it works under the hood.

Regarding Panorama, I was and still am a huge Panorama user and the extension they replaced it with works just as well. Stuff like that is cleaner as an extension anyway (which of course begs the question of why the hell Pocket and Hello aren't extensions).

Reply on news.ycombinator.com