RE: MODIFY-01 cluster: 25 CERT candidates moved to MODIFICATION phase
-----BEGIN PGP SIGNED MESSAGE-----
I tend to agree with Andre on this one....we enter the vulnerability
and then link it to the affected components (OS, application,service
etc.)as well as appropriate safeguards, workarounds for each
component. This allows us to link multiple affected components to a
single vulnerability description and references. But the CVE is not
set up this way.
Not sure how to answer this, but it would seem IMHO that you either
list all affected applications in one description (defeats the short,
concise description) or multiple CVE entries and cross-reference them
to show they are affected by the same vulnerability (adds considerable
entries to the CVE database). I would rather see a single entry with
multiple affected applications.
- -Mike Prosser
- -----Original Message-----
From: Andre Frech (ISS) [mailto:email@example.com]
Sent: Wednesday, June 23, 1999 7:32 PM
To: Steven M. Christey; firstname.lastname@example.org
Subject: RE: MODIFY-01 cluster: 25 CERT candidates moved to
Good point; we went through the same contortions and evolution with
First of all, I don't believe it to be a LOA problem (even if I don't
believe in voodoo). Therefore, we could go two ways on this type of
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
term, such as 'some MIME-compliant mailers..."
If we choose to enumerate, then it'll cascade into 'not listing all
versions, etc.', which again degrades into a VDB's job (no offense to
who own VDBs).
As background, originally we heard about this vuln affecting Outlook,
then it was broadened to all MIME-compliant mail programs. (Thus why
term is a bit misleading; once defined, an X-Force tagname is set in
or at least in wet concrete on a summer day.)
Good point, Adam and Steve.
X-Force Security Research
Internet Security Systems, Inc.
678.443.6241 / fax 678.443.6479
Adaptive Network Security for the Enterprise
> -----Original Message-----
> From: Steven M. Christey [mailto:email@example.com]
> Sent: Wednesday, June 23, 1999 1:40 PM
> To: firstname.lastname@example.org
> Subject: Re: MODIFY-01 cluster: 25 CERT candidates moved to
> Adam Shostack asked me the following question, which touches on a
> potentially delicate issue that nonetheless should be addressed
> rather than later. Quiet people may want to pipe up on this one ;-)
> | Candidate: CAN-1999-0004
> | Published:
> | Final-Decision:
> | Interim-Decision:
> | Modified: 19990621-01
> | Announced: 19990607
> | Assigned: 19990607
> | Category: SF
> | 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.
> | Modifications:
> | ADDREF MS:MS98-008
> | DESC include 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
> >to do this, we need to add at least Eudora as well. Its fairly
> >to me that these are distinct.
> I see how you think this could be an LOA (level of abstraction)
> There are multiple applications affected.
> >From my perspective, we shouldn't divide this into separate
> vulnerabilities because:
> - the same "exploit" would work on any of these applications
> (modulo the OS the application is on)
> - the bug occurs in multiple applications, but these applications
> all do the same thing (i.e. process email)
> - the bug is in the same functional component/specific "operation"
> of the applications, i.e. the MIME conversion
> - the bug has been discovered in each application at (basically)
> the same time
> To me, this is the same implementation flaw, spread across different
> implementations of the same type of application, so this is the
> appropriate LOA to use. (Er, I suppose I could have written that
> better). Do people agree with this perspective?
> 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
> - Steve
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2
-----END PGP SIGNATURE-----