[VIM] standards for inclusion of DoS attacks

[Steven M. Christey]

The Editorial Board had some discussion on this a number of years ago,
encoded roughly in the "EX-CLIENT-DOS" content decision.  It said roughly
"exclude DoS on a client unless it is persistent."  One problem with this
was that potential buffer overflows could be excluded based on symptoms
only (does a recent IE bug ring a bell?).  Plus a fairly large number of
VDB's include them, so CVE's role as communications facilitator sort of
led us to start including most DoS.

DoSes in other product classes were not really discussed.  generally I'm
of the mindset that a "normal" user shouldn't be allowed to

  (1) do something that impacts other users (e.g. halt someone else's
     processes by causing a kernel crash)

  (2) slow down the system or otherwise consume more resources beyond that
      which is "reasonable" - a bit fuzzy here, but asymmetric
      algorithmic complexity attacks come to mind, log filling etc.

  (3) "hog" or control a set of resources that is intended for another
      party and/or to be shared by multiple parties

  (4) conduct any sort of persistent DoS that is not immediately
      recoverable by the typical user

Memory leaks - if attacker-controllable (which most probably are) - fall
under legitimate DoS for me.  If in 5 or 10 years all operating systems
with widely-implemented, well-managed process memory restrictions then
maybe that will be different.

Reading things from changelogs is difficult, specifically because the role
of an attacker is rarely specified.  In these cases, if some other VDB
notes it, I'll probably add a note in the CVE description - at the very
least mentioning unknown attack vectors, and probably saying "this might
not be a vuln."

At some point the line between security and reliability gets very fuzzy,
and it varies for different customers.

This is ESPECIALLY the case for crashes due to un-analyzed malformed
inputs.  "I piped /dev/random through netcat to product X and all I got
was this lousy crash" issues are almost always undiagnosed and *might* be
some more serious issue underneath - remember when heap overflows weren't
exploitable, or when people manipulated array indexes without sufficiently
realizing they could modify arbitrary memory?  So given the immaturity of
analysis, it seems safest to include most DoS unless (a) the impact is
restricted entirely to the attacker and/or (b) recoverable without any
loss by the victim.  So if you have a multi-threaded server and an attack
causes a crash in the attacker's own thread but the thread is
automatically restarted, that's not really a DoS to me.


- Steve