Finding and exploiting holes in software features
With the holiday season fast approaching, and being so in the spirit of giving, I thought I’d compile a list of the top features that led to security issues I discovered with co-researcher Billy Rios.
With the New Year on its way, this should give the developers out there a chance to come up with some New Year’s resolutions regarding the lessons learned from a year in the wild world of computer security.
Picasa’s Button Import Feature and Built-in Web Browser/Server
Google’s Picasa includes a button import feature that can be accessed from a URI. This feature is actually quite useful; as it allows a user to click a link and import an XML description of a button into Picasa that when clicked will post images to Tabblo or Flickr albums. This is done with a Java applet that requires user interaction before upload.
Unfortunately, URIs are also accessible to attackers through cross-site scripting (XSS), so an attacker can XSS a Picasa user, load Flash which doesn’t do DNS pinning (this JUST missed our list), and then steal the user’s images without any interaction or confirmation.
I use Picasa to modify my pictures, but I can’t help worrying about the built-in web browser and web server that Picasa includes. Sure, the server is bound to the local loopback, but we can access it through Flash loaded in Picasa’s built-in browser as mentioned above. We could use the Flash we loaded in the built-in browser to attack the built-in server as well, which may lead to more vulnerabilities.
Starting web servers on the local loopback appears to be a design pattern for Google as Google Desktop does the same. From a features standpoint, this may provide a rich environment for extending applications. It’s important to consider the task at hand, and in the case of an application that is being used for photo editing, I have a hard time finding justification for having any service running.