The big hole in the floor

by Francois Joseph de Kermadec

Remember Mac OS X's first high-profile security vulnerability? A very long time ago, when most of the Mac community still thought of UNIX as a promised land of security, stability and compatibility, when Apples were still blue and glossy, when the Dock was still wearing its stripy baby costume, it was discovered Software Update could be lured into downloading rogue updates from a malicious server. Panic ensued, as well as an update, that Apple promptly and dutifully issued. The Mac world was hurt but not defeated. Yet, that very issue that prompted so much frantic updating persists in a great many applications to date. Somehow, nobody seems to care.

15 Comments


2006-12-16 09:08:09
Of course, some applications also download signatures and check them. How much protection does this provide however if the signature is downloaded over the same channel as the update? Some degree, for sure, if it is a real signature we are talking about, absolutely none if we are barely dealing with a checksum - though checksums assuredly are a great way to detect transmission errors.


You might want to brush up on your knowledge of public key cryptography. Downloading a signature over the same, insecure channel as the signed data, is safe (and not just to "some degree" as you claim), if the public key used to verifiy the signature has been obtained over a secure channel (for example, through the original installation CDs).

FJ
2006-12-16 09:12:23
Anonymous,


I am sure my knowledge of public-key cryptography leaves a lot to be desired but worry not, we agree. I am putting emphasis on the varying degree of security provided because an increasing number of applications is obtained through the web and not on offline media that could be considered secure. Of course, that supposes a much more complex attack.


Thanks for posting!


FJ

Gary
2006-12-16 10:48:00
The theory is that there are hackable exploits in OS X. And I'm sure that is true. In theory. But I wouldn't be so eager to sound the alarm bell as this kind of worrying about security holes is often not reflected in the practical day to day operation of one's Mac. There seems to be a backlash against Apple's claims to the impenetrability of the Mac that some people are more than giddy to debunk. What David wouldn't want to point to Goliath's weaknesses and knock him down a few pegs? But out in the wild, there just isn't enough empirical evidence for a call to arms against holes in the software update schemes. Maybe I'm just being blissfully ignorant, but having been a Mac user for the past thirteen years without one incident sure makes for a convincing illusion.
FJ
2006-12-16 10:53:37
Gary,


Thank you for your message. I am not quite sure this would require an exploit to exist in Mac OS X. For example, suppose whatever is downloaded issues an rm -r command upon launch: you as a user are certainly allowed to issue that command and zap all your files. Technically speaking, no exploit was used since you did order your computer to download a piece of software and run it without verifying its origin.


The issue here actually applies to all platforms and certainly is not a Mac OS X thing. Being a Mac user, I speak from a Mac perspective here but the same is true of any platform on which self-updating applications exist - that is, probably, any desktop or server platform capable of networking.


I hope this addresses your concern,
FJ

Steve
2006-12-16 13:09:24
Exactly - this is not an OS X issue, but a more over-arching issue with the potential exploitation of software update services that are automated through calls made by the applications themselves.


The problem exists in its absolute worst possible manner when you are on a network where a malicious user has control of a vital gateway to the internet and can either reroute the application's calls to the home server or even reroute your attempts to reach the application's home server.


But it doesn't necessarily need to occur on your subnet - it can be someone breaking into the network of the application's update server.


Perhaps what Apple is moving towards in their next OS update is the key - transactional backups. I'll admit that I felt that this sort of backup system was a bit of overkill for a consumer machine when it was announced (and I didn't raise too much dissent since ... well ... all I know about it is what was demonstrated - it kinda isn't available yet), but it is very possible that many foresee the next wave of security attacks not coming through the OS, but through the corruption of trusted applications. Transactional backups might not 'solve' the problem, but a least allow people to roll back the damage done.


This, of course, pushes the duty of being secure back on us, the users. This might just end up being something similar to what we do when we hear someone complaining that they had their hard drive erased by an email attachment - berate them for opening email attachments that they hadn't first scanned for trouble. After all, we don't expect our mail servers to remove everything that is malicious without paying them a great deal of money for such a service (or do we? - maybe my expectations are too low)


I have a feeling that this security issue could become one where in five years, we'll be saying, "What do you mean you let iRandomApp update itself without running a Traceroute!? And you did it from a hotel's wireless service?! Have you no sense?! Wake up! This is the freakin' internet! You can't trust anything on it!"

