[VIM] windows clarity

[Steven M. Christey]

Here's my original inquiry to MSRC.

I proposed creating separate CANs since they were separate issues, and
MSRC responded to confirm this.

- Steve

-----Original Message-----
From: Steven M. Christey [mailto:coley at mitre.org]
Sent: Tuesday, February 01, 2005 4:06 PM
To: Microsoft Security Response Center
Cc: coley at mitre.org
Subject: Clarification requested on CAN-2004-1049/MS05-002 ANI issue(s)


Hello,

MS:MS05-002 discusses a "Cursor and Icon Format Handling Vulnerability"
and credits eEye, but also uses the CAN-2004-1049 reference, which is
for an xfocus-discovered issue.

Issue 1) The xfocus-reported issue is for an integer overflow in the
         LoadImage function.

         BUGTRAQ:20041223 Microsoft Windows LoadImage API Integer
                          Buffer overflow
URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110382891718076&w=2

Issue 2) The eEye-reported issue specifically involves manipulating
         the "Length_of_AnimationHeader" field, whose value is "not
         checked appropriately," however it's not an integer overflow
         (since eEye would be smart enough to label it as such)

         eEye further explicitly states "This vulnerability is a
         separate vulnerability from the ones discovered by Xfocus."

         BUGTRAQ:20050111 EEYE: Windows ANI File Parsing Buffer Overflow

URL:http://marc.theaimsgroup.com/?l=bugtraq&m=110547079218397&w=2


By directly crediting eEye in MS05-002, but implicitly linking to the
xfocus issue in CAN-2004-1049, it seems to me that MS05-002 is covering
2 separate but closely related issues.

If this is the case, then I will update CAN-2004-1049 so that its
description mentions BOTH issues, and links to BOTH advisories.

Please confirm that this is the appropriate action.  The alternative
would be to create a separate candidate for the eEye issue, but that
doesn't seem like the proper way to go; since both issues involve the
same general type of vulnerability, I'd prefer that they stay combined.


Thanks,
Steve