[utidjian]

Originally posted by Richard Edgar:
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.

Your point... would require that the attacker not only publish a fake public key on a fake website but also publish all the applications that the real site publishes. All those applications would have to be re-signed with the attackers fake private key. The attacker would also have to 'push' the bogus apps AND key to all the mirror sites (or fake all the mirrors). Even with a single website/repository this would be a very difficult undertaking for the attacker. It would be quickly noticed as soon as someone tries to install a non-bogus package.

Your point... could work quite well for a single app on a single website.

Your point... could also work for SoftwareUpdate getting stuff from Apple, could it not? Yet we trust SoftwareUpdate.

I am not claiming, as some do, that PK schemes are better than seen-in-the-flesh-wet-ink-signatures. Obviously that kind of verification of a signature is not practical over the Internet. Wet ink signatures have the same problem and they get around that with having documents notarized. The analog to that in PK schemes is to use a 'web-of-trust' and/or a public keyserver. You can go to:
http://www.keyserver.net/en/
and look up 'Apple Computer' if you like. You can also look up 'Matthias Saou' and compare the public key there with the one on freshrpms.net.

Your point... Yes, man-in-the-middle attacks are possible but it is also possible to verify the key(s) independently which makes mitm far more difficult for the attacker.

[KrayZ]

Originally posted by utidjian:
Your point... could also work for SoftwareUpdate getting stuff from Apple, could it not? Yet we trust SoftwareUpdate.

I would expect SoftwareUpdate (assuming it uses PKE at all) has Apple's public key on the machine already (as part of the OS install), so a man-in-the-middle attack wouldn't work.

[turtle777]

Originally posted by KrayZ:
I would expect SoftwareUpdate (assuming it uses PKE at all) has Apple's public key on the machine already (as part of the OS install), so a man-in-the-middle attack wouldn't work.

Does anyone know for sure ?
Does Apple use some sort of certificates / digital signatures for SoftwareUpdate ?

-t

[CharlesS]

Originally posted by Charc:
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.

Ah, but notice that I specified that LS would cache an AliasRecord rather than an FSRef. The nice thing about aliases is that they store both the path to the file and a direct reference to it. If another file shows up in the same path, the AliasRecord will figure out that the file's been replaced and adjust itself automatically to point to the new file. So this shouldn't be a concern.

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.

Good point. Perhaps we should append someone's earlier idea of automatically scanning /Applications and its subdirectories and adding them automatically as we do now. Or perhaps Apple could add a command-line tool to register an app with LaunchServices - universities could run this command on each machine they were deploying an app to.

[Developer]

Originally posted by turtle777:
Does anyone know for sure ?
Does Apple use some sort of certificates / digital signatures for SoftwareUpdate ?

Security Update 07-18-02

Security Update 7-18-02 includes a more secure Software Update service, as well as an updated Software Update command line tool, which enables your system to verify that updates have originated from Apple.

[utidjian]

Originally posted by Developer:
Security Update 07-18-02

Cool. I had forgotten about that (two years ago now).

Presumably SoftwareUpdate does this all automatically and transparently. I wonder why Apple only publishes the SHA1 checksums for security and Mac OS X updates. No checksum is published for iTunes ferinstance.

Which brings me to my next question.... (this is not directed at you Developer but to all the naysayers):

If a checksum/authentication scheme is good enough for Apple to use in SoftwareUpdate, why isn't the same scheme (or an alternate one) good enough for other software creators? (This includes commercial and freeware/shareware software creators.)

[CharlesS]

Originally posted by utidjian:
If a checksum/authentication scheme is good enough for Apple to use in SoftwareUpdate, why isn't the same scheme (or an alternate one) good enough for other software creators? (This includes commercial and freeware/shareware software creators.)

Because SU only has to get software from one vendor (Apple), and thus the key can be installed with the OS, so it doesn't need to be downloaded from the Internet and there don't need to be worries about its authenticity.

[Spades]

Originally posted by utidjian:
If a checksum/authentication scheme is good enough for Apple to use in SoftwareUpdate, why isn't the same scheme (or an alternate one) good enough for other software creators?

Checksums are good enough. If you look around you'll find checksums for a lot of programs. They'll usually be MD5 instead of SHA, but that's good enough. Building automatic checksum checking into OS X isn't a bad idea.

