<?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 for Analytical Engine</title>
	<atom:link href="http://www.analyticalengine.net/comments/feed" rel="self" type="application/rss+xml" />
	<link>http://www.analyticalengine.net</link>
	<description>Application Security, General Technology, and Geek Ramblings</description>
	<pubDate>Wed, 27 Aug 2008 23:48:59 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
		<item>
		<title>Comment on Windows Buffer Overflow Protection 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>Comment on Windows Buffer Overflow Protection 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>
	<item>
		<title>Comment on Another Java Security Flaw by Joshbw</title>
		<link>http://www.analyticalengine.net/archives/41#comment-73</link>
		<dc:creator>Joshbw</dc:creator>
		<pubDate>Wed, 30 Jul 2008 18:54:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=41#comment-73</guid>
		<description>I'll pass the word around.  Take care until then, and good luck with the httpOnly crusade</description>
		<content:encoded><![CDATA[<p>I&#8217;ll pass the word around.  Take care until then, and good luck with the httpOnly crusade</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Another Java Security Flaw by Jim Manico</title>
		<link>http://www.analyticalengine.net/archives/41#comment-72</link>
		<dc:creator>Jim Manico</dc:creator>
		<pubDate>Wed, 30 Jul 2008 18:43:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=41#comment-72</guid>
		<description>This was absolutely hilarious Josh. Good work, I was very amused. 

PS: I'm going to be in town week of Sept 22. Pass the word. BBQ anyone?</description>
		<content:encoded><![CDATA[<p>This was absolutely hilarious Josh. Good work, I was very amused. </p>
<p>PS: I&#8217;m going to be in town week of Sept 22. Pass the word. BBQ anyone?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why is there debate about code review and WAFs? by Jim</title>
		<link>http://www.analyticalengine.net/archives/31#comment-44</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Wed, 21 May 2008 22:38:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=31#comment-44</guid>
		<description>Josh, this is a fantastic post bringing light to what PCI-DSS is really about. Nice work!</description>
		<content:encoded><![CDATA[<p>Josh, this is a fantastic post bringing light to what PCI-DSS is really about. Nice work!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Improved CAPTCHA? by Joshbw</title>
		<link>http://www.analyticalengine.net/archives/27#comment-33</link>
		<dc:creator>Joshbw</dc:creator>
		<pubDate>Wed, 16 Apr 2008 13:58:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=27#comment-33</guid>
		<description>Yeah, I read that article on ars yesterday.  I've found that no more spam than usual has made it through my outlook filter (the built in filter in 2007 is remarkably good) but I have been getting a great deal more spam in my gmail account, from gmail and hotmail domains.

I've also seen the Asira project before and I like the intent of it.  That said, I have a concern with it.  It is technically feasible to crawl petfinder and download all of the images, which are conveniently categorized by type (cat, dog, bird, rabbit, etc) and then create a simple database that uses a hash from the image as a key to look up the type.  Then, when crawling sites that are asira enabled the images could just be rehashed and looked up.

Hopefully MS is actually doing some modifications (resize, slight color filter, etc) that would cause the Asira image to have a different hash value, which would frustrate that approach.</description>
		<content:encoded><![CDATA[<p>Yeah, I read that article on ars yesterday.  I&#8217;ve found that no more spam than usual has made it through my outlook filter (the built in filter in 2007 is remarkably good) but I have been getting a great deal more spam in my gmail account, from gmail and hotmail domains.</p>
<p>I&#8217;ve also seen the Asira project before and I like the intent of it.  That said, I have a concern with it.  It is technically feasible to crawl petfinder and download all of the images, which are conveniently categorized by type (cat, dog, bird, rabbit, etc) and then create a simple database that uses a hash from the image as a key to look up the type.  Then, when crawling sites that are asira enabled the images could just be rehashed and looked up.</p>
<p>Hopefully MS is actually doing some modifications (resize, slight color filter, etc) that would cause the Asira image to have a different hash value, which would frustrate that approach.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Improved CAPTCHA? by Jim</title>
		<link>http://www.analyticalengine.net/archives/27#comment-32</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Tue, 15 Apr 2008 23:42:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=27#comment-32</guid>
		<description>Holy cats and dogs - have you seen this?

http://research.microsoft.com/asirra/?0sr=a</description>
		<content:encoded><![CDATA[<p>Holy cats and dogs - have you seen this?</p>
<p><a href="http://research.microsoft.com/asirra/?0sr=a" rel="nofollow">http://research.microsoft.com/asirra/?0sr=a</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Improved CAPTCHA? by Jim</title>
		<link>http://www.analyticalengine.net/archives/27#comment-31</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Tue, 15 Apr 2008 23:37:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=27#comment-31</guid>
		<description>Ouch - the world could use better Captcha protection: http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html</description>
		<content:encoded><![CDATA[<p>Ouch - the world could use better Captcha protection: <a href="http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html" rel="nofollow">http://arstechnica.com/news.ars/post/20080415-gone-in-60-seconds-spambot-cracks-livehotmail-captcha.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Improved CAPTCHA? by Joshbw</title>
		<link>http://www.analyticalengine.net/archives/27#comment-30</link>
		<dc:creator>Joshbw</dc:creator>
		<pubDate>Fri, 11 Apr 2008 14:43:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=27#comment-30</guid>
		<description>I think an animated GIF would be better for client side support, and isn't technically difficult to dynamically generate.  The downside is that it does take significantly more processing time than static graphics to generate, and for captchas on popular websites dynamic generation is usually the only viable route (since otherwise the attackers can just harvest all of the images, and create a database of hashes from the file and associated text).

Flash is definitely and easier route in terms of server resources, but you are absolutely right about it being a pain with the myriad of flash versions (is flash even present, is it a smart device that uses flash-lite, etc).</description>
		<content:encoded><![CDATA[<p>I think an animated GIF would be better for client side support, and isn&#8217;t technically difficult to dynamically generate.  The downside is that it does take significantly more processing time than static graphics to generate, and for captchas on popular websites dynamic generation is usually the only viable route (since otherwise the attackers can just harvest all of the images, and create a database of hashes from the file and associated text).</p>
<p>Flash is definitely and easier route in terms of server resources, but you are absolutely right about it being a pain with the myriad of flash versions (is flash even present, is it a smart device that uses flash-lite, etc).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Improved CAPTCHA? by Jim</title>
		<link>http://www.analyticalengine.net/archives/27#comment-28</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Thu, 10 Apr 2008 21:12:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.analyticalengine.net/?p=27#comment-28</guid>
		<description>You are onto something here - there are a number of ways to protect content via flash. The only downside - need to support a wide variety/versions of the flash engine. But still, I like it.</description>
		<content:encoded><![CDATA[<p>You are onto something here - there are a number of ways to protect content via flash. The only downside - need to support a wide variety/versions of the flash engine. But still, I like it.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
