Wednesday, September 02, 2009

About Apple’s Security Foundations, Or Lack Of Thereof...

Every once in a while it’s healthy to reinstall your system... I know, I know, it’s almost a heresy to say that, but that’s reality in the world where our systems are totally unverifiable. In fact I don’t even attempt to verify if my Mac laptop has been compromised in any way (most system files are not signed anyway). But sometimes, you got this feeling that something might be wrong and you decide to reinstall to start your (digital) life all over again :)

So, every time I (re)install a Mac-based system, I end up cursing horribly at Apple’s architects. Why? Because in the Apple World they seem to totally ignore the concept of files integrity, to such extent that it’s virtually impossible to get any assurance that the programs I install are in any way authentic (i.e. not tampered by some 3rd party, e.g. by somebody controlling my Internet connection).

Take any Apple installer package, e.g. Thunderbird. In most cases an installer package on Mac is a .dmg file, that represents an installation disk image. Now, when you open such a file under Mac, the OS will never display any information about if this file is somehow signed (e.g. by who) or not. In fact, I’m pretty sure it’s never signed. What you end up with, is a .dmg file that you just downloaded over plaintext HTTP and you have absolutely no way of verifying if it is the original file the vendor really published. And you’re just about to grant admin privileges to the installer program that is inside this file -- after all it’s an installer, so must got root privileges, right (well, not quite maybe)? Beautiful...

Interestingly, this very same Thunderbird installer, but for Windows, is correctly signed, and Windows, correctly, displays that information (together with the ability to examine the certificate) and allows the user to make a choice of whether to allow it to run or not.



Sure, the certificate doesn’t guarantee that Mozilla didn’t put a nasty backdoor in there, nor that the file was not compromised due to Mozilla’s internal server compromise. Or that the certificate (the private key) wasn’t somehow stolen from Mozilla, or that the issuing authority didn’t make a mistake and maybe issued this certificate to some random guy, who just happened to be named Mozilla.

But the certificate provides liability. If it indeed turns out that this very Thunderbird installer was somehow malicious, I could take this signed file to the court and sue either Mozilla, or the certification authority for all the damages it might have done to me. Without the certificate I cannot do that, because I (and nobody) cannot know if the file was tampered while being downloaded (e.g. malicious ISP) or maybe because my system was already compromised.

But in case of Apple, we have no such choice -- we need to take the risk every time we download a program from the Internet. We must bet the security of our whole system, that at this very moment nobody is tampering with out (unsecured) HTTP connection, and also that nobody compromised the vendor’s Web Server, and, of course, we hope that the vendor didn’t put any malicious code into its product (as we could not sue them for it).

So that sucks. That sucks terribly! Without ability to check the integrity of programs we want to install, we cannot build any solid foundations. It’s funny how people divagate whether Apple implemented ASLR correctly in Snow Leopard, or not? Or whether NX is bypassable. It’s meaningless to dive into such advanced topics, if we cannot even assure that at the day 0 our system is clean. We need to start building our systems from the ground up, and not starting from the roof! Ability to assure the software we install is not tampered seems like a reasonable very first step. (Sure it could be compromised 5 minutes later, and to protect against this we should have other mechanisms, like e.g. mentioned above ASLR and NX).

And Apple should not blame the vendors for such a situation (“Vendors would never pay $300 for a certificate”, blah, blah), as it is just enough to have a look at the Windows versions of the same products, and that most of them do have signed installers (gee, even open-source TrueCrypt, has a signed installer for Windows!).

One should say that a few vendors, seeing this problem on Mac, do publish PGP signatures for their installation files. This includes e.g. PGP Desktop for Mac, KeePassX, TrueCrypt for Mac, and a few others. But these are just exceptions and I wonder how many users will be disciplined (and savvy) enough to correctly verify those PGP signatures (in general it requires you to download the vendor keys many months before, keep it in your ring, to minimize possibility that somebody alters both the installer files and the keys you download). Some other vendors offer pseudo-integrity by displaying MD5/SHA1 sums on their websites. That would make some sense only if the website on which the hashes are displayed was itself SSL-protected (still the file signature is a better option), as otherwise we can be sure that the attacker that is tampering with the installer file, will also take care about adjusting the hash on the website... But of course this never is the case -- have a look e.g. at the VMWare download page for the Mac Fusion (one need to register first). Very smart, VMWare! (Needles to say, the VMWare Workstation installer for Windows is properly signed).