Signatures are another matter entirely. They work for Software Update because Apple's key can be installed from physical media with the OS. Good luck getting that key modified without anyone noticing.

[turtle777]

Originally posted by utidjian:

If a checksum/authentication scheme is good enough for Apple to use in SoftwareUpdate, why isn't the same scheme (or an alternate one) good enough for other software creators? (This includes commercial and freeware/shareware software creators.)

So how would that help ?

Telling you that a trojan malware has transmitted without being corrupted by a man-in-the-middle attack ?

The real questions is: do you trust the source.
Obviously, we all trust Apple (more or less...).

But there is not way in the first place to know if you can trust an unknown person / site on the internet.

Again: trust, authenticity, digital signature etc... are NOT the root problem or solution for bad behavior of URI schemes.

-t

[jdb8167]

Originally posted by CharlesS:
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. [...]

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. [...]

3. Internet Config is changed so that it no longer binds protocols to creator codes [...]

This seems overly complex to me. It seems to me you can take an 80-20 approach to this problem and simplify it a lot.

1. Applications that are installed in known locations /Applications, ~/Applications, /System/Library/Core\ Services etc would use the current LS scheme.

2. Applications that are opened from the Finder have the LS do its normal registration.

3. Any other application is inert until it is installed (copied) to a known location or run at least once. Provide an API that can override the need to open the application so that the App can be ready to go if it is installed from an installer program.

Now you don't have 100% of the old functionality but for the majority of users, they won't even notice the change. For techies, write an Applescript that allows LS to do its thing.

The only other thing is to block Safari (or whatever) from using /Applications as a download folder, but I suspect that is already unlikely.

[utidjian]

Originally posted by CharlesS:
Because SU only has to get software from one vendor (Apple), and thus the key can be installed with the OS, so it doesn't need to be downloaded from the Internet and there don't need to be worries about its authenticity.

The key can be installed, but is it? There is NOTHING in the documents I could find on Apples website to suggest that they are using any sor to of 'key' system. The only thing they published is a mere checksum digest. If that is the scheme they are using it is even weaker against mitm attacks than a PK scheme.

You can test this yourself (I just did). If you have access to another system that has the openssl command and you do (as an example):

openssl sha1 MacOSXUpdate10.3.4.dmg

you should get the same thing as I do:

SHA1(MacOSXUpdate10.3.4.dmg)= dd2e1576cfd2792f0c012d552d41556192ce7415

Which is exactly what Apple published on their website and exactly what I get when the command is run on Mac OS X OR Linux. I can assure you that the Linux box I tested it on knows nothing about any keys that were installed with the OS.

Presumably (this is pure speculation), Apples SU command will do something similar and check it against some server that Apple trusts right after the download phase and before the install phase. Yet I wonder how SU knows that it is talking to a genuine trusted Apple server? Does it even check?

Hmmm... curious.

I used the MacOSXUpdate10.3.4.dmg image mentioned above that passed the SHA1 digest test.

I mounted it with:

sudo hdiutil mount MacOSXUpdate10.3.4.dmg

Then I created a 'test' image with:

cd /Volumes
sudo hdiutil create -srcfolder Mac\ OS\ X\ 10.3.4\ Update/ MacOSXUpdate10.3.4_test_.dmg

Then I ran:

sudo openssl sha1 MacOSXUpdate10.3.4_test_.dmg

and got a different checksum:

SHA1(MacOSXUpdate10.3.4_test_.dmg)= 8252ecd917cc9298ffecceaea177a39d07b5c19c

Then I copied that image file to a different Mac and used the Installer to install it. It installed without complaint!

Apparently, regaredless of what SU does to verify that an update is genuine, Installer appears to do nothing to verify that an update is genuine. This IS interesting.

[CharlesS]

Originally posted by jdb8167:
This seems overly complex to me. It seems to me you can take an 80-20 approach to this problem and simplify it a lot.

1. Applications that are installed in known locations /Applications, ~/Applications, /System/Library/Core\ Services etc would use the current LS scheme.

2. Applications that are opened from the Finder have the LS do its normal registration.