Michael Buckley
2006-12-16 14:18:16
You may want to check out Andy Matuschak's wonderful Sparkle framework which is currently in use by about 100 popular Cocoa applications. It's free and open source (released under the MIT license), and provides for DSA signing of application updates. The public key is distributed with the application, and the author keeps the private key. Only the author can issue updates as long as they are the only person with the private key. Even a man in the middle attack would not be able to inject a rogue binary without breaking the encryption.


It's also very easy to integrate and comes with extensive documentation on using each feature. It's not the kind of thing which takes 100 hours to integrate into an existing code base. If you look at the documentation, you'll see how easy it is to set up the DSA signing.

weldon
2006-12-16 18:59:48
This reminds me of the hack to make .mac backup work with your local server because that system doesn't check if the certificate for mac.com is valid. It just wants a certificate.
FJ
2006-12-17 03:55:05
Steve,


It indeed seems that, in an attempt to improve security, some applications again put users in the uncomfortable position of not being able to trust the software that is meant to protect them.


FJ

FJ
2006-12-17 03:58:26
Michael,


A very interesting project indeed! Thanks for reminding us all of it. Let us hope authenticated update mechanisms will either get built into Mac OS X or gain additional traction among developers on all platforms. In any case, that certainly is a big step in just the right direction!


Cheers,
FJ

FJ
2006-12-17 03:59:20
Weldon,


While I am not familiar with the hack myself I indeed imagine that .Mac's rather lax authentication habits open a great many doors for, uh, interpretation!


FJ

Scott Guelich
2006-12-17 06:41:21
What, then, are developers to do? Sign applications? ... Sign the archives? ... SSL the servers? Also. Of course, none of these solutions really is satisfactory: they all involve added expense for the developer and make for heavier server management practices.


SSL is the solution to this problem, and it really doesn't add significant expense on the server side.


What you're proposing is a man-in-the-middle attack, which is analogous to exchanging any critical information between a web server and your web browser. If you fire up Safari, browse go to your favorite ecommerce website, select a few items, and check out -- how can you be sure that when you enter your credit card information the information is going to this site and not being intercepted by a third party? You look for the lock (or other indication) that tells you that your browser has confirmed the identity of the server's SSL certificate.


All applications that exchange critical data (whether exchanging financial data or downloading executable code) should be using SSL. It's not any more complicated to code this into the application, and getting an SSL certificate for your web server doesn't add much to the price of hosting.


I agree that there is a serious, potential risk. But stressing SSL as a solution to this issue would have been much more productive than raising a general oh-no-what-are-we-to-do alarm.


Scott

FJ
2006-12-17 08:03:28
Scott,


My aim was in no way to raise a general alarm and cause undue concern. You will notice that I do mention SSL as one of the steps to take. As the operator of a good few SSL-enabled sites, I am aware of the ease with which certificates are purchased and implemented nowadays. Of course, this does not protect users against all the way as an intruder could gain access to a server and post a rogue version of the application - though that is admittedly a lot more difficult.


Most shareware applications are hosted on shared servers at regular hosts. While some of these shared servers provide great security, not all of them do, making the signing of applications, in addition to the enabling of SSL something of an obligation.


I hope this answers your question,
FJ

Rand
2006-12-17 09:38:52
"The public key is distributed with the application, and the author keeps the private key. Only the author can issue updates as long as they are the only person with the private key."


Or until the public key in the application is replaced with a different public key. If you can't imagine how that could happen, you're not thinking like an attacker.


Sparkle 1.1 has serious bugs, which I found pretty easily. They aren't necessarily security bugs, but they are serious. Personally, I would not place my trust in Sparkle's DSA without doing my own security audit, not after the bugs I found and reported to Andy (unfixed in v1.1).


Even if/when Sparkle is demonstrably secure, an app developer can easily do things, accidentally or intentionally, that completely defeat any security Sparkle provided. While it's possible for an app using Sparkle to have secure updates, it is by no means certain. Use of Sparkle's secure update modes does not imply that app updates are secure, with or without SSL/TLS.

FJ
2006-12-17 09:43:44
Rand,


If you have not done so already, I suggest you get in touch with the Sparkle developers and let them know of your findings. Any contribution towards making updating systems more secure is essential!


Cheers,
FJ

Jake
2007-03-25 15:51:34
How do you make a HOle in the Floor?