[Spades]

Originally posted by CharlesS:

Yeah right! I highly doubt your statistics without links to back them up. Even if they were true, don't forget that computer processing power increases at a blistering rate. And those signatures are static.

No, actually, that is basically true. Barring a weakness in the cryptographic algorithm or an amazing new way of factoring prime numbers, it really would take effectively the lifetime of the universe to crack a strong key. That's even taking into account the speed at which processing power increases.

Plus, these signatures are not static. Most keys are revokable, and can be set to expire after a certain amount of time.

The reason I wouldn't place too much trust in them is because you don't need to brute force the key to get it. Some classic social engineering, or plain old breaking and entering can get you the key. I don't readily trust most companies to have the security procedures in place to prevent simpler attacks like these.

And in any case, I don't trust most companies to do decent background checking either. $200 may be a disincentive to get a key just for hacking, but that's hardly a foolproof deterrent.

Not to mention, the keys of these trusted authorities are a single point of failure. If one key gets out, it has to be revoked immediately, and that revocation has to be propagated to everyone yesterday, before "patches" signed by Microsoft or Apple start to mysteriously be served from geocities.

Again, signatures are not the ultimate solution. The trust model has to be carefully designed too, and no matter what you do in the end, somebody is going to be inconvenienced.

[Spades]

Originally posted by utidjian:
I think you misunderstand what public/private key signatures do.

I know what they do. A person can sign data using their private key, and anyone else can verify the signature using the public key. Verification of the signature has the effect of both authenticating the signature and checking the consistency of the file.

The only infrastructure one needs for getting genuine public keys is for the creator(s) to publish them on their website(s). Simple.

That would be the worst possible thing to do. If somebody hacks the website, they can not only change the software, but also the signatures (edit: and keys). It's better to have them in separate places.

It is very difficult to establish trust with anyone for that matter. But one tends to trust at least a few vendors. What public/private key signatures do is allow me to trust that the software I download is really from the vendors I trust.

See my previous post. When a few kilobytes of data suddenly becomes very important to computer security, they become a very juicy target.

Plus in the end, it still doesn't prove the person that signed the application isn't a bad guy. If you strictly enforce signing, you either a) don't accept just anyone's signature and relegate freeware/shareware to second class citizens or you b) accept most any signature and lose any benefits of trust.

And, once again, signatures solve the problem of authentication, but the Launch Services problem is a problem of authorization.

[utidjian]

Originally posted by CharlesS:
Yes, but like others have said, how do you know that the signature is valid? There has to be some sort of trusted server you can connect to in order to verify the signature. And that service may not be free. If it costs hundreds of dollars, that is severely eating into the already small income of shareware developers. Freeware devs are completely shut out.

You can be your own server or send it to a third party. Some third party servers cost money (Verisign Thawte) some don't. For instance, it would have cost you nothing but a little of your time (at some point) to publish a public key on your website (http://www.charlessoft.com). If you signed those files that you sent me to put on my server.... you could then easily verify that I had not modified them.... as could anyone else who trusts software from your site.

Yeah right! I highly doubt your statistics without links to back them up. Even if they were true, don't forget that computer processing power increases at a blistering rate. And those signatures are static.

See links in other post.

No offense, but so what?! Okay, so I know that this evil app that has erased my home folder by registering itself as a tn3270: link has not been modified since the evil hacker created it. Oh boy, that's a great consolation!

Simple... don't allow the installation of unsigned apps.

On my production Linux boxes I never install unsigned applications or software of any kind. For those systems I trust software from three origins: fedora.redhat.com, freshrpms.net, and stuff I build and test locally before distributing it to my systems. If the software I try to install is not signed by one of those origins... then it fails to install and tells me why. Most Linux distros are setup this way. The functionality is built into their packaging system already. It is almost completely automated. All the tools are there. ALL the software is handled this way.

I am currently working on a similar system for all the Macs I administer. It is a bit tedious to run around running SoftwareUpdate either physically or via ssh to even a few Macs... even worse when scaled to 300 of them. SoftwareUpdate only works for stuff distributed by Apple directly. So I want to automate all of this as much as possible... download the updates I need from Apple as they become available to my server... then distribute it from there to all the Macs.

[CharlesS]

Originally posted by utidjian:
You can be your own server or send it to a third party. Some third party servers cost money (Verisign Thawte) some don't. For instance, it would have cost you nothing but a little of your time (at some point) to publish a public key on your website (CharlesSoft - software you always wished someone would write). If you signed those files that you sent me to put on my server.... you could then easily verify that I had not modified them.... as could anyone else who trusts software from your site.

But then, what would stop anyone from putting up their own server, making their own signature with my name on it, and writing their own software which will get checked against the signature on their server?

You see, it's for reasons like this that there has to be a central trusted server. The sig check contacts that server and says "I want the public key for Charles S.", the server looks it up and gives it to the user. Otherwise, you can have the sig check contact Mr. E. Vile Hacker's server, tell it "I want the public key for Charles S.", the server says "Okay! (heh heh)" and gives a fake public key with my name encoded in it, the sig check verifies it and what do you know! It works. Clearly, the first method is the only one that's going to be effective, but it will probably not be free.

[CharlesS]

Originally posted by utidjian:
Simple... don't allow the installation of unsigned apps.

I don't understand. You said earlier that signing doesn't ensure who the creator is or that the app is authentic. It only ensures that the app has not been modified since it was created. But what good does that do if the app's original intention was to erase my home folder? If a cracker puts a signature on a malicious app, how does that help me?

[utidjian]

Originally posted by Spades:

That would be the worst possible thing to do. If somebody hacks the website, they can not only change the software, but also the signatures. It's better to have the two in separate places.

I do. But they are served through the same interface. My public keys are mounted from CD-ROM. If that configuration changes I am alerted.

See my previous post. When a few kilobytes of data suddenly becomes very important to computer security, they become a very juicy target.