3. Any other application is inert until it is installed (copied) to a known location or run at least once. Provide an API that can override the need to open the application so that the App can be ready to go if it is installed from an installer program.

Now you don't have 100% of the old functionality but for the majority of users, they won't even notice the change. For techies, write an Applescript that allows LS to do its thing.

You don't have 100% of the old functionality, because the creator code and bundle ID aren't getting cached, so double-clicking a document that is owned by the app will not work.

[CharlesS]

Originally posted by utidjian:
Apparently, regaredless of what SU does to verify that an update is genuine, Installer appears to do nothing to verify that an update is genuine. This IS interesting.

Why should it? Software Update is the program that knows that the update it's installing comes from Apple, so it's the one that verifies that. As far as Installer is concerned, the file it's working with could be any third-party app.

[utidjian]

Originally posted by Spades:
Checksums are good enough. If you look around you'll find checksums for a lot of programs. They'll usually be MD5 instead of SHA, but that's good enough. Building automatic checksum checking into OS X isn't a bad idea.

I agree.

Signatures are another matter entirely. They work for Software Update because Apple's key can be installed from physical media with the OS.

How do you know that SU uses any sort of key system?

Good luck getting that key modified without anyone noticing.

Exactly! If they do use a key distributed on the media then any sort of bogus software would be noticed immediately. It would hopefully flat-out refuse to install it.

[Big Mac]

Originally posted by CharlesS:
You don't have 100% of the old functionality, because the creator code and bundle ID aren't getting cached, so double-clicking a document that is owned by the app will not work.

Isn't that the type of functionality that we desire? If the application isn't installed in one of the "trusted" folders it shouldn't automatically be associated with any file. Unless and until the user manually launches that new program, it should be disabled. Perhaps I'm missing something.

Originally posted by jdb8167:
Provide an API that can override the need to open the application so that the App can be ready to go if it is installed from an installer program.

I really don't think providing a completely new API is desirable or even warranted in this case. If the application is installed by an installer, one assumes the installer will be installing in one of the trusted folders, so there would be no need to provide a first-launch exception in that case, right? The user will come to understand that if applications aren't placed in the usual locations, a first-launch limitation will be placed on them. Moreover, after the first launch the restriction would no longer apply, so it really wouldn't make much of a difference at all in most every case.

[dan7352]

Originally posted by utidjian:
How do you know that SU uses any sort of key system?

Found on <http://docs.info.apple.com/article.html?artnum=25631>

Security Update 7-12-02 (2002-07-12)

Software Update: Fixes CVE ID CAN-2002-0676 to increase the security of the Software Update process for systems with Software Update client 1.4.5 or earlier. Packages presented via the Software Update mechanism are now cryptographically signed, and the new Software Update client 1.4.6 checks for a valid signature before installing new packages.

[Person Man]

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

Actually, the very first one mentioned in this thread (using Help Viewer to run a script from a URI) was fixed in the recent Security Update.

[dan7352]

Originally posted by KrayZ:
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.

I would hope that Launch Services already has multiple sets of bindings? There needs to be one set for the system and a separate set for each logged in user. Otherwise the junior hacker could mount the DoEvil.dmg from his own account and take over his parents account when they log in.

[Someone might want to test if this is the case]

[jdb8167]

Originally posted by CharlesS:
You don't have 100% of the old functionality, because the creator code and bundle ID aren't getting cached, so double-clicking a document that is owned by the app will not work.

Yup, exactly what I want. An inert application in a suspicious location. Again, this is ok because the majority of users will install the application into /Applications or run an installer. Those are direct user intervention and imply that the user is comfortable with the origin of the software.

Sure, this tosses some useful functionality that makes the OS easier to use in some limited circumstance but the majority of users don't use OS X in that way and won't even notice the change. A small price to pay for reliably eliminating the fantasy URI protocol in my opinion.

[KrayZ]

Originally posted by dan7352:
I would hope that Launch Services already has multiple sets of bindings? There needs to be one set for the system and a separate set for each logged in user. Otherwise the junior hacker could mount the DoEvil.dmg from his own account and take over his parents account when they log in.

[Someone might want to test if this is the case]

Bindings are indeed different for each user. Inspection with MisFox from two different accounts (one with disk: disks: ftp: afp: plugged, the other not) confirms this.

