Linked by Thom Holwerda on Fri 20th Mar 2009 13:51 UTC, submitted by google_ninja
Permalink for comment 354521
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
More News »
Sponsored Links



Member since:
2006-05-11
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.