[37285] in bugtraq
BoF in Windows 2000: ddeshare.exe
daemon@ATHENA.MIT.EDU (Jack C)
Tue Nov 9 14:32:22 2004
Message-ID: <41902A40.1000608@crepinc.com>
Date: Mon, 08 Nov 2004 21:24:00 -0500
From: Jack C <jack@crepinc.com>
MIME-Version: 1.0
To: bugtraq@securityfocus.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Hello all,
I found a static buffer overflow in ddeshare.exe on my Windows 2000,
latest updates/service packs box tonight. It appears as though no bounds
checking is performed on the share name before it is copied to the variable.
Exploiting:
Start up c:\winnt\system32\ddeshare.exe. Click shares --> trusted
shares. Pick any of the shares already there (at least there are some on
my box, if not you can make one), and select Properties. Replace the
data in the "Share Name" text box with something like this:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABB
When you click OK, you get an error stating that ddeshare.exe has
"generated errors". Yay.
Run in OllyDbg, we find that the above string makes the program attempt
to JMP to 0x00420042. It just so happens that Hex 42 is a "B". So the
two B's at the end of the exploit string change the instrucation pointer.
As far as I can tell, this is not exploitable to run a shellcode because
of the fact that NULL's are inserted between charactors. But besides
that, it would only give the same privliges that you already have to run
the program in the first place. It simply points out bad coding.
Again, this isn't another of Microsoft's giant end-of-the-world security
blunders, but still, it's a BoF.
Thanks,
-Jack C ("crEp")
jack [at] crepinc.com
http://www.crepinc.com