[Richard Edgar]

Your point... would require that the attacker not only publish a fake public key on a fake website but also publish all the applications that the real site publishes. All those applications would have to be re-signed with the attackers fake private key. The attacker would also have to 'push' the bogus apps AND key to all the mirror sites (or fake all the mirrors). Even with a single website/repository this would be a very difficult undertaking for the attacker

Not quite. All it requires is for your ISP to be quietly redirecting all your attempts to communicate with what you think are the various mirror sites. Or keyserver, for that matter.

Your point... Yes, man-in-the-middle attacks are possible but it is also possible to verify the key(s) independently which makes mitm far more difficult for the attacker

My point is that using the 'net is most definitely not independent verification.

[dan7352]

Originally posted by Richard Edgar:
Not quite. All it requires is for your ISP to be quietly redirecting all your attempts to communicate with what you think are the various mirror sites. Or keyserver, for that matter.
My point is that using the 'net is most definitely not independent verification.

There is a theoretical possibility of isolating an individual by filtering their communications. In practice this would require intercepting and replacing every encryption key contained in every form of communications. If one key gets through the individual may be able to create a secure tunnel to a point outside of the filters. Even hints to a key such as fingerprints would need to be filtered to prevent the individual from learning that the key may be compromised. Since there are infinite variations on passing stealth messages the only guaranteed way to stop secure communications is to stop all communications. Most internet users would eventually notice if their online world was entirely fabricated.

It would be easier to spread rumors about the impossibility of having secure communications so the users won't even try to be secure.

-- Dan O.

[Big Mac]

Originally posted by Richard Edgar:
Not quite. All it requires is for your ISP to be quietly redirecting all your attempts to communicate with what you think are the various mirror sites. Or keyserver, for that matter.
My point is that using the 'net is most definitely not independent verification.

"Just because you're paranoid, don't mean they're not after not after you. . ."

[Developer]

Apple's Senior Vice President of Marketing Phil Schiller talked with News.com about the URI security flaw:

"What was learned in February was only a small piece of the picture and didn't present as great a threat," Schiller said. "The complete picture of this current threat has actually been very recent."

Apple has released a partial patch, but security researchers say the OS remains vulnerable to attack.

"We're actually doing a lot of the right things people want," Schiller said. "They're just not aware of it."

"We fixed one part of what is a complex problem. We're working on fixes to the other parts, and there will be more coming," Schiller said. "We were more interested in getting out the first part of the fix as fast as we can...It can help people right now. Now we'll follow up with more things as we finish the rest of this complex problem."

[CharlesS]

^ ^ Excellent news.

Thanks for the link.

[MindFad]

Awesome news.

[turtle777]

Originally posted by Developer:
"We're actually doing a lot of the right things people want," Schiller said. "They're just not aware of it."

I don't like these kind of statements.
Just sounds lame.

If it's true, why doesn't Apple let people know and get credit for it ? Apple, make them aware !

If Apple is trying to justify spending resources without delivering visible or recognized results, then THIS is a bad way of doing it.
Just sounds too lame.

-t

[Millennium]

Originally posted by CharlesS:
Because SU only has to get software from one vendor (Apple), and thus the key can be installed with the OS, so it doesn't need to be downloaded from the Internet and there don't need to be worries about its authenticity.

Theoretically, Apple could sign other companies' public keys with their own public key. You could then check the (unknown) company's public key against Apple's signature; if Apple has signed it, then you at least know that Apple trusts the person signing these updates. You cannot practically hope to share the keys with the vendors through non-Internet means, but Apple certainly can. It does mean a high degree of trust in Apple, though.

This is, however, dangerous in another sense: vendor-specificity. If only Apple can sign the keys, then vendors using this service are at Apple's mercy. This is much the same problem as Microsoft's Authenticode; Microsoft can refuse to sign a key and there is no recourse. Such a system could (and likely will) be abused.

That would make it something I wouldn't use, except for one thing: Apple isn't the one signing the keys. The one signing the keys appears to be Thawte, a public certificate authority. Their public signing key, like Apple's, is distributed with the OS; the same is true for the public signing keys of other root CAs. Thawte has a structure set up to verify the identity of who it gives keys to, so if Thawte signs a key, you can be pretty darn sure it belongs to Macromedia. It's not a perfect system, but it does mean that the CA is not in the software business, which satisfies me.

