<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Windows Buffer Overflow Protection</title>
	<atom:link href="http://www.analyticalengine.net/archives/53/feed" rel="self" type="application/rss+xml" />
	<link>http://www.analyticalengine.net/archives/53</link>
	<description>Application Security, General Technology, and Geek Ramblings</description>
	<pubDate>Tue, 06 Jan 2009 12:51:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.5</generator>
		<item>
		<title>By: Joshbw</title>
		<link>http://www.analyticalengine.net/archives/53#comment-76</link>
		<dc:creator>Joshbw</dc:creator>
		<pubDate>Tue, 12 Aug 2008 23:43:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=53#comment-76</guid>
		<description>&lt;blockquote&gt;I would think that the cost increase is likely to be negligible. The paper comes with full source code that's well-commented and pretty general.&lt;/blockquote&gt;
The difficulty for seasoned folks has not increased substantially but anything you do to make them take extra steps buys you something.  CAPTCHAs for example are pretty much broken, but there is still value in having a good one.  Determined attackers can still get through, but if your system is slightly more difficult than a similar size competing target people will tend to choose it over you.  Vista can be broken, but is it worth the extra effort when it isn't even needed for XP, a much larger target (granted you can get both going after Vista, but path of least resistance is usually the chosen one).

&lt;blockquote&gt;either create a large padding section&lt;/blockquote&gt;
Yeah, that and the no-op segments were the best recomendations, but while the actual logic code of the binary is quite small in those situations the physical size would not be.  To get around this they advocate using gzip compression so the physical size is negligable, but there are many servers that don't have this enabled by default.  Thus they would either own their own servers or be choosey in which compromised servers they use to serve the control.  Either way simply introducing the need for a hosted control increases the cost of the attack, if one was trying to break ASLR rather than simply avoid it.

&lt;blockquote&gt;In any case, Flash is probably the better vector, since it's far and away the most widely deployed plugin, and never ASLR protected anyway. No need to circumvent what isn't there.&lt;/blockquote&gt;  Well, quite true, and it is not as if flash is lacking in vulnerabilities at the moment.  That said, the browser isolation of IE 7 was specifically designed with that scenario in mind, so I am quite curious if it mitigates this threat.  The paper seemed very short on details concerning the browser isolation so I don't know what conclusion to draw.  I honestly would think it much bigger news that the logical isolation was broken so I'd love to hear confirmation one way or another.

