[VIM] windows clarity

Steven M. Christey coley at linus.mitre.org
Thu May 12 15:21:35 EDT 2005

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

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:


  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:


  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

More information about the VIM mailing list