BTW, anybody checked if the Apple updates are digitally signed somehow?

All I wrote here in this post is just trivial. It should be just obvious for every decently educated software engineer. Believe me it’s really is much more fun for me to write about things like new attacks on chipsets or virtualization. But I have this little hope that maybe somebody at Apple will read this little post and fix their OS. Because I really like Apple products for their aesthetics...

23 comments:

Anonymous said...

Multiple substantial inaccuracies:

1. "most system files are not signed anyway"

Most every binary or bundle installed on a Mac OS X system is signed. True, there is no UI for looking at individual files, but you can see the signature information for a given bundle or binary by using the codesign(1) command. For example, Mail.app:

$ codesign -v --verbose /Applications/Mail.app; codesign -d --verbose --verbose /Applications/Mail.app
/Applications/Mail.app: valid on disk
/Applications/Mail.app: satisfies its Designated Requirement
Executable=/Applications/Mail.app/Contents/MacOS/Mail
Identifier=com.apple.mail
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=16043 flags=0x0(none) hashes=796+3 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=28
Sealed Resources rules=10 files=530
Internal requirements count=1 size=104

2. "when you open such a file under Mac, the OS will never display any information about if this file is somehow signed (e.g., by who) or not. I'm pretty sure it's never signed."

While it's true that most developers (including Apple) don't sign their packages regularly (the 10.5.8 package is signed), the OS does have package verification capabilities. Developers can sign their packages using the packagemaker(1) command line tool in the Developer Tools suite.

If the lack of signed, verifiable installation media bugs you (which I can certainly understand) then file a bug in Mozilla's/Apple's bug tracking system (as well as those of other distributors you come across) asking them to please sign their packages.

Grzegorz Adam Hankiewicz said...

Hi there.

In this article and the previous one you repeat saying that a signed installer only provides liability to sue the author of the installer.

Is this really serious? IANAL but AFAICS all EULAs and similar software disclaimers and agreements force the user to just ignore the fact that you may have downloaded skynet into your computer and it may soon kill your pet, minutes before nuking earth.

So, what liability are you really talking about? Your ISP? The air in between? While most software can be downloaded through a direct link, there are providers who force you to go through an HTML confirmation page before getting the software, so that may have already forced you to not sue anybody.

Felipe said...

How many mere mortals do know what a PGP signature is? (I'm not even talking on how to check the signature is correct). I'd say less than 15%.

joanna said...

@Anonymous (AKA Mr. Multiple Substantial Inaccuracies):

I'm well ware of the codesign tool and I uphold my statement that most of the *system* files are not signed. E.g. this command will show you how many kernel(!) extensions are not signed:

find /System -name "*.kext" -exec codesign -v {} \;

And just a FYI, Mail.app, is not the best example of a system file;)

Regarding packagemaker and its ability to sign installation packages. It doesn't matter, because Mac OS X doesn't display any message if the dmg/pkg is not signed. So, there is no incentive for application developers to sign their packages -- in the end the user experience will be just the same.

joanna said...

@Grzegorz:
Well, of course, if the vendors writes in the EULA that "this software is going to spy on you and leak out your pgp keys", then it's an interesting challenge for a lawyer (although I still believe that the vendor would be punished for such a trick, just like various companies are often punished for "unfair" clauses in their contracts).

Grzegorz Adam Hankiewicz said...

Well, it's always funny how people sometimes discover these license gems and then slashdot runs some paranoic reality check article.

But I was thinking more in the terms of blocks like this one from the MIT license: "blah blah blah IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY blah blah blah"

I understand they can be malicious or stupid, but either way you are on your own.

joanna said...

@Grzegorz:

Well, IANAL2, but a common sense suggests, at least in the civilized world, you cannot simply sell something to the customer and take zero responsibility for it. Just the fact you write something in the EULA, doesn't exclude you from the (inter)national laws. E.g. can you imagine a car maker selling cars with a "use at your own risk" statement?

Again, neither of us is a lawyer, so lets cut off this discussion at this stage. One is sure at least -- without certificates, no matter what the law was, I couldn't sue anybody for a malicious application. The certificates open this possibility from the technical perspective. And I think that's just grate. (Plus they eliminate the problems with untrusted network connections). Everything else in the hands of courts and lawyers.

