4 ms·

Rather than looking for a new language, why not ban programs from writing to executable memory?

by dhsjxhx 10y ago

twic 10y ago
Because that isn't enough: https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming
bvinc 10y ago
I'm not an expert in this field, but it's my understanding that this is often the case for C programs executing nowadays. The AMD64 architecture even has the NX bit. There are some other ways that this can be enabled too. But surprisingly, this doesn't solve all code execution security problems from buffer overflows. Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program. But even if you solve the security issues, buffer overflows are still a huge headache. A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened. A developer can easily spend weeks tracking down a single buffer overflow crash.
- dhsjxhx 10y ago
  >A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened. I don't know about rust, but you can have an ArrayOutOfBoundsException in Java, and equivalent in Go and other safe languages
- nullc 10y ago
  > Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program. Changing function pointers or the return value on the stack are the normal things to do. In particular if you corrupt the stack you can simply return into system() with whatever arguments you want.
stusmall 10y ago
This wouldn't protect from bugs where you can maliciously trick a program from reading from other places in memory so it will leak passwords, keys etc. Think heartbleed
jjnoakes 10y ago
That is done already in many cases. Note that doing that doesn't fix all of the problems that out of bounds array writes can cause though.

Rather than looking for a new language, why not ban programs from writing to executable memory?

by dhsjxhx 10y ago

Rather than looking for a new language, why not ban programs from writing to executable memory?

twic 10y ago

Because that isn't enough: https://en.wikipedia.org/wiki/Return-oriented_programming https://en.wikipedia.org/wiki/Return-oriented_programming

bvinc 10y ago

I'm not an expert in this field, but it's my understanding that this is often the case for C programs executing nowadays. The AMD64 architecture even has the NX bit. There are some other ways that this can be enabled too. But surprisingly, this doesn't solve all code execution security problems from buffer overflows. Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program. But even if you solve the security issues, buffer overflows are still a huge headache. A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened. A developer can easily spend weeks tracking down a single buffer overflow crash.

dhsjxhx 10y ago
>A one byte buffer overflow can cause your program to crash an hour later, with almost no hope of figuring out why it happened. I don't know about rust, but you can have an ArrayOutOfBoundsException in Java, and equivalent in Go and other safe languages
nullc 10y ago
> Sometimes exploiters can find non-executable memory to change that allows them to change the program behavior to do what they want, such as changing the command string that gets passed to a normal execve call later in the program. Changing function pointers or the return value on the stack are the normal things to do. In particular if you corrupt the stack you can simply return into system() with whatever arguments you want.

stusmall 10y ago

This wouldn't protect from bugs where you can maliciously trick a program from reading from other places in memory so it will leak passwords, keys etc. Think heartbleed

jjnoakes 10y ago

That is done already in many cases. Note that doing that doesn't fix all of the problems that out of bounds array writes can cause though.