<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.msdn.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx</link><description>As y’all know, the Visual C++ /GS compiler flag adds prolog and epilog code to certain functions to help detect some classes of stack based buffer overruns at runtime. In VC++ 2005, the code looks like this: Function prolog sub esp, 8 mov eax, DWORD PTR</description><dc:language>en-US</dc:language><generator>CommunityServer 2.1 SP1 (Build: 61025.2)</generator><item><title>Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1  &amp;laquo; Software and web application security</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2026423</link><pubDate>Wed, 04 Apr 2007 20:33:24 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2026423</guid><dc:creator>Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1  « Software and web application security</dc:creator><description>&lt;p&gt;PingBack from &lt;a rel="nofollow" target="_new" href="http://chrisweber.wordpress.com/2007/04/04/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1/"&gt;http://chrisweber.wordpress.com/2007/04/04/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1/&lt;/a&gt;&lt;/p&gt;
</description></item><item><title>re: Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2030192</link><pubDate>Thu, 05 Apr 2007 09:24:06 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2030192</guid><dc:creator>Yoink</dc:creator><description>&lt;p&gt;Do Microsoft care to explain what 'If a parameter is used only in ways that are less likely to be exploitable in the event of a buffer overrun.' means?&lt;/p&gt;</description></item><item><title>re: Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2032831</link><pubDate>Thu, 05 Apr 2007 16:50:42 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2032831</guid><dc:creator>michael_HOWARD</dc:creator><description>&lt;p&gt;The sample code above shows the main one - using non-chars as the buffer element type&lt;/p&gt;
</description></item><item><title>re: Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2077798</link><pubDate>Wed, 11 Apr 2007 00:36:59 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2077798</guid><dc:creator>ddebug</dc:creator><description>&lt;p&gt;Is this correct that /GS can make copies of vulnerable parameters on stack, and thus increase stack usage much more and less predictably than we could guess? (8 bytes per call frame)&lt;/p&gt;
&lt;p&gt;Is there any easy way to know when the compiler makes big allocations on stack? This may be important for kernel mode, where stack is limited.&lt;/p&gt;</description></item><item><title>re: Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2079814</link><pubDate>Wed, 11 Apr 2007 04:20:57 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2079814</guid><dc:creator>michael_HOWARD</dc:creator><description>&lt;p&gt;ddebug,&lt;/p&gt;
&lt;p&gt;yes it's true, but in our experience, it's really not a big issue. We saw now perf problems or stack exhaustion.&lt;/p&gt;
</description></item><item><title>re: Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2177436</link><pubDate>Wed, 18 Apr 2007 19:47:18 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2177436</guid><dc:creator>Alexander Sotirov</dc:creator><description>&lt;p&gt;Does using this flag enable /GS cookies for the LoadAniIcon function which was responsible for the recent ANI vulnerability? It was a perfect example of a function which should have been protected by /GS, but the compiler failed to insert the cookie because the function was overwriting a structure on the stack, instead of an array.&lt;/p&gt;
&lt;p&gt;By the way, what exact version of VC2005 was used to compile Vista? Is it the same one that's included in the Vista release of the Windows SDK, or a private build of the compiler?&lt;/p&gt;</description></item><item><title>re: Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2178429</link><pubDate>Wed, 18 Apr 2007 21:19:07 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2178429</guid><dc:creator>michael_HOWARD</dc:creator><description>&lt;p&gt;Hello Alexander&lt;/p&gt;
&lt;p&gt;re: /GS - yes, the #pragma would add the cookie to this func.&lt;/p&gt;
</description></item><item><title>Lessons learned from the Animated Cursor Security Bug</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2291547</link><pubDate>Fri, 27 Apr 2007 01:56:58 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2291547</guid><dc:creator>The Security Development Lifecycle</dc:creator><description>&lt;p&gt;Michael Howard here. A core tenet of the SDL is to take and incorporate lessons learned when we issue&lt;/p&gt;
</description></item><item><title>re: Hardening Stack-based Buffer Overrun Detection in VC++ 2005 SP1</title><link>http://blogs.msdn.com/michael_howard/archive/2007/04/03/hardening-stack-based-buffer-overrun-detection-in-vc-2005-sp1.aspx#2314966</link><pubDate>Sat, 28 Apr 2007 22:55:26 GMT</pubDate><guid isPermaLink="false">91d46819-8472-40ad-a661-2c78acb4018c:2314966</guid><dc:creator>anonymous</dc:creator><description>&lt;p&gt;I have VS2005 SP1 running, but the compiler complains that this pragma simply doesn't exist. What now?&lt;/p&gt;</description></item></channel></rss>