Great overview. The title is somewhat misleading, though. Deterministic behaviors are a defender’s best asset, as well. If doing high-assurance security, you keep the code as deterministic as possible so it’s as easy to analyze as possible. Then, you can do formal methods, static analyzers, fuzzers, etc to show it behaves according to spec. Then, it does when fielded unless you’re tools were broken or a new class of error appears.
If you don’t assure code like that, then it behaves in potentially harmful ways on malicious input. And then you need all the non-determinism in the slide deck or other security mitigations. That they don’t or can’t assure their code to that degree is why they need it. However, it’s also useful as an extra layer of defense for unknown attacks or failures of other methods (eg hardware failures).
I’ll note there is a whole sub-field of CompSci dedicated to automatic obfuscation of programs, often with compilers. You can code in deterministic way with program analysis and testing to assure the code. Then, the special compilers turn it into something that gives opponents extra headaches without any headaches on developer’s part. That’s where people wanting program obfuscation should probably be putting effort in. Heck, there’s even organizations like NSF and DARPA funding it. Get paid to work on OpenBSD, err, to “develop and prototype obfuscation technologies for protecting our infrastructure from the Russian and Chinese hackers.” Hehe.
I’d actually argue that the compiler based focus for security properties is actually what the PaX/Grsecurity project has been doing since they started to heavily rely on GCC plugins for newer features. Additionally, I think the link and execution randomization is not dependent on the executables and the code being randomized, and can be created in a reproducible manner. I’ve had to debug quite a few crashes (looking at you iked(1) config parser) and all of these memory protections don’t realistically get in my way much for debugging.
Nice to see the differentiation between ASR and ASLR.
Great overview. The title is somewhat misleading, though. Deterministic behaviors are a defender’s best asset, as well. If doing high-assurance security, you keep the code as deterministic as possible so it’s as easy to analyze as possible. Then, you can do formal methods, static analyzers, fuzzers, etc to show it behaves according to spec. Then, it does when fielded unless you’re tools were broken or a new class of error appears.
If you don’t assure code like that, then it behaves in potentially harmful ways on malicious input. And then you need all the non-determinism in the slide deck or other security mitigations. That they don’t or can’t assure their code to that degree is why they need it. However, it’s also useful as an extra layer of defense for unknown attacks or failures of other methods (eg hardware failures).
I’ll note there is a whole sub-field of CompSci dedicated to automatic obfuscation of programs, often with compilers. You can code in deterministic way with program analysis and testing to assure the code. Then, the special compilers turn it into something that gives opponents extra headaches without any headaches on developer’s part. That’s where people wanting program obfuscation should probably be putting effort in. Heck, there’s even organizations like NSF and DARPA funding it. Get paid to work on OpenBSD, err, to “develop and prototype obfuscation technologies for protecting our infrastructure from the Russian and Chinese hackers.” Hehe.
I’d actually argue that the compiler based focus for security properties is actually what the PaX/Grsecurity project has been doing since they started to heavily rely on GCC plugins for newer features. Additionally, I think the link and execution randomization is not dependent on the executables and the code being randomized, and can be created in a reproducible manner. I’ve had to debug quite a few crashes (looking at you
iked(1)config parser) and all of these memory protections don’t realistically get in my way much for debugging.Good point. Appreciate info on debugging.
Too bad people got to program everything in languages that are deterministic.
If you consider their behaviour across a wide variety of different hardware combinations, a lot of programming languages are pretty non-deterministic