3 ms·

There's also a counter-point: Harvard architectures are more secure. If the application has the ability to execute data as native code, attackers will find a wa

There's also a counter-point: Harvard architectures are more secure. If the application has the ability to execute data as native code, attackers will find a way to exploit that.

vardump 11y ago
Until someone uses ROP-widgets turning stack return addresses into executing what the attacker wants. Doesn't matter if there are no pages that are both writable and executable. Besides, any secure JIT will only keep a page either writable or executable, but not both in the same time. http://en.wikipedia.org/wiki/Return-oriented_programming http://en.wikipedia.org/wiki/Return-oriented_programming
- latiera 11y ago
  It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated). With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written. Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it.
- quotemstr 11y ago
  latiera, you seem to be banned for some reason. Both of your comments are dead. I'll quote your post in full. > It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated). > With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written. > Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it. Of course ASLR makes ROP harder. It makes all exploits harder. I still don't agree with your last paragraph. As someone else mentioned, good JIT implementations never leave code both writable and executable. It's simply not the case that "page permissions are irrelevant". Page permissions are central because they defeat the specific attacks you have in mind. A JIT is no more vulnerable to them than the dynamic loader is. I still don't buy that banning PROT_EXEC buys you any protection from attackers exploiting applications. On the other hand, banning PROT_EXEC provides plenty of protection against uppity application developers trying to "abuse" the platform you "own" by attempting to program in unapproved ways.
  - vardump 11y ago
    Exactly. To add, nothing prevents from allocating pages from random addresses to get protection similar to ASLR. It can actually be harder to attack dynamically generated code, because instruction offsets and instructions used will vary from application invocation to another. You could even do intentional variations to ensure no relative instruction offsets are deterministic. So dynamically generated code can have not only have random address (ASLR) but also random relative offsets. Obviously statically compiled code must have those offsets static, known by the attacker. ASLR just means you don't necessarily know where. But once the attacker knows where or has some clever trick so it doesn't matter, it's game over. Unfortunately the creativity of attackers getting around ASLR seems to be endless.
- deleted 11y ago
  [deleted]
- ahomescu1 11y ago
  > Until someone uses ROP-widgets turning stack return addresses into executing what the attacker wants. That's like saying there's no point in locking your doors because thieves can go in through the window. Instead, you're better off applying separate defenses against separate attacks: read-only code against code injection and other defenses (like CFI or randomization) against ROP. > Besides, any secure JIT will only keep a page either writable or executable, but not both in the same time. Sure, but it's amazing how few actual JITs do that. V8, for example, actually maps its entire code cache as RWX.

There's also a counter-point: Harvard architectures are more secure. If the application has the ability to execute data as native code, attackers will find a way to exploit that.

vardump 11y ago

Until someone uses ROP-widgets turning stack return addresses into executing what the attacker wants. Doesn't matter if there are no pages that are both writable and executable. Besides, any secure JIT will only keep a page either writable or executable, but not both in the same time. http://en.wikipedia.org/wiki/Return-oriented_programming http://en.wikipedia.org/wiki/Return-oriented_programming

latiera 11y ago
It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated). With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written. Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it.
quotemstr 11y ago
latiera, you seem to be banned for some reason. Both of your comments are dead. I'll quote your post in full. > It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated). > With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written. > Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it. Of course ASLR makes ROP harder. It makes all exploits harder. I still don't agree with your last paragraph. As someone else mentioned, good JIT implementations never leave code both writable and executable. It's simply not the case that "page permissions are irrelevant". Page permissions are central because they defeat the specific attacks you have in mind. A JIT is no more vulnerable to them than the dynamic loader is. I still don't buy that banning PROT_EXEC buys you any protection from attackers exploiting applications. On the other hand, banning PROT_EXEC provides plenty of protection against uppity application developers trying to "abuse" the platform you "own" by attempting to program in unapproved ways.
- vardump 11y ago
  Exactly. To add, nothing prevents from allocating pages from random addresses to get protection similar to ASLR. It can actually be harder to attack dynamically generated code, because instruction offsets and instructions used will vary from application invocation to another. You could even do intentional variations to ensure no relative instruction offsets are deterministic. So dynamically generated code can have not only have random address (ASLR) but also random relative offsets. Obviously statically compiled code must have those offsets static, known by the attacker. ASLR just means you don't necessarily know where. But once the attacker knows where or has some clever trick so it doesn't matter, it's game over. Unfortunately the creativity of attackers getting around ASLR seems to be endless.
deleted 11y ago
[deleted]
ahomescu1 11y ago
> Until someone uses ROP-widgets turning stack return addresses into executing what the attacker wants. That's like saying there's no point in locking your doors because thieves can go in through the window. Instead, you're better off applying separate defenses against separate attacks: read-only code against code injection and other defenses (like CFI or randomization) against ROP. > Besides, any secure JIT will only keep a page either writable or executable, but not both in the same time. Sure, but it's amazing how few actual JITs do that. V8, for example, actually maps its entire code cache as RWX.