Plus in the end, it still doesn't prove the person that signed the application isn't a bad guy. If you strictly enforce signing, you either a) don't accept just anyone's signature and relegate freeware/shareware to second class citizens or you b) accept most any signature and lose any benefits of trust.

a) In my mind freeware/shareware software for the Mac are already third class citizens because they don't sign their apps.

b) I don't need to accept most any signature. I only need to accept the signature from the creators of the apps I want to install. If I more or less trust an application from a freeware/shareware vendor I want to be able to download their app from wherever is convenient... and updates. If they were signed it wouldn't matter where I downloaded them from.

And, once again, signatures solve the problem of authentication, but the Launch Services problem is a problem of authorization.

I agree.

[utidjian]

Originally posted by CharlesS:
But then, what would stop anyone from putting up their own server, making their own signature with my name on it, and writing their own software which will get checked against the signature on their server?

Nothing could stop them. BUT for your software I would get the public key from your server.... then I could get your software from anyones server that carries it and be pretty damn sure it came from you and no one else. There is no way I would trust a public key unless I could be reasonably sure it came from you.

You see, it's for reasons like this that there has to be a central trusted server. The sig check contacts that server and says "I want the public key for Charles Srstka", the server looks it up and gives it to the user. Otherwise, you can have the sig check contact Mr. E. Vile Hacker's server, tell it "I want the public key for Charles Srstka", the server says "Okay! (heh heh)" and gives a fake public key with my name encoded in it, the sig check verifies it and what do you know! It works. Clearly, the first method is the only one that's going to be effective, but it will probably not be free.

Yes. For software that comes from you it is enough (for me) that I get the public key from your server. As long as I have a copy of your public key then I can get your packages from anywhere. There is no way the 'sig check' will go to Mr. E. Vile Hacker's server to get the public key unless I allowed it to do so.

[CharlesS]

Originally posted by utidjian:
Nothing could stop them. BUT for your software I would get the public key from your server.... then I could get your software from anyones server that carries it and be pretty damn sure it came from you and no one else. There is no way I would trust a public key unless I could be reasonably sure it came from you.

But how will the sig check know what server is my server? Because it is encoded in the signature? What if this is the first app of mine that you've ever downloaded, and it's a hacked version with a fake signature that claims my site is http://www.evilhacker.com/ ?

[Big Mac]

Let me preface this post by saying I have a considerable amount of respect for you and your work, Charles. I'm just mulling over some of the issues presented in this thread. Now, you seem to be quite unenthusiastic about the prospect of digital signing of applications, since such modes of identification could be hacked. Granted, that is a possibility, but it is a remote one. Moreover, the scenarios you have been citing in order to illustrate your opposition to those security schemes are much more plausible when applied to the regular software distribution situation. With the current, comparatively insecure distribution model we really haven't had any problem. As has been pointed out, the distribution model isn't the vulnerability people are concerned about right now; at best it is an ancillary issue. If some sort of software authentication scheme were developed, it could only improve security. I suppose the real question is whether any of this is actually warranted in terms of opportunity cost to the developer and usefulness to the end user.

[CharlesS]

Originally posted by Big Mac:
Let me preface this post by saying I have a considerable amount of respect for you and your work, Charles. I'm just mulling over some of the issues presented in this thread. Now, you seem to be quite unenthusiastic about the prospect of digital signing of applications, since such modes of identification could be hacked. Granted, that is a possibility, but it is a remote one. Moreover, the scenarios you have been citing in order to illustrate your opposition to those security schemes are much more plausible when applied to the regular software distribution situation. With the current, comparatively insecure distribution model we really haven't had any problem. As has been pointed out, the distribution model isn't the vulnerability people are concerned about right now; at best it is an ancillary issue. If some sort of software authentication scheme were developed, it could only improve security. I suppose the real question is whether any of this is actually warranted in terms of opportunity cost to the developer and usefulness to the end user.

Well, my problem with it is:

1. There's already a problem - the exploits being discussed in this thread.

2. Digital signing is being proposed as a solution to the problem.

3. I don't see how displaying a warning when running a non-signed app can help since evil hackers can easily just put their own certificate on a malware app if said certificates are free.

[Richard Edgar]

I think that the technical, cryptographic problem is perfectly soluble. Unless someone can come up with a way of factorising numbers in polynomial time, each extra bit on the key doubles the time taken to brute force it. If someone does come up with such a way of factorising numbers quickly.... they're probably going to be cracking more interesting messages than software packages.

However, as has been pointed out, digital signatures only authenticate - worse, they don't even authenticate people. They only authenticate that a particular piece of software was signed by a particular key (in this case). So, how do you know that a particular key belongs to a particular person? Well, the same problem is faced by PGP (and its implementations, such as GPG). That's where the web of trust comes in. Everyone has their own keypair, and signs the keys of people they know and have verified directly and personally (to avoid man-in-the-middle attacks). However, therein lies a problem: not that many people have PGP keypairs (and also know the importance of carefully verifying keys - I certainly didn't at first. Luckily, I didn't get bitten by it). PGP certainly doesn't have a critical mass of people using it at the moment.

Even if you regard authentication as good enough for authorisation (that is, if you are happy to let anything known to be written by person X run on your machine), what then? Have you read any software licences recently? Whether commercial or open source, they tend to disclaim any and all responsibility for what the code does when run. So what have you gained in the end? You know exactly who isn't going to care that their program just wiped your hard drive.

[sniffer]

Originally posted by CharlesS:
Well, my problem with it is:

1. There's already a problem - the exploits being discussed in this thread.

2. Digital signing is being proposed as a solution to the problem.

3. I don't see how displaying a warning when running a non-signed app can help since evil hackers can easily just put their own certificate on a malware app if said certificates are free.

