|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: MODIFY-01 cluster: 25 CERT candidates moved to MODIFICATION phase
Adam said: > | Candidate: CAN-1999-0004 > [snip] > | 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. > | > [snip] > > >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. I said: > 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? Andre said: >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 information whatsoever. - Steve
|
||||