8 ms·

W^X now mandatory in OpenBSD

240 points by fcambus 10y ago

nightcracker 10y ago
What about JIT compilation and other forms of code generation?
- Steltek 10y ago
  Presumably that's why GCC, JDK, Mono, Chrome, etc are all in violation? Modifying your JIT to flip-flop between 'W' and 'X' seems like the naive fix but I imagine it ruins whatever hotspot tracing that may also be local to the JITted code.
- dchest 10y ago
  Firefox works fine with it: http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox/ http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-... After that, the performance overhead was pretty small on all benchmarks and websites I tested: Kraken and Octane are less than 1% slower with W^X enabled. On (ancient) SunSpider the overhead is bigger, because most tests finish in a few milliseconds, so any compile-time overhead is measurable. Still, it's less than 3% on Windows and Linux. On OS X it's less than 4% because mprotect is slower there.
cranium 10y ago
For those heading into the comments to know what this is about: W^X is a protection policy on memory with the effect that every page in memory can either be written or executed but not both simultaneously (Write XOR eXecute). It can prevent, for example, some buffer overflow attacks.
- CharlesMerriam2 10y ago
  I guess I've never understood this. The W^X is a response to one of the classic Multics paper attacks, but doesn't actually work well in a world where JavaScript, JVM byte code, and other non-native code is "sort-of executable". Why not put the effort into a great MMU so that every allocation is its own "page" for the purpose of triggering page faults on overruns?
  - nickpsecurity 10y ago
    There's already work on that sort of thing with crash-safe.org and Cambridge's CHERI. SVA-OS by Criswell et al to a degree. These kind of protections are for widespread use protecting legacy codebases they don't want to straight up fix or take performance hit of tools like Softbound+CETS. Incidentally, tradeoffs like that usually fail. ;)
  - epistasis 10y ago
    Won't it still work well for all that code that isn't actively translated code, which is probably the vast majority of software that's run on OpenBSD? >Why not put the effort into a great MMU The people who are writing for OpenBSD can not "put their effort" into hardware changes to entire platforms. They can do something to improve their own OS, however.
  - amelius 10y ago
    > Why not put the effort into a great MMU so that every allocation is its own "page" for the purpose of triggering page faults on overruns? Do you perhaps mean "every allocation is its own address space"? I guess that would require pointers that are double the size of regular pointers (the first half pointing to the address space, and the second half being an index into that space).
  - khedoros 10y ago
    Don't most of those end up JIT'd into native binary code, anyhow? The compiler would output code into a W page, then flip it to an X page and jump in. If it's just an interpreter, then the "sort-of executable" is just data being read, and the page can stay write-only.
  - stepvhen 10y ago
    Is this why JavaScript is deathly slow on my OpenBSD install and no the previous Arch Linux install?
    - dchest 10y ago
      No http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox/ http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-...
- _RPM 10y ago
  Further, XOR is an exclusive OR. In boolean logic, this means that the two values MUST be different. So 0 ^ 0 would 0, and 1 ^ 1 would also be 0. However, 1 ^ 0 would be 1.
  - PeCaN 10y ago
    > XOR > eXclusive OR Who would've thought.
    - _RPM 10y ago
      I was just trying to illustrate for the people that read HN that don't have CS backgrounds. Didn't mean to patronize you.
  - jameshart 10y ago
    Good point. It should probably be NAND: ~(W&X). Assuming that R is also a valid option, at least.
jtchang 10y ago
Does this mean to successfully exploit a program I need to write to an area in memory that the program will later turn the page in memory to "Execute"?
- eugeneionesco 10y ago
  Nope, just use return oriented programming.
  - notaplumber 10y ago
    OpenBSD has ROP, SROP mitigations, everything is compiled PIE. Even invented a static PIE variant for single-user and install media.
    - eugeneionesco 10y ago
      All of those are pretty much useless since the vast majority of vulnerabilities can be used to read arbitrary memory.
- PeCaN 10y ago
  Yep! That's the idea here: it makes it less likely to accidentally treat data as instructions. If you can figure out some bug in a JIT compiler to get it to write your payload to a page that will get turned executable, then you still have an exploit, but the attack surface is smaller. You can try return-oriented programming, but OpenBSD makes that hard: the stack is never executable, everything is position independent, objects get shuffled around inside libraries and executables¹, maybe more. ¹ At least this was proposed, and I think it landed in one of the newer releases, but I can't seem to find it for sure.
  - notaplumber 10y ago
    Yep: http://marc.info/?l=openbsd-cvs&m=146168291000757&w=2 http://marc.info/?l=openbsd-cvs&m=146168291000757&w=2