Agree it gives a false sense of security, AND in this case, or problem if you like, it's comparable to go fishing with dynamite. It's just something you don't do.
I know this isn't the time or place to tout your own ideas, but I've been into the issue earlier, and I think a variant of signed apps is a good idea. But as I see it, it should only be a measure to tell the OS that this or this app is capable of handling insecure documents, totally out of the way and invisible for the end-user. It should be a standard on OS level, not user level. And only granted apps should be added to the list of protocol helpers and perhaps other areas where this might become useful (like in firewall filters for instance?). It would not be about making a system unbreakable (or troublesome for the developers), just about setting a standard for the apps that are intentionally designed for handling insecure documents in the first place. Like an approval from its developer if you like. It would certainly not stop tn3270: hijackers but that's not the point. No more Help Viewer exploits is the key here. There are several, as mentioned earlier, alternative approaches to overcome hijacking. I see the th3270: issue more like an engineerings mistake than anything, if I am allowed to say so... No wait [edit] this whole issue is an engineerings problem IMO.

[utidjian]

Originally posted by CharlesS:
But how will the sig check know what server is my server? Because it is encoded in the signature? What if this is the first app of mine that you've ever downloaded, and it's a hacked version with a fake signature that claims my site is http://www.evilhacker.com/ ?

OK... perhaps an example will help.

For my Linux systems one of the creators of packages that I trust is Mattias Saou of freshrpms.net. Matthias creates very good add on packages for Red Hat and Fedora Core. He and the quality of his packages are very highly thought of in the community. On his website he has published the matching public key for the private key he uses to sign all packages from his website.

The public key is available here:
http://freshrpms.net/packages/RPM-GPG-KEY.txt

I download that file and save it as plain text.

On each system I want to use his packages on I do this:

rpm --import RPM-GPG-KEY.txt

once. If he changes the key I will have to download it and 'import' it again.

When I want to install a package made by him all I do is first download it... from wherever... even from http://www.evilhacker.com

Next I install the package I have downloaded like this:

rpm -ivh packagename.rpm

If the signature is valid the install proceeds. If it is not valid the install never writes a single file on my system and complains.

Simple.

There is no need for RPM to check any other server because it has all the information it needs. It doesn't even need a network connection because the package could be on a CD or HDD.

There are GUI apps that can do all this also (up2date, synaptic, redcarpet).

It is even easier than that... I can run:

yum update

and it will automatically download, checksum, checksig, and check and fulfill dependencies for all updates. It does this automatically for all packages on my system grabbing the latest updates. If any of the tests fails the install of that package fails and the system complains. This can be automated even further by turning on a simple cronjob. This is basically what the command:

sudo softwareupdate -a -i

does on my Mac OS X systems. Though I am not so sure that it checks any kind of signature.

Yet it is even easier than that... I also have public keys from fedora.redhat.com and my local signature 'import'ed. Each machine has an identical /etc/yum/yum.conf file that points to all those sources, including a repository on my local server for packages. Then a simple:

yum update

will update any required packages for ALL the software I have on my systems with all the required checks.

But wait... it should be even easier than that! I have a cronjob on one of my servers that will rsync all updates to my local server. If there is anything new it alerts me. I test the updates on my test system and when I am satisfied that it does't break anything I trigger the update job to all the other systems. The other client systems automatically check for the trigger flag and update themselves accordingly. All of this is centrally logged. At any given moment in time I know exactly what has been installed/upgraded on any of my systems. I also know if a system did not get an update or had some sort of problem. It "just works".

The above scheme was very easy to setup in Linux. All of the tools are there. I have been using this scheme (or one very similar) for several years now. The public key system allows me to do this sort of thing with some confidence that it is being done correctly and from sources I trust.

[turtle777]

Originally posted by utidjian:
OK... perhaps an example will help.

For my Linux systems one of the creators of packages that I trust is Mattias Saou of freshrpms.net. Matthias creates very good add on packages for Red Hat and Fedora Core. He and the quality of his packages are very highly thought of in the community. On his website he has published the matching public key for the private key he uses to sign all packages from his website.

I think, the whole issue of digitally signed packages goes far beyond our initial problem here.

The problem is: a malicious application could be installed without user KNOWLEDGE ! That's where a fix from Apple has to come.

I agree with with Big Mac.

Originally posted by Big Mac:

With the current, comparatively insecure distribution model we really haven't had any problem. As has been pointed out, the distribution model isn't the vulnerability people are concerned about right now; at best it is an ancillary issue.

The issue you are trying to tacle with digital signatures is the problem of trojan horses.
As well all know, they are technically feasible, but in real life, not an issue (yet).

So far,
-t

[Developer]

Originally posted by CharlesS:
I don't see how displaying a warning when running a non-signed app can help since evil hackers can easily just put their own certificate on a malware app if said certificates are free.

Because when you browse the web and suddenly are asked whether you'd like to run an app signed by [email protected] you will not let it run. Today it just executes via the evil: protocol exploit without user interaction.

[utidjian]

Originally posted by CharlesS:
Well, my problem with it is:

1. There's already a problem - the exploits being discussed in this thread.

2. Digital signing is being proposed as a solution to the problem.

3. I don't see how displaying a warning when running a non-signed app can help since evil hackers can easily just put their own certificate on a malware app if said certificates are free.

1. I agree.

2. I am not proposing digital signing as a solution to the current 1.

3. I am not proposing a click-through certificate system. The system I am proposing is one that already exists, works, and works well. It would require that the user visit the website of the app creator and download and install the public key. This could be a 'clickable' kind of thing but the for the first time for a given creators apps it will not be transparent.... the user has to visit the website of the creator.

[utidjian]

Originally posted by turtle777:
I think, the whole issue of digitally signed packages goes far beyond our initial problem here.

The problem is: a malicious application could be installed without user KNOWLEDGE ! That's where a fix from Apple has to come.

I agree.

I agree with with Big Mac.

The issue you are trying to tacle with digital signatures is the problem of trojan horses.
As well all know, they are technically feasible, but in real life, not an issue (yet).