[Developer]

Originally posted by turtle777:
"We're actually doing a lot of the right things people want," Schiller said. "They're just not aware of it."

I don't like these kind of statements.
Just sounds lame.

I thought he refers to brushed metal Finder here. It's the right thing for us and we want it, we're just not aware of it.

[CharlesS]

Originally posted by Millennium:
Theoretically, Apple could sign other companies' public keys with their own public key. You could then check the (unknown) company's public key against Apple's signature; if Apple has signed it, then you at least know that Apple trusts the person signing these updates. You cannot practically hope to share the keys with the vendors through non-Internet means, but Apple certainly can. It does mean a high degree of trust in Apple, though.

This is, however, dangerous in another sense: vendor-specificity. If only Apple can sign the keys, then vendors using this service are at Apple's mercy. This is much the same problem as Microsoft's Authenticode; Microsoft can refuse to sign a key and there is no recourse. Such a system could (and likely will) be abused.

That would make it something I wouldn't use, except for one thing: Apple isn't the one signing the keys. The one signing the keys appears to be Thawte, a public certificate authority. Their public signing key, like Apple's, is distributed with the OS; the same is true for the public signing keys of other root CAs. Thawte has a structure set up to verify the identity of who it gives keys to, so if Thawte signs a key, you can be pretty darn sure it belongs to Macromedia. It's not a perfect system, but it does mean that the CA is not in the software business, which satisfies me.

Well said. That is, like I said, exactly what is needed to prove that a key is valid for the purposes of preventing malware - to register it with some central authority. The problem with this is that the service is likely to be costly, and many shareware developers (and pretty much all freeware / open source developers) are not going to be able to afford it, which will relegate all of us to second-class citizen status.

[Person Man]

Originally posted by CharlesS:
The problem with this is that the service is likely to be costly, and many shareware developers (and pretty much all freeware / open source developers) are not going to be able to afford it, which will relegate all of us to second-class citizen status.

Maybe, but maybe not, if you consider what it's going to be used for. I see this as a way for commercial software vendors to use Apple's Software Update mechanism to distribute updates to their software to users. Not to authenticate applications at run time. Most of these commercial applications are, by their very nature, quite complex and tend to install files in many different places on the disk.

Many shareware developers (and using you as an example here), on the other hand, write applications that can be installed simply by mounting the disk image and dragging the application over to the Applications folder. They can also trash the application from their hard drive in the same manner, which makes upgrading pretty easy and simple.

I don't see Apple using this in the same manner as Microsoft's ideas about software authentication. I see it as Apple trying to provide a way to prevent some malware author from abusing the Software Update mechanism to offer Adobe Photohop CSI as a "critical update." And yes, I omitted the 's' from Photoshop intentionally. If people are going to use Software Update to update commercial third party applications they are going to expect that Apple has made some attempt to verify them. I also don't think that Apple is marketing this to shareware and freeware developers anyway.

Most people aren't going to expect shareware and freeware authors to take advantage of the Sofware Update mechanism, because those applications tend to be simpler to install anyways. So, while the cost in theory does relegate shareware/freeware developers to second class status, I think that because of the way it will be implemented, in practice, that's most likely not going to be the case. (But I could still be wrong; this is, after all, only my opinion).

[CharlesS]

Originally posted by Person Man:
Maybe, but maybe not, if you consider what it's going to be used for. I see this as a way for commercial software vendors to use Apple's Software Update mechanism to distribute updates to their software to users. Not to authenticate applications at run time. Most of these commercial applications are, by their very nature, quite complex and tend to install files in many different places on the disk.

Ugh. For most commercial applications, such as Microsoft Word, a drag-and-drop install should be fine. There's very little reason to use an installer for most of the apps that use them. Only certain very specific cases will need to do this.

Although I see your point about Software Update - that would be an okay idea since it would be handy for users to get notified when updates to their software is available, and the very nature of shareware means it's easy enough to write your own SU mechanism if you need to - just have it check the site and download the new version if it's there.

[Millennium]

