Onderwerp: BoF in Windows 2000: ddeshare.exe

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:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABB

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

--==_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+92wpqvoMOBP EnhPrW/wCdGxZM
0vfBlW14Qrhf+eDYTxNQ9dc=
=llme
-----END PGP SIGNATURE-----

--==_Exmh_458346432P--

On Tue, 9 Nov 2004 Valdis.Kletnieks@vt.edu wrote:

> Ah, but what if the 2 trailing B's are replaced by 2 Unicode chars that
> together take up 4 bytes?

Or we can realize that in Windows NT, XP, and above, all "characters" are
two-byte-wide UNICODE characters, and that we're not seeing "[NULs]
inserted between characters" but simply UNICODE characters with very low
ordinals.

It's probably worth pointing out that a large fraction of the 16-bit
UNICODE space is taken up with Chinese, Japanese, and Korean characters.

In fact, UNICODE codepoint 0x9090 happens to be the Chinese character for
[li3], "winding" or "meandering". Chinese poetry shellcode, anybody?

--Jeffrey