A few months back, my little team and myself were fortunate enough to assist a well-known software company release the latest version of their Mac OS X application. Among the improvements we recommended, and helped implement, was Sparkle-based updating.
One of our testing points at the time was to ensure one could not reasonably trick the application, through Sparkle, into downloading and executing malicious code.
As many of you know, Sparkle is the framework of choice for most Mac OS X developers when it comes to enabling auto-updates in their applications. It is fast, it is reliable and it provides a consistent updating experience for end-users who quickly become familiar with the process.
Sparkle can also be made to be very secure, thanks to signature verification. Unfortunately, it can also be implemented in a way that is more dangerous, simply connecting to a server and downloading code.
In the light of the recent announcements, it seems important to ensure that the Sparkle-using applications you run do check for signatures whenever implementing updates.
Additionally, it is important to check whether:
- The application displays release notes through an SSL (HTTPS) connection to the author's servers.
- The application displays no release notes.
Otherwise, as you can probably guess, the application may be tricked into displaying maliciously crafted release notes, that could, for example, trigger an exploit in WebKit. WebKit exploits aren't exactly unheard of, and they could be embedded very stealthily into otherwise perfectly genuine release notes. This works regardless of whether code signing is implemented.
None of this is a security issue with the Sparkle framework, really. It simply relies on WebKit to display web pages and it downloads code if instructed to do so. No criticism of Sparkle here.
However, if you are a Mac user and if you run third-party applications, now would be a great time to look into the issue and to get to know your applications better. Switching to a fully secured updating process does not require that authors remove Sparkle from the equation or invest in brand new code. It is, usually, only a matter of SSL here and signatures there.
(Yes, yes, I know updating an application is never easy and never without risks. It's "easy" as in "still Sparkle," not as in "baking brownies.")
Categories
Mac
Comments (1)
Read More Entries by FJ de Kermadec.
Sparkle is clearly filling a need for developers, but it has bad user interaction model, in my opinion. You're asked to apply an update at precisely the wrong moment--when you've just launched an app to get some work done. There should be a way to defer to the update until the application is quit; that would be much more user friendly.