Which is the best behavioral blocker

  • DeepGuard

    Votes: 4 5.9%
  • SONAR

    Votes: 29 42.6%
  • System Watcher

    Votes: 35 51.5%
  • Total voters
    68
  • Poll closed .
Products to compare
Symantec Endpoint Security Cloud
Kaspersky Security Cloud Family
F-secure Internet Security
Compare
Usability
Performance and System Impact
Proactive protection (Behavior blocker, HIPS, Sandbox)
Ransomware protection
Banking & Payments protection

notabot

Level 15
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!)
I'm not a security person but I'm fairly familiar with C/C++ and the internals of executables (at least for intel processors)

onto a neighboring pointer within the same struct
withing the same struct it's entirely unnoticeable indeed as the semantics could well be non-malicious, no BB can know that.

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.

how randomized malloc results are
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.

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) :')
 

notabot

Level 15
Detection of stack based attacks are still hard, and trust me, I’ve written at least one major OS’s implementation of return control flow hijacking detection ;)

No processor architecture allows sampling every function return and control flow change in order to track them. Some tool chains allow emitting of jump and return checkers that their C runtimes can implement but they can be extremely performance penalizing. And once again without processor level features like authenticated jump and return instructions it is still possible to detect.
Also the format of a stack frame is very much dependent on the compiler and optimizer, especially in user space. And no processor has enough watch points that you can realistically introspect every single attempt to overwrite what looks like a frame pointer.

BTW no behavior blocker does any of this kind of checking. This is the job of the OS, the C/C++ runtime, and the compiling tool chain. Windows Defender now “owns” a lot of the runtime gardening settings that used to be tucked away in other Windows preferences but that IMO is not to be considered a behavior blocker. In general a behavior blocker is looking at process to outside interactions: syscalls, inter process communication attempts, accesses to resources like the network and filesystem and registry, etc. Even exploit detectors are really looking for external behavior of a process. None of them monitor the internals of a process.
Thanks, very good post, and what you say makes sense, if the return address is not exposed in a reasonable manner by the processor, monitoring overrides becomes a pita (though given that this is a well known issue for 20 years now, maybe even more, they should had done something about it )
 

notabot

Level 15
Hey on the bright side, things are being done! For a few years now, ARM has defined a spec and made a handful of CPUs that support authentication in both the jump and return directions. Changes like that don’t happen overnight especially since few customers tolerate the idea that they switch to incompatible CPU architectures every 2-3 years and leave all older programs behind!
Does intel plan something similar ?
They are clearly doing security related work, ie SGX is very interesting for remote attestation and for holding in-enclave-memory keys etc but haven't come across anything related to execution security.