Originally posted by CharlesS:
Well said. That is, like I said, exactly what is needed to prove that a key is valid for the purposes of preventing malware - to register it with some central authority. The problem with this is that the service is likely to be costly, and many shareware developers (and pretty much all freeware / open source developers) are not going to be able to afford it, which will relegate all of us to second-class citizen status.

Their current rate for code-signing keys seems to be about $200/year. Granted, this is not for Apple keys, but the rate is likely to be similar. This is not trivial by any means, but even open-source software should be able to afford this via a donation box.

As for the "second-class citizen" thing, the same is true on Windows, and it does not seem to have affected non-commercial development there.

[Person Man]

Originally posted by CharlesS:
Ugh. For most commercial applications, such as Microsoft Word, a drag-and-drop install should be fine. There's very little reason to use an installer for most of the apps that use them. Only certain very specific cases will need to do this.

Yes. But you brought up the wrong example... Microsoft Office IS a drag-and-drop install, but when you run it for the first time, it installs some of its support files in other folders on the hard drive. But it also comes with a VISE installer so you can do a custom install and choose which components (Word, Excel, Powerpoint, Entourage) you want or don't want.

Although I see your point about Software Update - that would be an okay idea since it would be handy for users to get notified when updates to their software is available, and the very nature of shareware means it's easy enough to write your own SU mechanism if you need to - just have it check the site and download the new version if it's there.

Right. The other thing to keep in mind is that people have different sets of expectations about shareware/freeware vs. commercial applications, for the most part, so they probably won't expect the use of Apple's Software Update.

[CharlesS]

Originally posted by Millennium:
Their current rate for code-signing keys seems to be about $200/year. Granted, this is not for Apple keys, but the rate is likely to be similar. This is not trivial by any means, but even open-source software should be able to afford this via a donation box.

$200/year is almost $17 per month. I have enough monthly charges to deal with already, thanks. Unless you're of the opinion that shareware developers are rich and make a ton of dough, which would only give you away as not being a shareware developer.

As for the "second-class citizen" thing, the same is true on Windows, and it does not seem to have affected non-commercial development there.

Forgive me, I wasn't aware that Windows had a bustling shareware development scene on the same level as what there is on the Mac.

Originally posted by Person Man:
Yes. But you brought up the wrong example... Microsoft Office IS a drag-and-drop install, but when you run it for the first time, it installs some of its support files in other folders on the hard drive. But it also comes with a VISE installer so you can do a custom install and choose which components (Word, Excel, Powerpoint, Entourage) you want or don't want.

I'm well aware of the way Microsoft Office installs. That's why I was singling it out as an example of an app that shouldn't need an installer. Fortunately, it doesn't really install - most of the files it installs just go into ~/Library/Preferences and are basically preference files. The only exception I can find is that dumb Microsoft User Data that it puts in ~/Documents for whatever reason - that should have gone in ~/Library/Application Support and it would be completely standard behavior. AFAICT, it doesn't modify /Library/Frameworks or any other "system" directories.

[Art Vandelay]

Originally posted by CharlesS:
I'm well aware of the way Microsoft Office installs. That's why I was singling it out as an example of an app that shouldn't need an installer. Fortunately, it doesn't really install - most of the files it installs just go into ~/Library/Preferences and are basically preference files. The only exception I can find is that dumb Microsoft User Data that it puts in ~/Documents for whatever reason - that should have gone in ~/Library/Application Support and it would be completely standard behavior. AFAICT, it doesn't modify /Library/Frameworks or any other "system" directories.

If you didn't already know, you can move the MS User Data folder to the Preferences folder so it's no longer in the Documents folder. Office looks for it in both locations.

[CharlesS]

Originally posted by Art Vandelay:
If you didn't already know, you can move the MS User Data folder to the Preferences folder so it's no longer in the Documents folder. Office looks for it in both locations.

Ah, thanks for that. But, the folder really should be in Application Support. Preferences is better than Documents, though...

[absmiths]

Originally posted by CharlesS:
$200/year is almost $17 per month. I have enough monthly charges to deal with already, thanks. Unless you're of the opinion that shareware developers are rich and make a ton of dough, which would only give you away as not being a shareware developer.

...

