Message-ID: <43A098EC.3040503@kc.rr.com>
Date: Wed Dec 14 22:13:26 2005
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: iDefense Security Advisory 12.14.05: Trend
	Micro ServerProtect relay.dll Chunked Overflow Vulnerability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

labs-no-reply@...fense.com wrote:
> Trend Micro ServerProtect relay.dll Chunked Overflow Vulnerability
(yawn)

And iDefense gets duped again... this time by a three-year-old
vulnerability and a vendor's sloppy clean-up job.

As Trend document, this vulnerability is in the Microsoft Foundation
Classes library that ships with the underlying OS.  Not only that, but
this vulnerability has been public for 3+ years as well, since July of 2002.

An example of the same vulnerability is exploited by this code:
http://www.securiteam.com/exploits/5WP0C0U7PE.html

Indeed, this vulnerability is caused by the same broken code within the
MFC libraries.

Microsoft fixed this vulnerability with Visual Studio 6.0 SP6 (or,
rather, this was the claim MSRC made to me -- I never tested it).
However, there's no documentation of this overflow fix in any of the
associated knowledge-base articles.  It's a badly-done silent patch on
Microsoft's part, and it's not Trend's fault at all.  I'm surprised
Trend bothered pulling the old knowledge base article about the "heavy
load" flaw, as it's really not relevant at all to the real issue.

This bug was swept under the rug and patched by Microsoft without even a
mention in the KB.  The ridiculous reasoning for this that I received
was that Microsoft didn't have the ability to reach developers of
affected code (namely, those using the static libraries) and therefore
shouldn't *publicize* the fix because it could put customers at risk to
do so.  This, in spite of the fact that the vulnerability had been known
and public for *MORE THAN A YEAR* prior to Microsoft's issuance of SP6
in 2004.

It's entirely likely that Trend is just a new victim of an old hole.  In
particular, Microsoft's documentation for SP6 omits mention of any bugs
in the *DYNAMIC* libaries.  However, they're affected, too.  So, if you
have an old mfc42.dll on your testbed system, and are running an ISAPI
extension on it that is compiled with Visual Studio and linked to MFC,
you are vulnerable to remote code execution attacks against your web
applications.

...And after three years, there are still vulnerable libraries out
there.  To make matters worse, I discovered in my attempts to ascertain
the status of the issue in SP6... that there was never an internal Case
ID assigned to it.  I honestly couldn't tell you if the information I
received about Microsoft's plans to patch this issue in SP6 ever
translated into reality.  This is precisely why the "hush hush and let
the vendor deal with it" approach does *NOT* work and never will, no
matter what pretty, flowery ethical terminologies you put on it.  There
have to be limits, if for no other reason than accountability for
disasters like this one.

- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."

                                -- Michael Holstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDoJjrfp4vUrVETTgRAz8VAJ9d/iDNDeBvcS/EwERAvWNxL7C/zQCghIty
qRpvbvX56mCusVXcqp9hPIw=
=vmme
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3436 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051214/94b1a627/smime.bin

Powered by blists - more mailing lists