RE: MODIFY-01 cluster: 25 CERT candidates moved to MODIFICATION phase
> | Candidate: CAN-1999-0004
> | Reference: CERT:CA-98.10.mime_buffer_overflows
> | Reference: XF:outlook-long-name
> | Reference: SUN:00175
> | MIME buffer overflow in email clients, e.g. Solaris mailtool
> | and Outlook.
> >It occurs to me that there may be a [level of abstraction] issue
> >here. Why are we grouping all mailtools into one entry? If we choose
> >to do this, we need to add at least Eudora as well. Its fairly clear
> >to me that these are distinct.
> Note that the description singles out mailtool and Outlook, ignoring
> the other applications that are affected. Assuming we agree on the
> LOA, should the description be modified to list all affected clients?
>we could go two ways on this type of issue: either
>enumerate all the mailers and risk missing one (which IMHO is a
>function of a vulnerability database (VDB), not the CVE) or use a
>general term, such as 'some MIME-compliant mailers..."
I believe that there are enough MIME vulnerabilities out there that
someone "looking up" the name of this vulnerability might be able to
better distinguish this vulnerability from others if we do list all
the affected mailers, or at least a reasonable portion of them. In my
opinion, the requirement for a distinctive description holds
precedence here. I think the general term that Andre suggested is, in
this case, too general.
I agree that it's a VDB's job to be complete on this sort of
information, but it's not a requirement for the CVE.
>If we choose to enumerate, then it'll cascade into 'not listing all
>OSes, versions, etc.', which again degrades into a VDB's job (no
>offense to those who own VDBs).
If we take the same approach as I am with CVE references - i.e.,
there's no *requirement* to be complete, just a strong preference to
provide enough to be distinctive - then we might be able to avoid this
cascading problem in most cases. But for some vulnerabilities that
are similar, the "distinctive description" requirement may force us to
include this kind of information.
The same problem can happen with including OS or application versions.
We don't *need* to include versions, unless they help to distinguish
similar vulnerabilities. Consider "Sendmail buffer overflow" - that
still applies to 5+ different vulnerabilities, so including the
version number helps to distinguish the different vulnerabilities. On
the other extreme, one-word descriptions like "phf" or "Ping o' Death"
are sufficiently distinctive (at this time, anyway ;-)) with almost no