I wasn't trying to downplay that this is big, but some context is necessary.  This is not Vista security rendered next to worthless as is being reported.  The paper primarily targets browsers and many of the tactics will not work in, say, WMP, which is compiled with DEP and doesn't have anywhere near as vulnerable a plugin model (even though in the past it was a popular target of buffer overflows).  Additionally, while browsers were the primary target the paper was generally mum about the IE 7 isolation protection.  Specific aspects of Vista security, very important aspects to be sure, but only specific aspects none the less are not as effective.  That is hardly the end of the world, and I think the authors were pretty open about even those aspects going forward in new versions of windows (for example, 64 bit Win2k8 server which is much less susceptable because of policy enforcement).</description>
		<content:encoded><![CDATA[<blockquote><p>I would think that the cost increase is likely to be negligible. The paper comes with full source code that&#8217;s well-commented and pretty general.</p></blockquote>
<p>The difficulty for seasoned folks has not increased substantially but anything you do to make them take extra steps buys you something.  CAPTCHAs for example are pretty much broken, but there is still value in having a good one.  Determined attackers can still get through, but if your system is slightly more difficult than a similar size competing target people will tend to choose it over you.  Vista can be broken, but is it worth the extra effort when it isn&#8217;t even needed for XP, a much larger target (granted you can get both going after Vista, but path of least resistance is usually the chosen one).</p>
<blockquote><p>either create a large padding section</p></blockquote>
<p>Yeah, that and the no-op segments were the best recomendations, but while the actual logic code of the binary is quite small in those situations the physical size would not be.  To get around this they advocate using gzip compression so the physical size is negligable, but there are many servers that don&#8217;t have this enabled by default.  Thus they would either own their own servers or be choosey in which compromised servers they use to serve the control.  Either way simply introducing the need for a hosted control increases the cost of the attack, if one was trying to break ASLR rather than simply avoid it.</p>
<blockquote><p>In any case, Flash is probably the better vector, since it&#8217;s far and away the most widely deployed plugin, and never ASLR protected anyway. No need to circumvent what isn&#8217;t there.</p></blockquote>
<p>  Well, quite true, and it is not as if flash is lacking in vulnerabilities at the moment.  That said, the browser isolation of IE 7 was specifically designed with that scenario in mind, so I am quite curious if it mitigates this threat.  The paper seemed very short on details concerning the browser isolation so I don&#8217;t know what conclusion to draw.  I honestly would think it much bigger news that the logical isolation was broken so I&#8217;d love to hear confirmation one way or another.</p>
<p>I wasn&#8217;t trying to downplay that this is big, but some context is necessary.  This is not Vista security rendered next to worthless as is being reported.  The paper primarily targets browsers and many of the tactics will not work in, say, WMP, which is compiled with DEP and doesn&#8217;t have anywhere near as vulnerable a plugin model (even though in the past it was a popular target of buffer overflows).  Additionally, while browsers were the primary target the paper was generally mum about the IE 7 isolation protection.  Specific aspects of Vista security, very important aspects to be sure, but only specific aspects none the less are not as effective.  That is hardly the end of the world, and I think the authors were pretty open about even those aspects going forward in new versions of windows (for example, 64 bit Win2k8 server which is much less susceptable because of policy enforcement).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: DrPizza</title>
		<link>http://www.analyticalengine.net/archives/53#comment-75</link>
		<dc:creator>DrPizza</dc:creator>
		<pubDate>Tue, 12 Aug 2008 21:19:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=53#comment-75</guid>
		<description>"To to respond to the commentary, the reason this is a big deal (moreso than Bright believes) but not the end of the world (as Kingsley-Hughes thinks) is that it makes exploits feasible but more costly"

I would think that the cost increase is likely to be negligible. The paper comes with full source code that's well-commented and pretty general.

"For example, to defeat ASLR the authors advocates hosting a .Net Web Component of sufficient size to dramatically impact how the address space can be randomized, and in order to facilitate downloads they also recommend the webserver hosting the component use gzip compression (which in turn means controlling web server configuration). "

You don't need a huge .NET DLL--the paper shows a couple of ways to make that a non-issue (either create a large padding section, or use a malformed header to make the assembly incompatible with ASLR). Hopefully the latter issue will be fixed sooner rather than later. The former will continue to be an issue until we move to 64-bit processes (it's not possible to cover any appreciable portion of a 64-bit address space, so randomized 64-bit processes could be sufficiently sparse as to make ASLR decently robust).

In any case, Flash is probably the better vector, since it's far and away the most widely deployed plugin, and never ASLR protected anyway. No need to circumvent what isn't there.</description>
		<content:encoded><![CDATA[<p>&#8220;To to respond to the commentary, the reason this is a big deal (moreso than Bright believes) but not the end of the world (as Kingsley-Hughes thinks) is that it makes exploits feasible but more costly&#8221;</p>
<p>I would think that the cost increase is likely to be negligible. The paper comes with full source code that&#8217;s well-commented and pretty general.</p>
<p>&#8220;For example, to defeat ASLR the authors advocates hosting a .Net Web Component of sufficient size to dramatically impact how the address space can be randomized, and in order to facilitate downloads they also recommend the webserver hosting the component use gzip compression (which in turn means controlling web server configuration). &#8221;</p>
<p>You don&#8217;t need a huge .NET DLL&#8211;the paper shows a couple of ways to make that a non-issue (either create a large padding section, or use a malformed header to make the assembly incompatible with ASLR). Hopefully the latter issue will be fixed sooner rather than later. The former will continue to be an issue until we move to 64-bit processes (it&#8217;s not possible to cover any appreciable portion of a 64-bit address space, so randomized 64-bit processes could be sufficiently sparse as to make ASLR decently robust).</p>
<p>In any case, Flash is probably the better vector, since it&#8217;s far and away the most widely deployed plugin, and never ASLR protected anyway. No need to circumvent what isn&#8217;t there.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