Anonymous said...

1. Several of those lines say "Object file format invalid or unsuitable", because you've recursed into the plug-ins of a top-level kext which is signed. The fact that a handful of kexts are unsigned (and most of those are third party code) does not validate your conclusion that "most of the system files are not signed". Most of those kexts won't even load unless you use specific third-party accessories that they're designed to support.

2. To further demonstrate that the kexts are outliers, go through /bin, for example. No unsigned code whatsoever.

3. Mail.app was not intended to be a representative data point, simply an example of how to use the tool, since your post states you "don't even attempt" to verify your system's integrity. Obviously, I misinterpreted that sentence.

4. Mac OS X won't warn you if a package you're installing is unsigned, but it will display a certificate indicator you can use to see that the package is signed (and by whom). Check for digital signature indicia and if you don't trust the package's signer, or the package isn't signed, *don't install the package*. Throwing a warning in the user's face is not a security strategy, it's a nuisance.

5. If installing unverifiable software is annoying to you (and I can certainly understand why it would be) then:

FILE BUGS

with the perpetrators (Apple, Mozilla), or at least describe specifics. Over-generalizing statements like "most of the system files are not signed" will not help anyone *fix* the behavior you're criticizing.

Anonymous said...

Perfectly good article and some of you had to bring law into the comments.

Believe me--if it ever made it to a jury I was on, I'd ignore what the EULA said and rake the vendor over the fire.

As Joanna put it so elegantly--some of us prefer to live in the "civilized world."

On a related note--when dealing with an untrusted HTTP source, I often download the image from my home connection, a proxy in boston, and a proxy in Europe and checksum all of the images for equality. It isn't perfect, but I've always kind of assumed that it'd be a pain in the ass for anyone performing a MITM to do it completely untargeted. Of course, they could always just have stolen the DNS and it wouldn't do any good... but it's better than the nothing HTTP gives me.

joanna said...

@Anonymous-with-whom-we-argue-if-it's-"many"-or-"most"-of-system-files-that-are-unsigned-and-also-if-the-osx-should-warn-about-unverifiable-installers:

1) Can you provide a command that would index *all* binary files on the volume and count how many of them are unsigned vs. signed?

I'm talking here about every possible binary, including libraries, System preference extensions, filesystems, just every potential binary. I don't know how to write one clean command that would find all the files (and verify them). In fact I gave up on the task for doing that log time ago, just after I installed Leopard, because I just saw too many examples of unsigned files. Anyway, it would be interesting to get the numbers (and to see which types os files are still unsigned).

2) I have never seen in my life OSX displaying info about installer being signed. You saying such a possibility exists -- perhaps it does, but why I, as a Mac user, have never seen it? And why I have seen it all the times on Vista? For some reason nobody uses it, and this is precisely the problem I'm point out. Of course, I can try filing bug reports (or emailing support) to a few dozen of app vendors, but, frankly, I don't have time for this. Why I have never had to do that on Vista? Why the very same vendors properly sign their installers for Windows, but don't do that for Mac? Obviously there must be some more generic reason for that.

BTW, can I also sign a DMG file, or only the installer package inside it? What about all those programs that do not use "installer" to install, but that you just "drag to Applications folder" after opening DMG? Sure, if they were signed (but they are not, even iWork '09 is not signed!) I could do codesign on those files inside just-openen-dmg, but, come on, this is not the way a user-friendly system should behave.

julien said...

Mozilla has bugs about this, since 2007.

https://bugzilla.mozilla.org/show_bug.cgi?id=400296
https://bugzilla.mozilla.org/show_bug.cgi?id=409459

Anonymous said...

Thats why windows and probably mac systems are so flawed. Even if os is secure, that winamp.exe you download gets you owned.

This is the most serious security argument over systems without signed software repositories.

I am using ubuntu and all aditional software i install from ubuntu signed repositories. So no problems for me (until skype/picassa needed...)

joanna said...

@Anonymous: Please note that Windows *unlike* Mac OS X, has managed to force most of the (mature) vendors to sign their installers. We shall not pick on Windows for this one thing.

Aleksandar said...

Joanna, you argue about potential problem, not an actual one. What is going to happen to poor Apple uninformed users when they start to run untrusted dangerous installs.

This is not happening. There is no mentionable problem (apart from pirated and tampered with SL install .dmg now and iLife09 before it) out there.
And I'm certain we will never see anything like UAC or signed/unsigned warnings on Mac that exists on Windows (I was Win user for 10+ years and still am at the office). It does not fit in Mac UX. Is it bad or not is irrelevant - it will not happen.

On the topic - I'm sure Ivan Krstić was not hired by Apple to sit and look pretty ;)

joanna said...

@Aleksandar: Can you somehow support your statement about unverifiable installers not being a real problem?

Consider e.g. a freedom fighters in China -- do you really think the Chinese government would not attempt to put a backdoor into the files they download from the net?

macsphere said...

Mac OS X also check whether a new version is signed by the original vendor, and asks the user whether she wants to trust her credentials to the new version.

joanna said...

@macsphere: What are you talking about? Can you be more specific? I have never observed the behavior you mention...

macsphere said...

I wish I could post an image in the comments :)

