[37292] in bugtraq
Re: BoF in Windows 2000: ddeshare.exe
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Wed Nov 10 00:33:35 2004
Message-Id: <200411091959.iA9JxKaL009177@turing-police.cc.vt.edu>
To: Jack C <jack@crepinc.com>
Cc: bugtraq@securityfocus.com
In-Reply-To: Your message of "Mon, 08 Nov 2004 21:24:00 EST."
<41902A40.1000608@crepinc.com>
From: Valdis.Kletnieks@vt.edu
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_458346432P";
micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 09 Nov 2004 14:59:20 -0500
--==_Exmh_458346432P
Content-Type: text/plain; charset=us-ascii
On Mon, 08 Nov 2004 21:24:00 EST, Jack C said:
> 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.
Ah, but what if the 2 trailing B's are replaced by 2 Unicode chars that
together take up 4 bytes? ;)
> 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.
If you can find a way to programmaticaly call the same code, this can be
leveraged by a trojan code. Consider: If there was a way to get a user to
click on a URL that resolved to a file share and fall into this code, this
could be used as an initial attack point for a worm.....
--==_Exmh_458346432P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFBkSGXcC3lWbTT17ARAmNpAKDUeu8l3V+92wpqvoMOBPEnhPrW/wCdGxZM
0vfBlW14Qrhf+eDYTxNQ9dc=
=llme
-----END PGP SIGNATURE-----
--==_Exmh_458346432P--