bch 10y ago
NetBSD is going through some similar security moves currently (extending PaX[0]), and iiuc, there are special considerations required for Java/jvm, because of the bytecoding process. Does anybody know if my understanding is correct (that a page will have to be both writable and executable) and if so, what are OpenBSDs considerations for this ? [0] http://mail-index.netbsd.org/current-users/2016/05/15/msg029374.html http://mail-index.netbsd.org/current-users/2016/05/15/msg029...
- koenigdavidmj 10y ago
  Allocate the page write-only. Write write write. Change the page to executable-only. Run. Firefox already got this treatment for its JavaScript compiler.
- Esau 10y ago
  Speaking as a NetBSD user, I hope Pkgsrc issues a warning prior to installing software that sets exemptions via paxctl. I would want to know.
sillysaurus3 10y ago
This paper's thesis is that W^X does not work, and not because of any of the reasons presented in this thread: https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf The paper says that to bypass W^X protection, you can simply scan an executable for "the instruction you want to use, followed by a RET". The paper calls these "gadgets." You can write any function you want by using these gadgets: simply call them. When you call a gadget, it executes the corresponding instruction, then returns. This allows you to write arbitrary functions, since real-world programs are large enough that they have a massive number of gadgets for you to choose from. Can someone provide a counterargument?
- cosarara97 10y ago
  How do you scan the executable when the memory layout is randomised? EDIT: https://news.ycombinator.com/item?id=11789653 https://news.ycombinator.com/item?id=11789653
  - tptacek 10y ago
    With any program behavior or bug that leaks memory layout. They're common.
  - monocasa 10y ago
    Via what's known as an "information disclosure vulnerability". Basically the program somehow leaks what address something ended up at.
  - cyphar 10y ago
    You need to have a memory disclosure bug (they're very common). You don't even need to be able to read all of memory, you just need to know the start offset of where the library is loaded (if the library is from a distribution you can download it and figure out the ROP offsets using the library -- though apparently OpenBSD has defences against that too).
- admax88q 10y ago
  W^X isn't a solution for all memory corruption bugs. Only some. What this paper describes is called ROP (return oriented programming). Theo has a different patch in OpenBSD to help mitigate that by re-linking the libraries at system startup, randomizing the location of most gadgets.
byuu 10y ago
I've always been in favor of all OpenBSD security enhancements I've seen, but I have to say, and please hear me out, this is an objectively terrible idea. Yes, most programs should disallow W|X by default. But trying to banish the entire practice with a mount flag, knowing full well few people will go that far to run a W|X application, is bad practice. I'd rather see this as another specialty chmod flag ala SUID, SGID, etc. Or something along those lines. One shouldn't have to enable filesystem-wide W|X just to run one application. The thing is, when you actually do need W|X, there is no simple workaround. Many emulators and JITs need to be able to dynamically recompile instructions to native machine code to achieve acceptable performance (emulating a 3GHz processor is just not going to happen with an interpreter.) For a particularly busy dynamic recompiler, having to constantly call mprotect to toggle the page flags between W!X and X!W will impact performance too greatly, since that is a syscall requiring a kernel-level transition. We also have app stores banning the use of this technique as well. This is a very troubling trend lately; it is throwing the baby out with the bathwater. EDIT: tj responded to me on Twitter: "the per-mountpoint idea is just an initial method; it'll be refined as time goes on. i think per-binary w^x is in the pipeline." -- that will not only resolve my concerns, but in fact would be my ideal design to balance security and performance.
- yoklov 10y ago
  > One shouldn't have to enable filesystem-wide W|X just to run one application This is a very good point, and it seems like enabling it more granularly would be worth it. But, for your second point, I have trouble believing that switching between W!X and X!W is going to happen frequently enough to be substantial for performance. (It was very small in Firefox's JavaScript JIT, causing something like a 1%-4% performance hit depending on system).
  - byuu 10y ago
    An emulator is a very different use case than Firefox's JIT. Take Dolphin (the Gamecube / Wii emulator) for example: you have a 4GiB DVD, it has a massive 80-hour game's entire code engine on there. You cannot recompile the entire disc at startup. Even if you could (you really can't), these games tend to push code into RAM to execute, which a static recompiler cannot handle. The way dynamic recompilers handle the tremendous burden is to recompile small blocks at a time, and track which ones are hot and cold. When the buffers fill up, they start dropping old, stale code. It's hard to say exactly what the performance impact would be, and it'd probably vary per game title. But it'd be a lot worse than a web browser recompiling jQuery plus another 200KiB of custom Javascript once on page load. Plus, I am sure there are many more uses cases for W|X than just emulators and JITs. It would be a shame to try and eradicate them all from existence.
malkia 10y ago
I dunno why, but this quote from Benjamin Fraklin came to m mind - “Those who surrender freedom for security will not have, nor do they deserve, either one.” i'm just kiddin ;)
anfroid555 10y ago
Anyone know if Erlang is good?
- yellowapple 10y ago
  I haven't tried it on -current yet, but I don't recall ever hearing about BEAM (Erlang's VM) being affected by this. It probably helps that BEAM inherits a lot of Erlang semantics like immutability and process isolation; I reckon this eliminates a lot of the need for a given portion of memory to be both writable and executable at the same time.
fithisux 10y ago
Can someone provide an introduction for dummies like me?
- terminalcommand 10y ago
  I am not an expert on the field. But | means or and ^ means execute. In the traditional W(rite)|(or)E(xecute) model, the processes can both write and execute instructions in their address space in memory. I might be wrong but I think this could result in security leaks, because you cannot determine what the code evolves into at execution time. W(rite)^(xor)E(xecute) model doesn't allow the processes to write AND execute instructions at the same time. The wikipedia page states: W^X requires using the CS code segment limit as a "line in the sand", a point in the address space above which execution is not permitted and data is located, and below which it is allowed and executable pages are placed. This means using W^X is an improvement for security, but it's hard to adapt to from a technical viewpoint and limits your computer's ability in meta-programming. For further information: https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX http://marc.info/?l=openbsd-misc&m=105056000801065 http://marc.info/?l=openbsd-misc&m=105056000801065 Disclaimer: I myself am a beginner in the field. Apologies for oversimplification and possible faulty assessments.
deleted 10y ago
[deleted]

240 points by fcambus 10y ago

nightcracker 10y ago

What about JIT compilation and other forms of code generation?

Steltek 10y ago
Presumably that's why GCC, JDK, Mono, Chrome, etc are all in violation? Modifying your JIT to flip-flop between 'W' and 'X' seems like the naive fix but I imagine it ruins whatever hotspot tracing that may also be local to the JITted code.
dchest 10y ago
Firefox works fine with it: http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox/ http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-... After that, the performance overhead was pretty small on all benchmarks and websites I tested: Kraken and Octane are less than 1% slower with W^X enabled. On (ancient) SunSpider the overhead is bigger, because most tests finish in a few milliseconds, so any compile-time overhead is measurable. Still, it's less than 3% on Windows and Linux. On OS X it's less than 4% because mprotect is slower there.

cranium 10y ago

For those heading into the comments to know what this is about: W^X is a protection policy on memory with the effect that every page in memory can either be written or executed but not both simultaneously (Write XOR eXecute). It can prevent, for example, some buffer overflow attacks.

CharlesMerriam2 10y ago
I guess I've never understood this. The W^X is a response to one of the classic Multics paper attacks, but doesn't actually work well in a world where JavaScript, JVM byte code, and other non-native code is "sort-of executable". Why not put the effort into a great MMU so that every allocation is its own "page" for the purpose of triggering page faults on overruns?
- nickpsecurity 10y ago
  There's already work on that sort of thing with crash-safe.org and Cambridge's CHERI. SVA-OS by Criswell et al to a degree. These kind of protections are for widespread use protecting legacy codebases they don't want to straight up fix or take performance hit of tools like Softbound+CETS. Incidentally, tradeoffs like that usually fail. ;)
- epistasis 10y ago
  Won't it still work well for all that code that isn't actively translated code, which is probably the vast majority of software that's run on OpenBSD? >Why not put the effort into a great MMU The people who are writing for OpenBSD can not "put their effort" into hardware changes to entire platforms. They can do something to improve their own OS, however.
- amelius 10y ago
  > Why not put the effort into a great MMU so that every allocation is its own "page" for the purpose of triggering page faults on overruns? Do you perhaps mean "every allocation is its own address space"? I guess that would require pointers that are double the size of regular pointers (the first half pointing to the address space, and the second half being an index into that space).
- khedoros 10y ago
  Don't most of those end up JIT'd into native binary code, anyhow? The compiler would output code into a W page, then flip it to an X page and jump in. If it's just an interpreter, then the "sort-of executable" is just data being read, and the page can stay write-only.
- stepvhen 10y ago
  Is this why JavaScript is deathly slow on my OpenBSD install and no the previous Arch Linux install?
  - dchest 10y ago
    No http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-firefox/ http://jandemooij.nl/blog/2015/12/29/wx-jit-code-enabled-in-...
_RPM 10y ago
Further, XOR is an exclusive OR. In boolean logic, this means that the two values MUST be different. So 0 ^ 0 would 0, and 1 ^ 1 would also be 0. However, 1 ^ 0 would be 1.
- PeCaN 10y ago
  > XOR > eXclusive OR Who would've thought.
  - _RPM 10y ago
    I was just trying to illustrate for the people that read HN that don't have CS backgrounds. Didn't mean to patronize you.
- jameshart 10y ago
  Good point. It should probably be NAND: ~(W&X). Assuming that R is also a valid option, at least.

jtchang 10y ago

Does this mean to successfully exploit a program I need to write to an area in memory that the program will later turn the page in memory to "Execute"?

eugeneionesco 10y ago
Nope, just use return oriented programming.
- notaplumber 10y ago
  OpenBSD has ROP, SROP mitigations, everything is compiled PIE. Even invented a static PIE variant for single-user and install media.
  - eugeneionesco 10y ago
    All of those are pretty much useless since the vast majority of vulnerabilities can be used to read arbitrary memory.
PeCaN 10y ago
Yep! That's the idea here: it makes it less likely to accidentally treat data as instructions. If you can figure out some bug in a JIT compiler to get it to write your payload to a page that will get turned executable, then you still have an exploit, but the attack surface is smaller. You can try return-oriented programming, but OpenBSD makes that hard: the stack is never executable, everything is position independent, objects get shuffled around inside libraries and executables¹, maybe more. ¹ At least this was proposed, and I think it landed in one of the newer releases, but I can't seem to find it for sure.
- notaplumber 10y ago
  Yep: http://marc.info/?l=openbsd-cvs&m=146168291000757&w=2 http://marc.info/?l=openbsd-cvs&m=146168291000757&w=2

bch 10y ago

NetBSD is going through some similar security moves currently (extending PaX[0]), and iiuc, there are special considerations required for Java/jvm, because of the bytecoding process. Does anybody know if my understanding is correct (that a page will have to be both writable and executable) and if so, what are OpenBSDs considerations for this ? [0] http://mail-index.netbsd.org/current-users/2016/05/15/msg029374.html http://mail-index.netbsd.org/current-users/2016/05/15/msg029...

koenigdavidmj 10y ago
Allocate the page write-only. Write write write. Change the page to executable-only. Run. Firefox already got this treatment for its JavaScript compiler.
Esau 10y ago
Speaking as a NetBSD user, I hope Pkgsrc issues a warning prior to installing software that sets exemptions via paxctl. I would want to know.

sillysaurus3 10y ago

This paper's thesis is that W^X does not work, and not because of any of the reasons presented in this thread: https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf https://cseweb.ucsd.edu/~hovav/dist/geometry.pdf The paper says that to bypass W^X protection, you can simply scan an executable for "the instruction you want to use, followed by a RET". The paper calls these "gadgets." You can write any function you want by using these gadgets: simply call them. When you call a gadget, it executes the corresponding instruction, then returns. This allows you to write arbitrary functions, since real-world programs are large enough that they have a massive number of gadgets for you to choose from. Can someone provide a counterargument?

cosarara97 10y ago
How do you scan the executable when the memory layout is randomised? EDIT: https://news.ycombinator.com/item?id=11789653 https://news.ycombinator.com/item?id=11789653
- tptacek 10y ago
  With any program behavior or bug that leaks memory layout. They're common.
- monocasa 10y ago
  Via what's known as an "information disclosure vulnerability". Basically the program somehow leaks what address something ended up at.
- cyphar 10y ago
  You need to have a memory disclosure bug (they're very common). You don't even need to be able to read all of memory, you just need to know the start offset of where the library is loaded (if the library is from a distribution you can download it and figure out the ROP offsets using the library -- though apparently OpenBSD has defences against that too).
admax88q 10y ago
W^X isn't a solution for all memory corruption bugs. Only some. What this paper describes is called ROP (return oriented programming). Theo has a different patch in OpenBSD to help mitigate that by re-linking the libraries at system startup, randomizing the location of most gadgets.

byuu 10y ago

I've always been in favor of all OpenBSD security enhancements I've seen, but I have to say, and please hear me out, this is an objectively terrible idea. Yes, most programs should disallow W|X by default. But trying to banish the entire practice with a mount flag, knowing full well few people will go that far to run a W|X application, is bad practice. I'd rather see this as another specialty chmod flag ala SUID, SGID, etc. Or something along those lines. One shouldn't have to enable filesystem-wide W|X just to run one application. The thing is, when you actually do need W|X, there is no simple workaround. Many emulators and JITs need to be able to dynamically recompile instructions to native machine code to achieve acceptable performance (emulating a 3GHz processor is just not going to happen with an interpreter.) For a particularly busy dynamic recompiler, having to constantly call mprotect to toggle the page flags between W!X and X!W will impact performance too greatly, since that is a syscall requiring a kernel-level transition. We also have app stores banning the use of this technique as well. This is a very troubling trend lately; it is throwing the baby out with the bathwater. EDIT: tj responded to me on Twitter: "the per-mountpoint idea is just an initial method; it'll be refined as time goes on. i think per-binary w^x is in the pipeline." -- that will not only resolve my concerns, but in fact would be my ideal design to balance security and performance.

yoklov 10y ago
> One shouldn't have to enable filesystem-wide W|X just to run one application This is a very good point, and it seems like enabling it more granularly would be worth it. But, for your second point, I have trouble believing that switching between W!X and X!W is going to happen frequently enough to be substantial for performance. (It was very small in Firefox's JavaScript JIT, causing something like a 1%-4% performance hit depending on system).
- byuu 10y ago
  An emulator is a very different use case than Firefox's JIT. Take Dolphin (the Gamecube / Wii emulator) for example: you have a 4GiB DVD, it has a massive 80-hour game's entire code engine on there. You cannot recompile the entire disc at startup. Even if you could (you really can't), these games tend to push code into RAM to execute, which a static recompiler cannot handle. The way dynamic recompilers handle the tremendous burden is to recompile small blocks at a time, and track which ones are hot and cold. When the buffers fill up, they start dropping old, stale code. It's hard to say exactly what the performance impact would be, and it'd probably vary per game title. But it'd be a lot worse than a web browser recompiling jQuery plus another 200KiB of custom Javascript once on page load. Plus, I am sure there are many more uses cases for W|X than just emulators and JITs. It would be a shame to try and eradicate them all from existence.

malkia 10y ago

I dunno why, but this quote from Benjamin Fraklin came to m mind - “Those who surrender freedom for security will not have, nor do they deserve, either one.” i'm just kiddin ;)

anfroid555 10y ago

Anyone know if Erlang is good?

yellowapple 10y ago
I haven't tried it on -current yet, but I don't recall ever hearing about BEAM (Erlang's VM) being affected by this. It probably helps that BEAM inherits a lot of Erlang semantics like immutability and process isolation; I reckon this eliminates a lot of the need for a given portion of memory to be both writable and executable at the same time.

fithisux 10y ago

Can someone provide an introduction for dummies like me?

terminalcommand 10y ago
I am not an expert on the field. But | means or and ^ means execute. In the traditional W(rite)|(or)E(xecute) model, the processes can both write and execute instructions in their address space in memory. I might be wrong but I think this could result in security leaks, because you cannot determine what the code evolves into at execution time. W(rite)^(xor)E(xecute) model doesn't allow the processes to write AND execute instructions at the same time. The wikipedia page states: W^X requires using the CS code segment limit as a "line in the sand", a point in the address space above which execution is not permitted and data is located, and below which it is allowed and executable pages are placed. This means using W^X is an improvement for security, but it's hard to adapt to from a technical viewpoint and limits your computer's ability in meta-programming. For further information: https://en.wikipedia.org/wiki/W%5EX https://en.wikipedia.org/wiki/W%5EX http://marc.info/?l=openbsd-misc&m=105056000801065 http://marc.info/?l=openbsd-misc&m=105056000801065 Disclaimer: I myself am a beginner in the field. Apologies for oversimplification and possible faulty assessments.

deleted 10y ago

[deleted]