To view parent comment, click here.
To read all comments associated with this story, please click here.
I think you misunderstand the "obscurity" in the "security is not obtained by obscurity". Here, obscurity has nothing to do with the obscurity with the source code and, in some case, even the executable code. Here "obscurity" means lack transparency and straightforwardness.
I don't know what you mean by "crash more readily". Anti-exploit features do not prevent the crash, so it does not increase the stability. Either, it does not prevent a hacker from doing things malicious, but only slow him/her down. But as I said, time does not as much matter in exploiting as other attack-defense game. That's why I am skeptical about the anti-exploit.
In fact, in the exploiting world, there is a certain sort of bug which is by nature anti-exploiting. That's the heap corruption. Unlike stack, heap is dynamic, its location is almost random. So by natural a randomization feature is not too much obscure than a heap corruption. But even a heap corruption is attackable and there are a number of techniques to do so.




Member since:
2006-01-02
I think you have a misunderstanding here. Anti-exploit technologies usually aim to make the program crash more readily when it is exposed to malicious data. If the crash happens closer to the point of failure, it becomes easier to understand the bug and to debug problems. None of the mitigation techniques we use increase the obfuscation of the code.