When you distribute a unsigned update to your app, that uses confidential user information that resides in the Keychain, the OS asks you whether to allow/deny access to this information.

I'm not sure whether this applies to all unsigned apps and not just updates (it's been ages since I read those docs). It probably does. Apple considers the Keychain to be the central repository of sensitive information, so it probably happens (or should happen) with all apps.

joanna said...

@macsphere: Just the fact that Mac will warn when an unsigned .app is accessing keychain, is almost irrelevant. Most apps don't use Keychain at all.

All I want is to know, *before* I install given app (no matter if it's going to use Keychain or not), if it is non-tampered.

garaged said...

i find it more unexplicable when i see the things they are doing with ipods an iphones, specially the arguments they use to control app on the store

Anonymous said...

Greatly overdue response, but...

> 1) Can you provide a command that would index *all* binary files on the volume and count how many of them are unsigned vs. signed?

No, I can't, because I've never actually constructed it. But I would expect that it would involve the following pieces, on a clean system:

1. find -x / (to iterate over the entire boot volume)

2. file (to determine Mach-O binaries from other things)

3. codesign (to determine if the file is unsigned, signed, or a nested resource).

And, it goes without saying: grep.

> 2) I have never seen in my life OSX displaying info about installer being signed. You saying such a possibility exists -- perhaps it does, but why I, as a Mac user, have never seen it? And why I have seen it all the times on Vista? For some reason nobody uses it, and this is precisely the problem I'm point out. Of course, I can try filing bug reports (or emailing support) to a few dozen of app vendors, but, frankly, I don't have time for this. Why I have never had to do that on Vista? Why the very same vendors properly sign their installers for Windows, but don't do that for Mac? Obviously there must be some more generic reason for that.

There is a possibility. For example, if you're on Leopard, download the 10.5.8 combo updater manual package. Installer will start up, and you'll see a little certificate icon in the upper-right corner. If you click it, the Installer will show you information from the signing certificate, including whether its chain validates for that purpose.

There are at least a few I can think of:

Apple isn't signing all of its own packages, as you note below.

Signing a package is a "hard" (as in difficulty) step, involving a command-line tool.

Some software vendors, as I'm sure you know, treat OS X as a second class platform, and don't give its users the effort they deserve.

Apple would induce insane dialogue fatigue if it made installing an unsigned package a drop-everything, must-tell-the-user-now kind of watershed event.

> BTW, can I also sign a DMG file, or only the installer package inside it? What about all those programs that do not use "installer" to install, but that you just "drag to Applications folder" after opening DMG? Sure, if they were signed (but they are not, even iWork '09 is not signed!) I could do codesign on those files inside just-openen-dmg, but, come on, this is not the way a user-friendly system should behave.

To my knowledge, there is no way to sign a disk image directly, as disk images are intended to support writable container file systems. You can sign either an Installer package or an Application bundle for drag-installs (and ideally, you should sign the application your installer installs, even if the installer is itself signed).

Anonymous said...

"BTW, anybody checked if the Apple updates are digitally signed somehow?"

Joanna, did you see K. Chen's Black Hat presentation? Apple didn't sign their keyboard firmware update... I wonder what other surprises Macs have in store.

joanna said...

@Anonymous: Sure it sucks the firmware is unsigned (all firmware reflashing should always require signed updated!). But my question here was rather about the whole update download process -- i.e. whether the Mac's updater application somehow verifies the files it downloads over the *Internet*?