bugtraq - RE: Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 14 May 2003 10:43:47 -0500
From: "Executable Security" <exurity@...ers.com>
To: <bugtraq@...urityfocus.com>
Subject: RE: Detailed analysis: Buffer overflow in Explorer.exe on Windows XP SP1

Hi:

> -----Original Message-----
> From: nesumin [mailto:nesumin@...thome.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