[24277] in bugtraq
Microsoft C++ feature against buffer overflows itself vulnerable
daemon@ATHENA.MIT.EDU (Chris Ren)
Thu Feb 14 12:57:01 2002
From: "Chris Ren" <cren@cigital.com>
To: bugtraq@securityfocus.com
Date: Thu, 14 Feb 2002 09:00:42 -0500
Message-ID: <51CC94132526754995E79DCF28C0C34D029B@exchange.cigital.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7BIT
Microsoft added a new security feature to their latest C++ compiler, called
both Visual C++.Net and Visual C++ version 7 that was released February
13th. This security feature is meant to protect potentially vulnerable
source code automatically from some forms of buffer overflow attack. The
protection afforded by the new feature allows developers to continue to use
vulnerable string functions such as strcpy() as usual and still be
"protected" against some forms of stack smashing. The new feature is
closely based on an invention of Crispin Cowan's called StackGuard and is
meant to be used when creating standard native code (not the new .NET
intermediate language, referred to as "managed code").
Note that the new feature is meant to protect any program compiled with the
"protected" compiler feature. In other words, the idea is that using this
feature should help developers build more secure software. However, in its
current form, the Microsoft feature leads to a false sense of security
because it is easily defeated.
Microsoft's feature includes the ability to set a "security error handler"
function to be called when a potential attack is underway. Because of the
way this was implemented, the Microsoft security feature is itself
vulnerable to attack. An attacker can craft a special-purpose attack
against a "protected" program, defeating the protection mechanism in a
straightforward way. This kind of attack is not new. See, for example,
Phrack 56 at http://www.phrack.org/show.php?p=56&a=5
There are several well known approaches not based on StackGuard that a
compiler-producer might use to defeat buffer overflow attacks. Microsoft
chose to adopt a weak solution rather than a more robust solution. This is
a design-level flaw leading to a very serious set of potential attacks
against code compiled with the new compiler. The Microsoft compiler is thus
in some sense a "vulnerability seeder".
More technical information about the flaw can be found at
http://www.cigital.com/news/mscompiler-tech.html
Microsoft has been alerted to the flaw.
Chris Ren