[VIM] standards for inclusion of DoS attacks

[security curmudgeon]

Does anyone have any thoughts, debates or even policy on what consitutes a 
'DoS attack', in the context for inclusion into a VDB?

I ask for a specific reason that comes up every month or so. What prompted 
this one:

   http://www-1.ibm.com/support/docview.wss?uid=swg27007054

This is a gnarly changelog of sorts. There are clearly security issues in 
here that will appear in every database. Secunia breaks out 7 entries in 
SA18328. My once through says OSVDB may have ~ 10 based on their 7.

My second pass lead to this post. If you read through this changelog, you 
begin to see countless "crashes" and "memory leaks". Many of them suggest 
that an unprivileged user could manipulate the error to force the crash, 
some don't give any hint as to the privileges required to abuse it.

I see both sides of the debate to include every single one. First, it is a 
legitimate attack against a system, with the potential to disrupt the 
service or user activity, without authorization. No matter how trivial, a 
clever attacker could use it. If you look at the entries most of us 
maintain for Linux Kernel DoS issues, a lot of them are akin to these. 
They take a fairly specific configuration or kernel compilation, local 
access to the machine (usually), and a knowledgable attacker. As such, 
they get entries in the VDB. Yet in the past, we have all glossed over 
these changelogs, typically from the big vendors like IBM, HP or Sun. That 
leads into the other side of the argument.

Second, the computer industry is not at a stage where we have stable 
software for the most part. Programs are still horrible at sanitizing user 
input. While they are getting better at sanitizing *some* input, it is 
specific to known attack vectors like overflows, format strings, sql 
injections and more. Most are bad about filtering "all other junk someone 
may throw at this", which leads to these typs of changelogs. If a VDB is 
expected to make an entry for every way to crash a server or application, 
we could potentially expect to see several thousand more entries every 
year (scaling up as each year goes by). As such, it isn't prudent to add 
each and every one at this point.

If you subscribe to #1 and haven't done it for your database, i'd guess it 
is a time/resource issue. It can take hours to sort through that changelog 
and think about which get an entry, then hours more to create them in the 
database. If that is the case, I fully understand it and it is the exact 
reason I have skipped over some of these changelogs in the past.

If you subscribe to #2, what is the fine line that dictates which get an 
entry and which doesn't? I am not dead set on every single DoS attack 
getting an entry, but I find myself having a hard time deciding where the 
line is. Solely based on access/privileges required? Based on how feasible 
an attack is using the method? Something else?

Brian

ps: this is on my to-blog about list.