Time for some more controversy...
Another Microsoft developer and I recently had a fairly long email discussion about a potential problem. It turns out that it might be possible to craft a file in such a fashion that would cause some internal applications to crash. The details aren't really important, but some of the comments that this developer (let's call him "R.") made were rather interesting and worthy of discussion.
In this case, the problem could not be exploited - the worst that could happen with this problem is a crash, which is considered a local DoS attack (a classic buffer overrun also can cause a crash, but they allow the attacker to execute arbitrary code, instead, they're classified as elevation of privilege attacks (the buffer overrun allows the attacker to elevate from unauthenticated to authenticated).
The SDL process states this kind of DoS attack isn't important enough to rate a security bulletin, instead they're classified as being in the "fix in the next service pack" category (IIRC, remote DoS attacks are service bulletin classed issues (I may be wrong on this one)).
So as I mentioned, we're discussing to what level the system should protect itself from this kind of issue. R. was quite adamant that he considered these kinds of problems to be "non-issues" because the only thing that could happen was that an app could crash.
The rules of the road in this case are quite simple: If it's possible to craft a file that would cause a part of the system to hang or crash, it's got to be fixed in the next service pack after the problem's discovered (or RTM if it's found in testing, obviously).
But R.'s point was essentially the same as David's: Crashes (hangs) are bad got a point, but are they really "security bugs"? There are tons of ways to trick applications to do bad things, do all of them classify problems that MUST be fixed, even if they're not exploitable?
Just something to think about on a Thursday afternoon.