[30134] in bugtraq
RE: Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1
daemon@ATHENA.MIT.EDU (Executable Security)
Wed May 14 19:09:10 2003
From: "Executable Security" <exurity@rogers.com>
To: <bugtraq@securityfocus.com>
Date: Wed, 14 May 2003 10:43:47 -0500
Message-ID: <NHBBJKMMFKCGNHDPMAJJEEPJCAAA.exurity@rogers.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20030514202001.861A.NESUMIN@softhome.net>
Hi:
> -----Original Message-----
> From: nesumin [mailto:nesumin@softhome.net]
> I could create the exploit code on my Japanese Windows XP SP1.
> Perhaps, I think you can easily create the full exploit code
> by the following;
>
> * You can directly specify all overwritten data without thinking
> the UNICODE conversion if you create the "desktop.ini" as "UTF-16".
> (Adding BOM and encoding "[.ShellClassInfo]\x0d\x0a".)
>
> * You can get the code area of about 0xFF4 bytes.
> (Before and after RET address)
Obviously, I was playing in the ANSI world. Yes, I agree with you that the
exploit code written in RTF-16 can be created with a size of about 0xFF4
bytes. A piece of 0xFF4 bytes long exploit code can do a lot. So, my
previous statement about limited exploitation of this buffer overflow is not
accurate.
It should be very easy to fix this bug. I manually modified the 800H to 400h
in shell32.dll to fix it.
Thanks a lot for your mention of BOM and UTF-16. Your concept is learnt and
programmatically reproduced with GetPrivateProfileSectionW.
Best regards
Peter Huang