Forgive me, I wasn't aware that Windows had a bustling shareware development scene on the same level as what there is on the Mac.

First of all, shareware developers do NOT make much money - probably only a small percentage of shareware apps ever get registered (and that only for non-utility apps - generally a utility app is hard pressed to get ANY registrations because it gets downloaded, used, then discarded). My shareware barely supported my website (back in the 'day) which was roughly $15 a month. At $200 a year, I would have had to pay to keep my distribution.

Shareware on Windows is a little enigmatic. I use Windows all the time at work, and the only "shareware" we ever use is WinZip. Oddly enough, for being the most used platform on the planet, there are MANY times when I try to find shareware/freeware for a particular function and can't.

[utidjian]

Originally posted by absmiths:
Shareware on Windows is a little enigmatic. I use Windows all the time at work, and the only "shareware" we ever use is WinZip. Oddly enough, for being the most used platform on the planet, there are MANY times when I try to find shareware/freeware for a particular function and can't.

Try:

http://www.tucows.com
http://www.shareware.com
http://www.downloads.com
http://www.versiontracker.com

to name a few.

There are also many OSS programs that are also available on Windows at:
http://freshmeat.net
http://sourceforge.net

Personally, I don't use Windows enough to need much beyond WinZIP, Putty, and WinSCP. There are some rather good circuit design tools that are shareware/freeware for Windows also. You may note that Putty and WinSCP are available as cryptographically signed packages.

-DU-...etc...

[CharlesS]

Originally posted by absmiths:
First of all, shareware developers do NOT make much money - probably only a small percentage of shareware apps ever get registered (and that only for non-utility apps - generally a utility app is hard pressed to get ANY registrations because it gets downloaded, used, then discarded). My shareware barely supported my website (back in the 'day) which was roughly $15 a month. At $200 a year, I would have had to pay to keep my distribution.

Hey, I'm agreeing with you. I think you misread my post, which stated that anyone who thinks shareware developers make a lot of money is not a shareware developer.

[cfevnmm]

Patch out now in Software Update.

[MartiNZ]

Yep, downloading now. I'm guessing there will be a new thread about it soon though. Not to mention everyone's results with all the dodgy scripts .

[Kenneth]

so after 591 (22862 views)

will this thread come to the end now?

[das]

Security Update 2004-06-07 (Mac OS X 10.3.4 and 10.2.8)

Description - Security Update 2004-06-07 delivers a number of security enhancements and is recommended for all Macintosh users. The purpose of this update is to increase security by alerting you when opening an application for the first time via document mappings or a web address (URL). Please see this article for more details, including a description of the new alert dialog box.

Versions: Security Update 2004-06-07 is available for the following system versions:
- Mac OS X v10.3.4 "Panther"
- Mac OS X Server v10.3.4 "Panther"
- Mac OS X v10.2.8 "Jaguar"
- Mac OS X Server v10.2.8 "Jaguar"

Component: LaunchServices
CVE-ID: CAN-2004-0538
Impact: LaunchServices automatically registers applications, which could be used to cause the system to run unexpected applications.
Discussion: LaunchServices is a system component that discovers and opens applications. This system component has been modified to only open applications that have previously been explicitly run on the system. Attempts to run an application that has not previously been explicitly run will result in a user alert. Further information is available in this article.

Component: DiskImageMounter
CVE-ID: No CVE ID has been reserved as this is only an additional preventative measure.
Impact: The disk:// URI type mounts an anonymous remote file system using the http protocol.
Discussion: The registration of the disk:// URI type is removed from the system as a preventative measure against attempts to automatically mount remote disk image file systems.

Component: Safari
CVE-ID: CAN-2004-0539
Impact: The "Show in Finder" button would open certain downloaded files, in some cases executing downloaded applications.
Discussion: The "Show in Finder" button will now reveal files in a Finder window and will no longer attempt to open them. This modification is only available for Mac OS X v10.3.4 "Panther" and Mac OS X Server v10.3.4 "Panther" systems as the issue does not apply to Mac OS X v10.2.8 "Jaguar" or Mac OS X Server v10.2.8 "Jaguar".

Component: Terminal
CVE-ID: Not applicable
Impact: Attempts to use a telnet:// URI with an alternate port number fail.
Discussion: A modification has been made to allow the specification of an alternate port number in a telnet:// URI. This restores functionality that was removed with the recent fix for CAN-2004-0485.

------------

About Security Update 2004-06-07

Security Update 2004-06-07 increases security when automatically opening an application for the first time.

An application may be automatically opened two ways: either by opening a document that is associated with the application or by clicking a link (URL) in a web page or document.

Opening an application manually or automatically

You can manually open an application, such as by clicking its icon in the Dock; or the application may open automatically, such as when you click a link or open a document that is associated with the application.

For example: You open Safari manually if you double-click its icon in the Applications folder or single-click its icon in the Dock. But Safari will open automatically if you open a document such as "mypage.html", or click an "http://" link that's in a document.

How does Mac OS X know which application to open automatically?

This is done by association (or "mapping"). Mac OS X associates each major type of document (such as text, pictures, movies, and web pages) and each major type of link (such as "http://") with a particular application. When you open a document or click a link, it automatically opens in the associated application. If you encounter a document or link type that is not associated with an application that you have, then Mac OS X will ask you to choose which application to open it with. In the example, web pages (.html) and web links ("http://") are both associated with Safari by default.

Tip: You can change the application associated with a type of document in the Info window. In some cases you can use application preferences, such as the Default Web Browser preference in Safari.

A warning for new applications

When you open an application manually, you are making an explicit choice to do so. But when you open a document, it may not be clear which application will be used. If you click an untrustworthy link, it may try to automatically open a downloaded application designed to cause harm to the system. The feature provided by Security Update 2004-06-07 will alert you if an application that is being automatically opened has not previously been opened, either manually or by consent to this warning dialog:



You can either open the application or cancel the attempt, which is appropriate if you don't recognize or trust the application.

Once an application has been opened, this message will not appear again for that particular application.

Applications included with your computer are considered "trusted" and will not trigger the warning panel.

[CharlesS]

Nice. Downloading now.

It would be better if they showed the entire path, though. You could still call your malware application "Safari" and put it in a disk image named "Applications" and it would look like it was just going to open with Safari in your Applications folder...

[Developer]

You could but it appears they also disabled remote mounting of disk images.

[Hugin777]

Originally posted by Developer:
You could but it appears they also disabled remote mounting of disk images.

FTP is still working (albeit slow). And I guess most will enable automatic opening of "safe" files in Safari again; I know I will.

It seems that the Launch Services database already "knows" the previous exploit scripts/apps, s� I have updated my exploit test page with renamed scripts. It seems to have been fixed, although I'm wondering if this could be misused:

Applications included with your computer are considered "trusted" and will not trigger the warning panel.

[CharlesS]

Originally posted by Hugin777:
It seems that the Launch Services database already "knows" the previous exploit scripts/apps, s� I have updated my exploit test page with renamed scripts. It seems to have been fixed, although I'm wondering if this could be misused:

Yeah, I noticed that too. The first thing I tried after installing the patch was my evil: and tn3270: apps. Neither of them seem to launch under any circumstances, even if I open the app ahead of time. Those protocols are just blocked, apparently.

Changing the protocol from "evil:" to "nifty:" caused the alert box saying "This app is being opened for the first time" to come up.

[CharlesS]

Originally posted by Developer:
You could but it appears they also disabled remote mounting of disk images.

No, remote mounting of disk images works fine. You just have to use the hdid command-line tool instead of a disk:// URL, which is blocked.

Frankly, I'm not sure why they did that as you can just do the same thing with FTP, AFP, WebDAV, etc. anyway.

Anyway, the point is moot if the user has safe files turned on, as someone already pointed out.

[Millennium]

Originally posted by CharlesS:
No, remote mounting of disk images works fine. You just have to use the hdid command-line tool instead of a disk:// URL, which is blocked.

Frankly, I'm not sure why they did that as you can just do the same thing with FTP, AFP, WebDAV, etc. anyway.

Anyway, the point is moot if the user has safe files turned on, as someone already pointed out.

Exactly. The only way to fix this hole is going to be removing that option completely. There is no such thing as a "safe file".

Nevertheless, some of the things in this update have merits of their own, such as asking permission to open apps. I do wish there was an option to make it ask every time, though.