I'm not a security person but I'm fairly familiar with C/C++ and the internals of executables (at least for intel processors)Yep changing WD security settings has no impact on the exploit working. Things like DEP, ASLR, stack guards only work against specific forms of vulnerabilities.
Just as a basic example: if you allocate a struct on either the stack or the heap that contains a mix of function pointers and buffers, and then allow for a buffer overflow such that a buffer can spill onto a neighboring pointer within the same struct, there is almost nothing that can be bolted onto this after compilation that will guard against this attack. there is a new wave of technologies like authenticated pointers which can help mitigate these attacks but that is something that requires the program writer to opt into this at compile time and dramatically changes code generation.
Things that you can change at runtime are things like whether or not you allow the stack to contain code, how randomized malloc results are, and so on. They help guard against a different set of attacks.
(BTW my background is in system security through proactive security technologies and system design; BB’s and such represent a last line of defense if I have failed at my job!)
withing the same struct it's entirely unnoticeable indeed as the semantics could well be non-malicious, no BB can know that.onto a neighboring pointer within the same struct
But while a heap based attack like this is unnoticeable. a stack based attack where the return address is overwritten can be detected (?) e.g. I can't think of any C++ dev whose coding practices include going beyond the bounds of an array to overwrite the return address. The semantics here are clearly malicious.
not to remove the bite from the other attacks but I'd imagine this is fairly important for overflows, for the example you mentioned, where the overwrite is in the same struct, nothing can be done, but to reverse the argument, if all malloc results were deterministic/known exploiting other structs would be trivial. - I'd call this progress.how randomized malloc results are
I think we're on the same page but though e.g. I expected the old school stack based attacks to be detectable as overwriting a return address at runtime can only malicious.
I just remembered: back in the day when stack was executable, a junior had by mistake self-inserted a stack based buffer overrun on a string which he "fixed" by adding one more variable (whose value was overriden instead of the return address) :')