RE: MODIFY-01 cluster: 25 CERT candidates moved to MODIFICATION phase

["Andre Frech (ISS)" <afrech@iss.net>]

Good point; we went through the same contortions and evolution with this
vulnerability.

First of all, I don't believe it to be a LOA problem (even if I don't really
believe in voodoo). Therefore, 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..."

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).

As background, originally we heard about this vuln affecting Outlook, and
then it was broadened to all MIME-compliant mail programs. (Thus why our
term is a bit misleading; once defined, an X-Force tagname is set in stone,
or at least in wet concrete on a summer day.)

Good point, Adam and Steve.

=====================================
Andre Frech
X-Force Security Research
afrech@iss.net

Internet Security Systems, Inc.
678.443.6241 / fax 678.443.6479
www.iss.net
Adaptive Network Security for the Enterprise
=====================================


> -----Original Message-----
> From: Steven M. Christey [mailto:coley@linus.mitre.org]
> Sent: Wednesday, June 23, 1999 1:40 PM
> To: cve-review@linus.mitre.org
> Subject: Re: MODIFY-01 cluster: 25 CERT candidates moved to MODIFICATION
> phase
>
>
>
> Adam Shostack asked me the following question, which touches on a
> potentially delicate issue that nonetheless should be addressed sooner
> 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 choose
> >to do this, we need to add at least Eudora as well.  Its fairly clear
> >to me that these are distinct.
>
> I see how you think this could be an LOA (level of abstraction) issue.
> 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 clients?
>
> - Steve
>