So far,
-t

I also agree.

[alcatholic]

Originally posted by utidjian:
3. I am not proposing a click-through certificate system. The system I am proposing is one that already exists, works, and works well. It would require that the user visit the website of the app creator and download and install the public key. This could be a 'clickable' kind of thing but the for the first time for a given creators apps it will not be transparent.... the user has to visit the website of the creator.

Hmm, that's very good. I never understood the certificates of the type:
"Do you trust Microsoft, Inc.?" I could never bring myself to trust the certificate. How do I know who made the certificate?

But, a public key system sounds much better. I could go to Charles' website, decide I want his software, download his public key, then download his software...interesting. Then when launch services registers an app it will check the private key, see if I have the public key, and warn me if I don't. Of course if Charles want to send me malware I'm in trouble. This could work, but only if the key system is free for Charles.

[alcatholic]

Originally posted by Richard Edgar:
Even if you regard authentication as good enough for authorisation (that is, if you are happy to let anything known to be written by person X run on your machine), what then?

I think the point is that you would be warned when a non-authenticated app was trying to load onto your computer.

This is sort of what smeger tried to do with PA, i.e. warn us that an app was attempting to register with LaunchServices. Public Key System is another way to do that kind of thing, along with other benefits, I guess.

[Spades]

Digital signatures just aren't a good general solution. There are plenty of cases where they are a good solution, but they will never be acceptable in every case. You will see that there is no case that is fair, secure, and easy.

You accept signatures by untrusted keys.
-You gain no security from this.

You accept signatures by trusted keys.
-So what do you trust?

Require the user to retrieve the key manually.
-This is an acceptable solution in some cases. If you know how to find the key, know how to decide whether to trust it, and know how to make it trusted, this works. If you're a system and network administrator, great. Your problem is solved. But most people aren't system and network administrators. This is too complicated and time consuming for most people to do. You lose ease of use with this. Even if you can make it easy, most users will just trust everything. You gain no security from this.

Click-through trusting of keys.
-Most users will just click yes. You gain no security from this.

Implicitly trusted keys in the OS.
-This is also acceptable in some cases. For example, OS patches from Apple should be signed by Apple. However, as an absolute protection scheme this is unfair to freeware/shareware developers.

Have the keys signed by a trusted signing authority.
-What does it take to get your key signed?

Free signing by trusted authorities.
-Anybody, even bad people, can get their key signed. You gain no security from this.

Paid signing by trusted authorities.
-This is unfair to freeware/shareware developers. In addition, having to pay money is not a foolproof deterrent to a person who really wants to do damage, so you only gain some security from this.

So I don't see any practical method of using digital signatures as a general protection scheme. Fair, secure, easy. Pick two.

[utidjian]

Originally posted by alcatholic:
Hmm, that's very good. I never understood the certificates of the type:
"Do you trust Microsoft, Inc.?" I could never bring myself to trust the certificate. How do I know who made the certificate?

Well those certificates are made by places like Verisign.

But, a public key system sounds much better. I could go to Charles' website, decide I want his software, download his public key, then download his software...interesting. Then when launch services registers an app it will check the private key, see if I have the public key, and warn me if I don't. Of course if Charles want to send me malware I'm in trouble. This could work, but only if the key system is free for Charles.

You almost have that right. It could be that when LS registers an app it checks the apps signature against the public keys you have already registered with it. The signature on the app can ONLY be created with the matching private key which Charles has. LS never needs to see the private key.

The PGP/GnuPG system can never insure against Charles providing you with malware. It also wouldn't have stopped the iTunes update from Apple that wiped out some hard drives that were named a certain way.

To do this would require a fundamental change in how LS works and how the regular installer works. This would have to come from Apple.

I am not sure why Apple didn't include this functionality in the first place. I can only speculate that they felt that it would force developers to change how they create and distribute their software and that this change would be awkward and unwelcome. They may have also felt that it would change the freewheeling way we have used to for installing and running any old app. They may have also felt that, so far, the issue of malware has not been a problem. Because of this they seem to have decided that it should be really easy for software to automatically install itself... it is a feature. And so we are left with the situation we have today.

[turtle777]

Originally posted by Spades:
Digital signatures just aren't a good general solution. There are plenty of cases where they are a good solution, but they will never be acceptable in every case. You will see that there is no case that is fair, secure, and easy.

Thanks, Spades.

That sums it up quite well.
For our discussion topic, digital signatures and certificates are NOT a solution.
Too many exceptions, too complicated, yet too easy to fool the average user.

I think the whole "signature road" is a dead end.

-t

[alcatholic]

Anyone else pickup that PA does not seem to protect against the App Hijacking exploit?

Ironically, App Hijacking is a type of trojan horse,no?

[Spades]

Before I say anything else, I just want to make sure.

App Hijacking means you can make an application that can pretend to be a newer version of an application and take over the URI scheme, right?

[Richard Edgar]

On his website he has published the matching public key for the private key he uses to sign all packages from his website.

The public key is available here:
http://freshrpms.net/packages/RPM-GPG-KEY.txt

I download that file and save it as plain text.

I would rather hope that you have better grounds than that for believe that it is his key. If your belief rests on the fact you 'downloaded it from his website' you are not really in a better position than untrusted downloads. It just means that subverting your system is a little harder.

[turtle777]

Originally posted by alcatholic:

Ironically, App Hijacking is a type of trojan horse,no?

Why ironically ?

There is no sure protection against trojan horses.
Behind every program that you execute could be malicious code.
At least, your home folder is in danger.

But that's not the issue here.
It doesn't matter what kind of application gets executed, there shouldn't be any way to execute programs through HTML in the first place.

-t

[CharlesS]

Originally posted by utidjian:
OK... perhaps an example will help.

For my Linux systems one of the creators of packages that I trust is Mattias Saou of freshrpms.net. Matthias creates very good add on packages for Red Hat and Fedora Core. He and the quality of his packages are very highly thought of in the community. On his website he has published the matching public key for the private key he uses to sign all packages from his website.

