4 ms·

Which is their "One Job" ? Options include: 1. protected the systems always work even if things are messed up 2. protected systems are always protected even

by cduzz 2y ago

Which is their "One Job" ? Options include: 1. protected the systems always work even if things are messed up 2. protected systems are always protected even when things are messed up The two failure modes are exclusive; ideally you let the end user decide what to do if the protection mechanism is itself unstable. One could suggest "the system must always work" but that's ignoring that sometimes things don't go to plan. None of the systems in boot loops were p0wned by known exploits while they were boot looping. As far as we know anyhow. (edited to add the obvious default of "just make a working system" which is of course both a given and not going to happen)

jmb99 2y ago
The failure mode here was a page fault due to an invalid definition file. That (likely) means the definition file was being used as-is without any validation, and pointers were being dereferenced based on that non-validated definition file. That means this software is likely vulnerable to some kind of kernel-level RCE through its definition files, and is (clearly) 100% vulnerable to DoS attacks through invalid definition files. Who knows how long this has been the case. This isn’t a matter of “either your system is protected all the time, even if that means it’s down, or your system will remain up but might be unprotected.” It’s “your system is vulnerable to kernel-level exploits because of your AV software’s inability to validate definition files.” The failure mode here should absolutely not be to soft-brick the machine. You can have either of your choices configurable by the sysadmin; definition file fails to validate? No problem, the endpoint has its network access blocked until the problem can be resolved. Or, it can revert to a known-good definition, if that’s within the organization’s risk tolerance. But that would require competent engineering, which clearly was not going on here.
- cduzz 2y ago
  Well.... yeah, incuriously shoving unsigned data from elsewhere into ring 0 and executing it is malpractice.
EvanAnderson 2y ago
Their "one job" is to not make things worse than the default. DoS'ing the OS with an unhandled kernel mode exception would be not doing that job. How about a different analogy: First do no harm.

by cduzz 2y ago

jmb99 2y ago

The failure mode here was a page fault due to an invalid definition file. That (likely) means the definition file was being used as-is without any validation, and pointers were being dereferenced based on that non-validated definition file. That means this software is likely vulnerable to some kind of kernel-level RCE through its definition files, and is (clearly) 100% vulnerable to DoS attacks through invalid definition files. Who knows how long this has been the case. This isn’t a matter of “either your system is protected all the time, even if that means it’s down, or your system will remain up but might be unprotected.” It’s “your system is vulnerable to kernel-level exploits because of your AV software’s inability to validate definition files.” The failure mode here should absolutely not be to soft-brick the machine. You can have either of your choices configurable by the sysadmin; definition file fails to validate? No problem, the endpoint has its network access blocked until the problem can be resolved. Or, it can revert to a known-good definition, if that’s within the organization’s risk tolerance. But that would require competent engineering, which clearly was not going on here.

cduzz 2y ago
Well.... yeah, incuriously shoving unsigned data from elsewhere into ring 0 and executing it is malpractice.

EvanAnderson 2y ago

Their "one job" is to not make things worse than the default. DoS'ing the OS with an unhandled kernel mode exception would be not doing that job. How about a different analogy: First do no harm.