[VIM] windows clarity

[Steven M. Christey]

Here's my original response to Kurt Seifried, which goes into the
nitty-gritty detective work for how I really determined that they were
different.  See the "** THUS **" statement for a techy executive summary.

This is the kinw of heavy duty work that should be shared across the VIM
community.  It's a lot faster to verify than to do it entirely on your
own; I forget how long it took, but it was a couple hours at least.

- Steve


Date: Wed, 16 Feb 2005 12:55:53 -0500 (EST)
From: "Steven M. Christey" <coley at rcf-smtp.mitre.org>
To: Kurt Seifried <kurt at seifried.org>
cc: "Steven M. Christey" <coley at rcf-smtp.mitre.org>
Subject: Re: dupe for sure


On Wed, 16 Feb 2005, Kurt Seifried wrote:

>
>       CAN-2005-0416 The Windows Animated Cursor (ANI) capability in
Windows
> NT, Windows 2000 through SP4, Windows XP through SP1, and Windows 2003
> allows remote attackers to execute arbitrary code via the
> AnimationHeaderBlock length field, which leads to a stack-based buffer
> overflow. BUGTRAQ:20050111 EEYE: Windows ANI File Parsing Buffer
Overflow
>
> Is for SURE:  CAN- 2004- 1049
>
> our write up even includes:
> "...  the length of the AnimationHeaderBlock is 36 bytes  ..."


Dude, you're killing me!  This one's been giving me headaches and I
thought I finally had a resolution.

1) eEye's advisory says "[CAN-2005-0416] is not the same bug as
[CAN-2004-1049]

2) the xfocus issue explicitly mentions frame/rate values, neither of
which seems to be related to the animation length.

3) the xfocus issue's exploit involves setting these values to 0.

4) the fairly big one - Microsoft confirmed via email that they're 2
different issues entirely

5) Looking at this ANI file format info:

   http://underwar.livedns.co.il/projects/ani/ani_file_format.txt

  we see "anih" which is "length of ANI header (36 bytes)"

  but right after "anih" we see:

    "rate" {Length of rate block}

  and then this file:

   http://www.daubnet.com/formats/ANI.html

  goes more into the format of the rate block *and* the anih block

  For the anih block, 4 of the 36 bytes are for a "DisplayRate" field...
and another 4 are for a "NumFrames" field.

  The XFOCUS frame/rate issues say: "no proper check of the frame number
set in the ANI file header" -- which must be talking about the NumFrames
field - and "no proper check of the rate number set in the ANI file
header" - which must be talking about the DisplayRate field.

6) ** THUS **

   eEye mucked around with the *length* of the ANI block, whereas Xfocus
mucked around with fields *within* the ANI block.



How do ya like THEM apples? ;-)

- Steve