The public key is available here:
http://freshrpms.net/packages/RPM-GPG-KEY.txt

I download that file and save it as plain text.

On each system I want to use his packages on I do this:

rpm --import RPM-GPG-KEY.txt

once. If he changes the key I will have to download it and 'import' it again.

When I want to install a package made by him all I do is first download it... from wherever... even from http://www.evilhacker.com

Next I install the package I have downloaded like this:

rpm -ivh packagename.rpm

If the signature is valid the install proceeds. If it is not valid the install never writes a single file on my system and complains.

Simple.

There is no need for RPM to check any other server because it has all the information it needs. It doesn't even need a network connection because the package could be on a CD or HDD.

Okay, that sounds like it work pretty well for a Linux user, as Linux users tend to be more savvy than the common folk. Of course, you have to be really sure that the public key you downloaded was actually from the developer, and that you didn't get tricked by a site using address spoofing or something similar.

However, what about the average Joe Mac user (or even worse, the average Joe Windows user)? They are not going to know to get this public key, and they will not appreciate the extra step needed to do so. Heck, for the longest time, I was obligated to hunt down the virus definition update files and e-mail the links to my father every month, because he couldn't be bothered to go track down the files themselves on the anti-virus company's web site. If we ask users like him to track down two files on a server, they'll almost certainly just download the app and dismiss any warning.

There are GUI apps that can do all this also (up2date, synaptic, redcarpet).

It is even easier than that... I can run:

yum update

and it will automatically download, checksum, checksig, and check and fulfill dependencies for all updates. It does this automatically for all packages on my system grabbing the latest updates. If any of the tests fails the install of that package fails and the system complains. This can be automated even further by turning on a simple cronjob. This is basically what the command:

sudo softwareupdate -a -i

does on my Mac OS X systems. Though I am not so sure that it checks any kind of signature.

Okay, but what happens if you don't already have the public key for one of those dependencies or updates? Does it automatically download it from somewhere? How does it know where to get the key from?

[alcatholic]

Originally posted by Spades:
Before I say anything else, I just want to make sure.

App Hijacking means you can make an application that can pretend to be a newer version of an application and take over the URI scheme, right?

Correct. The newer version of the app is registered and when itms: needs iTunes, LaunchServices gives it the highest version # iTunes it's registered. Even with a PA type warning whose going to say, "no, don't launch iTunes." (assuming the trogan horse uses the iTunes name.)

But this suggests a solution Peter de Silva spelled out(sorry to bring him up again).

by turtle777
It doesn't matter what kind of application gets executed, there shouldn't be any way to execute programs through HTML in the first place.

-t

What if the browser doesn't see that there is a newer version of iTunes that just registered? The browser has a list separate from LaunchServices, call it SafeLaunchServices, where the protocols are all registered manually/somehow securely. This list shouldn't autoregister and so a URL couldn't launch hijacked apps via a browser or any app that used the list.


Here is part of de Silva's letter.

Having a single set of bindings for trusted and untrusted sources is why Internet Explorer and Outlook have been security nightmares for most of the past decade.

I can understand Microsoft doing this: they have political reasons for "integrating" the desktop and the browser (they're not good reasons... trying to weasel out of an agreement with the DoJ is never a good reason). I can't understand Apple, though: there should be at least *two* unrelated sets of bindings... one to be used for applications that work with local documents and one for applications that work with untrusted documents... and the bindings for applications that work with untrusted documents should be *absolutely* minimal.

In fact, by default and in the absence of explicit uuser action nothing should ever be transferred from an untrusted document to another application...

[utidjian]

Originally posted by Spades:
Digital signatures just aren't a good general solution. There are plenty of cases where they are a good solution, but they will never be acceptable in every case. You will see that there is no case that is fair, secure, and easy.

You accept signatures by untrusted keys.
-You gain no security from this.

You accept signatures by trusted keys.
-So what do you trust?

Simple. I trust the packages that have a signature that matches the keys that I trust.

Require the user to retrieve the key manually.
-This is an acceptable solution in some cases. If you know how to find the key, know how to decide whether to trust it, and know how to make it trusted, this works. If you're a system and network administrator, great. Your problem is solved. But most people aren't system and network administrators. This is too complicated and time consuming for most people to do. You lose ease of use with this. Even if you can make it easy, most users will just trust everything. You gain no security from this.

The difference is the user is at least aware at least once that they are trusting a specific source of software. The alternative to that is what we have now. The user has no choice whether to trust it or not... "it just works".

Click-through trusting of keys.
-Most users will just click yes. You gain no security from this.

Depending on how you implement it yes, most users will 'click-through' the accepting of the public key. That is the users choice, and always will be. After they have clicked-through and accepted a particular creators public key the system can install and run any application created and properly signed by that creator. No more user intervention will be required. If, however, the user encounters a package that claims to be from a creator that it already trusts AND the package is not properly signed by the creator they trust then it will fail to install and run.

Note: The systems I am familiar with that use PK (public/private keys) do not use a key that is included with the package. The public key must be retieved from the creators website. Yes, this would involve extra mouse-clicks but it only has to be done once for a particular creator.

Implicitly trusted keys in the OS.
-This is also acceptable in some cases. For example, OS patches from Apple should be signed by Apple. However, as an absolute protection scheme this is unfair to freeware/shareware developers.

Sure. The public keys for Apple and any other vendor that Apple trusts (Adobe, MS, whatever) could be included. No need for the user to get those separately. A vendor could include the file on their software distribution CDs.

No protection scheme is absolute... I never claimed otherwise. This is no more unfair to freeware/shareware developers than Apple not including the their software in the original install/restore CDs (or DVDs).

Have the keys signed by a trusted signing authority.
-What does it take to get your key signed?

Why should I trust a CA any more than I trust the website of the creator whose software I am about to download and install on my system?

As far as I know the only thing required by places like Verisign for a COA is for the applicant to pony up the bucks.

Free signing by trusted authorities.
-Anybody, even bad people, can get their key signed. You gain no security from this.

True. Even bad people can get their keys signed by a CA. The cost only raises the bar of entry for both good and bad people.

Paid signing by trusted authorities.
-This is unfair to freeware/shareware developers. In addition, having to pay money is not a foolproof deterrent to a person who really wants to do damage, so you only gain some security from this.

Right. See above.

So I don't see any practical method of using digital signatures as a general protection scheme. Fair, secure, easy. Pick two.

I am not claiming that digital signatures are, by themselves, a 'general protection scheme' so I am not surprised that you can not see it as a practical method for providing that.

PK are 'fair' if you use one of the free variants of the scheme.

PK are 'secure' if you trust the security of the creator of the package you are about to install on your system.

PK are 'easy' if one designs a method to make it fairly easy for the creator to distribute their public key and for the user to accept it.

[dan7352]

Originally posted by turtle777:
It doesn't matter what kind of application gets executed, there shouldn't be any way to execute programs through HTML in the first place.

-t

That's being too repressive. Would you be forbidding Java apps? How about playing MIDI from a browser if the browser doesn't have a MIDI synth built in?

What is needed (which happens to fall into Apple's area of expertise) if for Apple to develop the Human Interface Guidelines for Security when dealing with Active Content.

We are all familiar with the concept of a sandbox which lets foreign apps play without risk to our system. What is missing are the rules that assure nothing will get in or out of the sandbox without the explicit consent of the local user. There is no problem downloading a file or mounting a volume within the sandbox. But moving the file or volume out of the sandbox should require that the user drag it out.

Even simple actions such as opening a new view should require at least a mouse click. Unfortunately popups would then be confined to within the current sandbox view and would all go away when the view is closed :-)

[utidjian]

Originally posted by Richard Edgar:
I would rather hope that you have better grounds than that for believe that it is his key. If your belief rests on the fact you 'downloaded it from his website' you are not really in a better position than untrusted downloads. It just means that subverting your system is a little harder.

Sure. At some point I have to start trusting someone somewhere otherwise I might as well turn all these boxes off... or just use them for games.

It is pretty easy for me to 'trust' the public key published on his website be cause it also works with all the applications published on his website.

There are also extra benfits to the PK scheme. Freshrpms.net also mirrors the 'official' updates site for Fedora Core:
http://download.fedora.redhat.com/pu.../core/updates/

problem for many users is... that site can be incredibly busy. It can take a long time for the smallest of updates to be downloaded and installed. However, I can download those exact same updates from freshrpms.net or any other mirror on the Internet (including my own) and be pretty damn certain that the updates are genuine. I can do this because they are signed by fedora.redhat.com and I have a copy of their public key installed.

This advantage of the PK scheme can actually benefit the freeware/shareware software creators and the end user. The end user can have a reasonable level of assurance that the software was created by the creators they trust no matter where they get the copy from. This makes it much easier for the creator to distribute their software.

[Spades]

Originally posted by alcatholic:
Correct. The newer version of the app is registered and when itms: needs iTunes, LaunchServices gives it the highest version # iTunes it's registered. Even with a PA type warning whose going to say, "no, don't launch iTunes." (assuming the trogan horse uses the iTunes name.)

Then how about the user must either change it manually in preferences, or the new application must have physically replaced the old one first? Assuming the other problems are fixed, a downloaded application can't automatically overwrite the other application. The user has to do it. If the user has to drag the new application over the old one, I think that's all the interaction and all the chance that is needed to confirm the user really wants this.

[Charc]

Hi folks.

First, kudos for discovering these security flaws before they're exploited. It was very interesting to read the thread after the fact and see the different participant's great insights lead to a nice understanding of the situation.

Second, what would you think of the following summary and way to fix things?

It seems the basic problem here is that Launch Services' current behavior means that any file made accessible to a user's computer in any way (disk:, ftp:, afp:, but also NFS or other remote disk mounting) is implicitly given the permission to be launched without the user's intervention (via an evil: protocol or application hijacking by a higher versioned evil application). In short, Launch Services' behavior means mounting a disk or disk image is equivalent from a security perspective to running any program on that disk... not exactly what a user would expect!

Simply making it harder to mount disks would not fix this: It would be unreasonable to expect all users to believe that trust-to-mount = trust-to-run, and so relatively easy for an attacker to convince victims to mount a remote file system, and in doing so get them to run malware. Also, trying to fix things this way would break reasonable uses of remote disk mounting, such as viewing and copying non-program files from a server not necessarily trusted to run programs from, or wanting to view files on a server before deciding whether to run files from that server. Things would be particularly problematic in environments like academic ones where ad-hoc remote access to files is common.

Thus fixing things requires breaking or loosening the tie that Launch Services makes between mounting and running. Unfortunately, this threatens an important aspect of Mac OS's ease of use. Here's one way the tie could be loosened enough for safety without harming that ease of use too much: LaunchServices could recognize and record document or protocol bindings when it comes across new applications, but mark those bindings as new and untrusted, and require that the user confirm the bindings the first time they're used (with an alert panel asking whether it's OK to run the corresponding application, giving the location of the application and the reason why it's being launched). This would avoid requiring the user to manually locate the applications needed to handle particular documents or URLs, but ensure that no program is run without a user's knowledge.

The original bindings shipped with the system would be trusted, of course, as would any ones for applications installed as part of a package. Bindings for applications on local disks could also be automatically trusted. Finally, a user could be given a place (for example their keychain) to keep PGP public keys of trusted application authors, and the bindings for applications signed by these authors would be automatically trusted. This would allow applications to be shared in a corporate or educational network. Minimizing the number of untrusted bindings would ensure that the untrusted binding warning is rarely presented to the user, which would allow that warning to be taken seriously.

Let me know what you thing,

- Charles (another one :-)

PS: I realize this is purely an intellectual exercise, and hope that Apple's fix, whatever that is, is already implemented and being tested.

[smeger]

Charc, I think that's the best solution I've seen yet. Maintaining the fabled Mac "ease of use" is very important, and shouldn't be discarded lightly.

As I understand your solution, a flag would be added to each entry in the Launch Services database. When set, any use of that database entry would present a notification to the user and would require user permission to proceed. Executing the corresponding application would clear the flag.

The flag would be set by default when the Launch Services database entry is created.

There could be lots of ways for the flag to be cleared - installing an app using Apple's Installer.app would do it, Software Update would do it, etc.

The net result would be that you would see the notification and be forced to respond only when double-clicking a document that launches a newly-registered app that's never been run before, or when being hit with a URI exploit like what we've been talking about.

I like it.

[CharlesS]

Charc - that could work, and be a good way to prevent what Developer has entitled the fantasy protocol attack. The one problem I see is that users may dismiss dialog boxes without reading them.

[VValdo]

Not to change the subject from signed applications too much, but I just noticed on versiontracker.com that 10.3.4 is out. Does anyone know:

1. Does Paranoid Android create difficulties in upgrading?

2. Has Apple addressed/solved any of these security issues in 10.3.4?

3. If not, does PA still work in 10.3.4?

I'm upgrading now, and if I notice anything going wrong, I try to report back.

Here are the official notes from software update. I don't see anything about new security updates being included.

W

--------

Key enhancements include:
� improved file sharing and directory services for Mac (AFP), UNIX (NFS), PPTP, and wireless networks
� improved OpenGL technology and updated ATI and NVIDIA graphics drivers
� improved disc burning and recording functionality
� iPods connected via USB 2.0 are now recognized by iTunes and iSync
� additional FireWire audio and USB device compatibility
� updated Address Book, Mail, Safari, Stickies, and QuickTime applications
� improved compatibility for third party applications
� previous standalone security updates

For detailed information on this Update, please visit this website: http://www.info.apple.com/kbnum/n25764

[VValdo]

After updating, had a blank blue screen when trying to restart and finally had to manually restart it, but everything seems to be alright. Finder reports 10.3.4...

Paranoid Android 1.2 works as usual, but from a report on another thread, the main app registration problem still seems to be in effect

W

[alcatholic]

Originally posted by Charc:
Thus fixing things requires breaking or loosening the tie that Launch Services makes between mounting and running. Unfortunately, this threatens an important aspect of Mac OS's ease of use. Here's one way the tie could be loosened enough for safety without harming that ease of use too much: LaunchServices could recognize and record document or protocol bindings when it comes across new applications, but mark those bindings as new and untrusted, and require that the user confirm the bindings the first time they're used

Great post.

The loosening you propose between mounting and running is gentle and deep. It might be wise to increase the Mac's general security in the way you suggest. Especially considering a future involving broadband and the many network services it will bring.

Yes, a general modification of the Mac's LaunchServices is probably needed, and yours seems clever.

[Person Man]

Originally posted by CharlesS:
Charc - that could work, and be a good way to prevent what Developer has entitled the fantasy protocol attack. The one problem I see is that users may dismiss dialog boxes without reading them.

I think it's a good idea, myself. As far as people just clicking through the dialog box, well, nothing is foolproof without completely destroying the Mac's ease of use. The people who will just click through without reading things do so at their own risk. That has always been the case, though.

I would modify things slightly, however. Mac OS X comes with a few URI scheme handlers preset for some applications that aren't part of a default install. I would also put up the dialog box the first time any of those are used, too. I would also put up the dialog box the first time an application was changed, to prevent hijacking by masquerading as a newer version of an existing app.

[Person Man]

[QUOTE]Originally posted by VValdo:
[B]Not to change the subject from signed applications too much, but I just noticed on versiontracker.com that 10.3.4 is out. Does anyone know:

1. Does Paranoid Android create difficulties in upgrading?

2. Has Apple addressed/solved any of these security issues in 10.3.4?

3. If not, does PA still work in 10.3.4?

I'm upgrading now, and if I notice anything going wrong, I try to report back.

Here are the official notes from software update. I don't see anything about new security updates being included.

W

--------

Answers: 1. No difficulties

2. Apple has only addressed the original problem discussed in the thread: the Help Viewer runscript exploit. Everything else was first discovered and reported to Apple in the last 2 weeks or so, and the problem is SO complex and deeply rooted in the operating system that to expect a PROPER (not an untested knee-jerk fix that some people might demand--- "Apple should come out with the fix the instant the problem is reported to them" is NOT reasonable) fix in any time less than a month or two is being a bit unreasonable. Until then, there are several workarounds, none of which is perfect, but better than nothing, at any rate.

3. I'm not sure if PA works in 10.3.4. I don't see why it wouldn't, though.

Apple usually rolls in the last several security updates in their 10.3.x installers. The latest update, dated 5/24/04 might have been too new to be included in 10.3.4, however.

[Person Man]

duplicate post deleted.

[dan7352]

The net result would be that you would see the notification and be forced to respond only when double-clicking a document that launches a newly-registered app that's never been run before, or when being hit with a URI exploit like what we've been talking about.

I like it.

I hate it.

You're all thinking like programmers and forgetting the human factors. You need to develop a clear metaphor in the users view of what is happening or the rules will get fuzzy and more leaks will occur.

One metaphor to use is that the browser is a window into another world. Nothing in that other world should affect the operation of the users computer. When the user drags an object from that other world into his world that object becomes part of the users computer system. At that time if there is a security concern the user can be prompted to confirm the action. If you wait for an application to be accessed before bringing up the warning the user will have lost the context of where the application came from.

-- Dan O.

[KrayZ]

Originally posted by dan7352:
One metaphor to use is that the browser is a window into another world. Nothing in that other world should affect the operation of the users computer. When the user drags an object from that other world into his world that object becomes part of the users computer system. At that time if there is a security concern the user can be prompted to confirm the action.

Yeah, that's more Peter da Silva's approach; two separate sets of bindings, with user intervention required to move new bindings to the "trusted" set.

Launch Services for browsers and separate Launch Services for local documents.

[sniffer]

Originally posted by dan7352:
I hate it.

You're all thinking like programmers and forgetting the human factors. You need to develop a clear metaphor in the users view of what is happening or the rules will get fuzzy and more leaks will occur.

One metaphor to use is that the browser is a window into another world. Nothing in that other world should affect the operation of the users computer. When the user drags an object from that other world into his world that object becomes part of the users computer system. At that time if there is a security concern the user can be prompted to confirm the action. If you wait for an application to be accessed before bringing up the warning the user will have lost the context of where the application came from.

-- Dan O.

Agree. This factor can't be overlooked, not even here in this theoretical discussion if our objective is to come up with ideas that would have somewhat relevance with the Apple model of doing things. Personally I am not sure if I like the idea of using "confusing/scary" pop-ups at all since it's an open question if such a measure will be well taken by grandmother, but your perspective is a very fundamental correct one nevertheless.

[sniffer]

Originally posted by KrayZ:
Launch Services for browsers and separate Launch Services for local documents.

Yep, it makes sense. And it should be designed clever enough to avoid another unnecessary Help Viewer exploit which IMO shouldn't have been there in the first place.

[Richard Edgar]

It is pretty easy for me to 'trust' the public key published on his website be cause it also works with all the applications published on his website

You've completely ignored my point. When you instruct your machine to connect to his website, how do you know that it really connects to his website? If you have not verified the key through a medium other than the 'net, the answer is simple: you don't. And as a result, you have gained nothing by your efforts. You have done nothing to mitigate the main failure mode of public key cryptography - the man-in-the-middle attack.

[CharlesS]

Originally posted by dan7352:
I hate it.

You're all thinking like programmers and forgetting the human factors. You need to develop a clear metaphor in the users view of what is happening or the rules will get fuzzy and more leaks will occur.

One metaphor to use is that the browser is a window into another world. Nothing in that other world should affect the operation of the users computer. When the user drags an object from that other world into his world that object becomes part of the users computer system. At that time if there is a security concern the user can be prompted to confirm the action. If you wait for an application to be accessed before bringing up the warning the user will have lost the context of where the application came from.

-- Dan O.

Exactly. You hit the nail on the head - the user will think "Oh, it's fine, I'm just browsing" and hit the OK button without reading the dialog.

How about this one:

1. When a protocol is bound to an app, LS remembers the AliasRecord of the actual physical app bundle that it's bound to. If a new version of the same app shows up, LS keeps using the old app unless the new app actually gets launched. This should close the version number exploit.

2. When a new app shows up, LS caches its creator code and supported URL schemes, as usual. But, it does not bind any protocols to the app, it just takes note of what it supports. At the time the app is launched, LS can then cache the AliasRecord of the app for any protocols that it supports that are not already handled. This should tie up the fantasy protocol exploit while retaining Mac-like behavior for documents that are double-clicked in the Finder.

3. Internet Config is changed so that it no longer binds protocols to creator codes (which are obsolete anyway - bundle IDs are the replacement). Instead, it binds protocols to specific AliasRecords of apps. This should tie up the creator code exploit. Unfortunately, it would require rewriting a good bit of LaunchServices and Internet Config, and would break setup apps like More Internet. But I think it would tie up the problem.

What do you think? Any holes/potential exploits in that?

[Diggory Laycock]

Originally posted by CharlesS:

3. Internet Config is changed so that it no longer binds protocols to creator codes (which are obsolete anyway - bundle IDs are the replacement). Instead, it binds protocols to specific AliasRecords of apps. This should tie up the creator code exploit. Unfortunately, it would require rewriting a good bit of LaunchServices and Internet Config, and would break setup apps like More Internet. But I think it would tie up the problem.

What do you think? Any holes/potential exploits in that?

I'd happily lose IC - as soon as Apple adds public methods to alter the preferred bindings through LS - at the moment LS is read-only if you're not an Apple Developer.

[Hugin777]

Originally posted by VValdo:
2. Has Apple addressed/solved any of these security issues in 10.3.4?

AFAIK the telnet: and ssh: exploits have been fixed in 10.3.4, but not any of the three found in this thread.

[Charc]

Originally posted by CharlesS:

How about this one:

1. When a protocol is bound to an app, LS remembers the AliasRecord of the actual physical app bundle that it's bound to. If a new version of the same app shows up, LS keeps using the old app unless the new app actually gets launched. This should close the version number exploit.

2. When a new app shows up, LS caches its creator code and supported URL schemes, as usual. But, it does not bind any protocols to the app, it just takes note of what it supports. At the time the app is launched, LS can then cache the AliasRecord of the app for any protocols that it supports that are not already handled. This should tie up the fantasy protocol exploit while retaining Mac-like behavior for documents that are double-clicked in the Finder.

I like this proposal a lot (and I dislike dialogs, even when I'm proposing them :-). I particularly like how #1 allows #2 to fix the fantasy protocol exploit while keeping the Mac-like behavior for documents, where it is most useful.

Could upgrading applications be made smoother by allowing the registration of a new version of an application when that application is in the same location as the previous version (after all, if you can overwrite an application, surely you should be allowed to take over its bindings)? That would allow the usual drag-a-new-version-to-the-application-folder-to-upgrade-in-place to work as it does now.

Also, would there be any danger in permitting the full document and protocol registration of applications installed from a package, and/or of applications whose signature is valid according to PGP public keys known to the user? Allowing that would avoid having to require a manual application launch when distributing protocol-handling applications in packages, or when putting up such applications in a shared folder on a corporate or academic network.