Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Origins of Mac OS X's runscript Security Hole

pudge posted more than 10 years ago | from the hell dept.

OS X 63

ahknight writes "codepoetry has an informative article about why there was a runscript command to begin with, where it came from, and how it's still used. A good read for people wondering why the command existed at all. Also, Daring Fireball has possibly the best solution so far with instructions on how to turn off the help and disk protocols entirely (much better than deleting random system components)." Update: 05/21 22:27 GMT by P :Daring Fireball also mentions an abuse of the telnet: handler that can overwrite any file you have write permissions to, and doesn't need a known path. There's also an applescript: handler, which I'd disable just for the heck of it, at this point ... Update: 05/21 22:36 GMT by P : Several readers note that Apple has just released Security Update 2004-05-24, which address the runscript problem, though apparently not the others.

cancel ×

63 comments

Sorry! There are no comments related to the filter you selected.

no posts? (0, Offtopic)

Anonymous Coward | more than 10 years ago | (#9220894)

Daring Fireball is great.

HA (0, Troll)

huber (723453) | more than 10 years ago | (#9220941)

proof macs are dying!! seriously though im not too worried about this problem. backups cure most ailments.

Re:HA (5, Interesting)

schwap (191462) | more than 10 years ago | (#9221222)

backups cure most ailments.

Image a virus that infects Word documents at a large organization that goes unnoticed for a year because it doesn't actually do anything but replicate itself quietly and subtly, and infects any document it can over the course of the year. Slowly, all the backups of files will be infected as well. It doesn't have to do anything malicious, just prevent a document from being viewed or opened easily.

Every place I have seen Office being used, there are huge volumes of files which everyone can share and update. Boom! Nobody can do anything with the information they have because Office won't work....

errrrm.... wait. I see the flaw in my argument. Office does that all on it's own already.

Re:HA (4, Insightful)

47Ronin (39566) | more than 10 years ago | (#9221353)

Image a virus that infects Word documents at a large organization that goes unnoticed for a year because it doesn't actually do anything but replicate itself quietly and subtly, and infects any document it can over the course of the year.

I know of a small pharmaceutical company whose product database is kept, and updated to frequently, in a MS Word file of all things. No CVS, no MySQL. A Word file!

The potential disaster there is terrifying, to say the least.

Opensource Linux vs. OS X security (0, Troll)

amichalo (132545) | more than 10 years ago | (#9220952)

Does the understanding of the 'Help Script' security hole bring with it a correlation of opensource vs. closed source security issues?

If the Help Script vulnerability was within closed source code, does it imply that OS X, with it's use of Apple closed source on top of FreeBSD, is less secure than other 100% open source OSes? Has a definative security comparison between Linux and OS X been done? (How about one for XP vs. OS X vs. Linux for that matter?)

Re:Opensource Linux vs. OS X security (4, Insightful)

Llywelyn (531070) | more than 10 years ago | (#9221083)

Nice fallacy.

In short, no it doesn't.

Open Source doesn't, by default, mean more secure any more than a published algorithm is more secure than an unpublished article, only that it has the *potential* to be more secure.

There have been security holes from boneheaded design decisions made in various components of Linux before, a single security hole changes nothing nor tells us anything about the relative security of the two systems.

Re:Opensource Linux vs. OS X security (4, Insightful)

0x0d0a (568518) | more than 10 years ago | (#9221281)

Open Source doesn't, by default, mean more secure any more than a published algorithm is more secure than an unpublished article, only that it has the *potential* to be more secure.

While you are technically correct, I believe that you are being misleading. I have the *potential* to be safer running in front of cars than staying on the sidewalk as well -- the issue that most people would be concerned about is what your chances are.

I think that there are few cryptographers that would trust an unpublished algorithm -- many of us do not trust unpublished code.

That doesn't mean that published code is automatically safe -- just that there are more grounds to trust it.

I agree with you that this hole is not an open-source vs closed-source issue (the problem was in design, and enough of the design was available that someone who wanted to identify this could have done so), though I do think that decision decisions like this remind me more of desktop than traditional *IX developers.

Re:Opensource Linux vs. OS X security (0)

Anonymous Coward | more than 10 years ago | (#9235034)

> ... and enough of the design was available that
> someone who wanted to identify this could have done so
> ...

Shouldn't that read, "... and enough of the design was available that someone who wanted to identify this _did_ so ..."

I remember thinking about this back in the days of 8.5. What stopped me from contacting Apple myself back then, and several times since? I had a projects hanging fire where the original schedule had already included the assumption of overtime anyway, bills to pay, family to feed.

The reason I hate Microsoft so much is precisely that they are so busy running around pretending to do what the customer wants before the customer wants it that I have to work so hard to compete that there's no time left to do the right thing.

Security by illusion.

Re:Opensource Linux vs. OS X security (3, Insightful)

Anonymous Coward | more than 10 years ago | (#9221108)

Why must every security hole in a non-OSS program turn into a OSS vs. non-OSS debate?

The fact of the matter is that security holes can happen anywhere. It doesn't matter if the code in question is OSS or non-OSS. All that matters is that the problem gets fixed.

And don't even start the "if it was OSS, we would have caught it earlier" argument. There have been plenty of holes in OSS that were not noticed for a long time.

Re:Opensource Linux vs. OS X security (2, Funny)

Gilmoure (18428) | more than 10 years ago | (#9222647)

This one was first noticed back in February and duly reported to Apple. Three-four months isn't bad response time, to craft a script that would go in, turn off a couple of options in URL handling, right?

Re:Opensource Linux vs. OS X security (1)

scrotch (605605) | more than 10 years ago | (#9221114)


I think that if "a definative security comparison" were possible, OS distributors would run them and then fix all the holes found. There's no way at this point to perform such thorough testing on systems so complex. Meaning no way to list all the things to test for, and no way to test them all before the technology is obsolete.

If you disagree, you have found a very good career. (If only disagreeing with /. posts was always so fruitful.)

software update (2, Informative)

Pathwalker (103) | more than 10 years ago | (#9221005)

Or, you could just run softwareupdate, and install patch SecUpd2004-05-24Pan-1.0 which, despite it's name, is out today and is described as:
Security Update 2004-05-24 delivers a number of security enhancements and is recommended for all Macintosh users. This update includes the following components:

HelpViewer

Re:software update (4, Informative)

mst76 (629405) | more than 10 years ago | (#9221771)

As already noted in the writeup and elsewhere in this thread, the Apple fix isn't enough. The other issues, discovered on the MacNN forum [macnn.com] , are summarized here [unsanity.com] .

Re:software update (2, Informative)

monkeyneck (648963) | more than 10 years ago | (#9222954)

Other issues... I ran the Security Update, and then tried Unsanity's example. it didn't work. So, it looks like that particular vulnerability is fixed by the Security Update. The problem can be fixed with RCDefault [rubicode.com] quite easily, as well. Also, note that this vulnerability does not work from within the Opera 7.5 browser.

Re:software update (1)

carou (88501) | more than 10 years ago | (#9223774)

Other issues... I ran the Security Update, and then tried Unsanity's example. it didn't work.

I also ran the Security Update from Apple, and then tried Unscanity's example. For me, it DID work. I've got a text file in my home directory to prove it...

Are you sure the disk image downloaded quickly enough for the refresh to execute it?

Re:software update (1)

monkeyneck (648963) | more than 10 years ago | (#9228482)

Yes, I'm sure. I waited, and I tried it a couple of times. For the record, I have RCDefault installed, and I did set everything back to the default settings before trying Unsanity's example.

Re:software update (1)

mst76 (629405) | more than 10 years ago | (#9224038)

> Other issues... I ran the Security Update, and then tried Unsanity's example. it didn't work. So, it looks like that particular vulnerability is fixed by the Security Update.

The issue is fixed by disabling Open Safe Files and the disk:// protocol, not by Apple's SU. There are rumors that other volume-mounting protocols are also succeptible to the attack (ftp://, afp://, smb://, webdav://, others?)

Re:software update (1)

monkeyneck (648963) | more than 10 years ago | (#9228494)

I hear what you're saying, and I have done this using RCDefault, which I used to set the disk protocols and others back to their default settings before doing the test. I've read the rumors, and have set my protocols accordingly. As I had set the protocols back to the defaults, anecdotal evidence in this case would seem to indicate that the Security Update fixed the problem. Either way, the idea that Paranoid Android is the ONLY fix is bogus.

Parnoid Android (4, Informative)

Red_Winestain (243346) | more than 10 years ago | (#9221009)

Paranoid Android [unsanity.com] protects against all of these potential exploits, including telnet://-nfoo.

Re:Parnoid Android (2, Informative)

bw5353 (775333) | more than 10 years ago | (#9223549)

They also have a demo page, which unfortunately proves that Apple's latest security update (of 24 May, which is the day after tomorrow - sounds like a Bond film) is not enough (another Bond film).

I tried their demo page after Apple's update and sure enough, a nasty text file was written to my home directory.

Paranoid Android not good for my mom (5, Informative)

karnat10 (607738) | more than 10 years ago | (#9224195)


Paranoid Android does not "protect" against anything, it just lets the user decide which URL schemes he wants to allow and which he doesn't, on a case by case basis. But not everyone is an IT professional and knows by heart which protocols are good and which are evil. My mom doesn't. So, is there a workaround that doesn't involve P.A.? I think so.

I can see three different (but related) issues here:
  1. The "new and unknown URL scheme" issue exploited by malicious applications in downloaded and mounted disk images. Avoid this by not allowing disk images to be mounted automatically. You have to disable "Open Safe Files" (to avoid mounting disk images downloaded over http) and the disk: and disks: protocols. Having to mount all disk images by hand requires a decision from your side and gives you time to think about what you are doing.
  2. The "help://runscript" issue caused by the Help Viewer accepting arbitrary commands. Disable the help: protocol, who needs it anyway?
  3. The "telnet://-nfoo" issue caused by telnet's ability to overwrite existing files. Disable telnet:, ssh exists.
Correct me if I'm wrong, but with those protocols disabled I can see no way for the malware to get its stinky little bits on my harddrive.

To disable the protocols I used RCDefaultApp [rubicode.com] which is a neat (and missing) preference pane anyway.

With the steps above taken and P.A. installed I opened the sample exploit [geekspiff.com] by the P.A. author (also linked from his white paper [unsanity.com] if you're paranoid which would seem normal under this circumstances). P.A. nicely asked me for permission, first for disk: and then for malware:. I granted both permissions, but since I had disabled the disk: protocol the image was never mounted and nothing happened.

Now, installing an additional prefPane and disabling individual protocols is not exactly an easy one-click workaround for my mom, but it would be possible to guide her through the process on the phone, and after that she would leave me alone ... until the next flaw is found.

But then again, I still have some hope in Apple releasing a Security Update which is more convincing than the one they just released. With flaws that serious, I expect a bit more than just the replacement of one application which is obviously only part of the problem.

Apple posted Security update for this (0, Redundant)

Rouxfus (567556) | more than 10 years ago | (#9221024)

Security Update 2004-05-24 delivers a number of security enhancements and is recommended for all Macintosh users. This update includes the following components: HelpViewer 712K through Software Update. No Reboot. Problem: if you run Software Update again, it will let you run the Security Update again and again - it never figures out that it has already been installed!

Re:Apple posted Security update for this (-1, Troll)

Anonymous Coward | more than 10 years ago | (#9221106)

Apple sucks. You must really like that logo to pay so much for it.

Re:Apple posted Security update for this (1)

phatsharpie (674132) | more than 10 years ago | (#9221303)

Strangely enough, I did not encounter this problem. Software Update seems to have recognized that I have the security update installed, and have not asked me to download it again.

-B

Re:Apple posted Security update for this (1)

Graff (532189) | more than 10 years ago | (#9221431)

Strangely enough, I did not encounter this problem.

Yep. no such problems here. The install went smoothly and it now says I'm up to date.

Re:Apple posted Security update for this (1)

SillyWilly (692755) | more than 10 years ago | (#9221944)

I get this problem with random updates from time to time. I don't know of any immediate solution, they just seem to go away after a while.

NOW? (1)

Dahan (130247) | more than 10 years ago | (#9221174)

Heh, check out the codepoetry [codepoetry.net] article in a browser that supports the <acronym> tag (such as Mozilla); all off the "NOW"s, such as in "NOW Help Viewer was almost 100% feature-equivalent to Apple Guide" and "NOW that the system had a real web display system..." have a tooltip that says, "National Organization for Women (Man-Haters)" :)

Re:NOW? (-1)

Anonymous Coward | more than 10 years ago | (#9221570)

stupidest post ever

URL handling still has "remote code" exploits! (4, Informative)

mithras the prophet (579978) | more than 10 years ago | (#9221305)

As discussed in this thread [macnn.com] , the URL handling in OS X, plus the automatic app-registration, plus the auto-mounting of disk images makes for an easy execute-remote-code flaw in OS X. I quote the poster, smeger:
In other words, lets' say I write a standard Mac app that deletes the home directory. The Info.plist for this app contains
(snipped for lameness filter)
<key>CFBundleURLSchemes</key>
<array>
<string>malware</string>
</array>

The malware author sticks this app into a DMG and uses the trick mentioned elsewhere in this thread to mount the DMG and then redirect the web page to "malware://anything". Boom - bye bye home directory.

Am I missing something here, or did this vulnerability just get even nastier?

yikes! Make sure you turn off "open safe files" in Safari (or the equivalent in your browser), and also disable the disk:// protocol, until this is resolved!

Re:URL handling still has "remote code" exploits! (3, Interesting)

mst76 (629405) | more than 10 years ago | (#9221649)

The MacNN thread is a great read, you can witness the discovery of this vulnerability almost live. The new exploit means the malware author can make up his own protols like malware:// and give his app the appropriate creator code. Is other words, fixing the Help app is not enough, the problem is the automounting of .dmg and the URL handlers. Apple has been notified, so expect another fix soon.

Re: URL handling still has "remote code" exploits! (1)

edmundv (457386) | more than 10 years ago | (#9224232)

Turning off 'Open safe files' in Safari is NOT enough!

Disks can be automatically mounted through the 'disk://' URI handler. You should download RCDefaultApp and disable the handlers for 'disk', as well as 'ftp' and 'afp'. Oh, and 'telnet' as well, since that one is not safe too.

At least until Apple comes up with a proper security patch.

Jaguar Update (1)

grocer (718489) | more than 10 years ago | (#9221471)

The 10.2.8 update lists Help Viewer and Terminal updates...in the usual Apple verbose style.

Some notes (4, Informative)

daveschroeder (516195) | more than 10 years ago | (#9221875)

Some notes about the now-fixed exploit:

Some reports describe this as also a vulnerability with the 'disk' URI handler. This is incorrect. There is no vulnerability in the 'disk' URI handler; however, it could be used in conjunction with the 'help' vulnerability to deliver malicious content. On its own, 'disk://' does nothing more than enable the remote mounting of disk images. It was this capability combined with the 'help' vulnerability's ability to run arbitrary code at a known location that made it dangerous.

Also, reports have also described this as a vulnerability in Safari, Internet Explorer, or other browsers. This is also incorrect. It was a vulnerability in the way Help Viewer handles 'help' URI requests passed to it by the OS.

Last, there seems to be a misunderstanding that this vulnerability requires the OpnApp.scpt helper script within Help Viewer somehow. It does not. However, OpnApp.scpt, combined with the help URI handler vulnerability, could be used to execute some arbitrary commands. But "exploiting" it actually just comes back to general help URI handler vulnerability, now fixed.

That said, this was a very serious exploit...probably the first major (potentially) easily exploitable vulnerability for Mac OS X.

Incidentally, the people who removed Help Viewer altogether, or did things like chmod 000 (without setting it back) will be screwed and unable to properly install this update. Hopefully there's not too many of those people...

Last, the telnet:// "vulnerability" isn't really a dangerous one, since it can only overwrite files (not directories) with a known name and path that you have permission to, and only one file at that. Yes, yes, plenty of preferences and maybe even some really irritating things like your iTunes Music Library database file. In any event, this definitely should also be fixed.

Re:Some notes (4, Informative)

mst76 (629405) | more than 10 years ago | (#9221925)

> Some notes about the now-fixed exploit:

It's not clear from your writing if you realize that there is another similar exploit that has not been fixed yet. Malware writers can invent their own URL protocols and LaunchServices will automatically register them on mounted volumes (e.g. through disk://, and maybe also ftp:// and afp://). In other words, the same kind of exploit is possible without HelpViewer, for details, see this link [unsanity.com] .

Re:Some notes (1)

aristotle-dude (626586) | more than 10 years ago | (#9223102)

Umm... are you sure that all it needs is to exist on a mounted volume? Don't you have to execute the app in order to register the URL type with Launch Services?

Is having the URL type in an info.plist enough?

You can disable the disk: and disks: url handlers with the Default Apps prefs pane. I don't want to post a link to slashdot though. Use Google.

I don't want Apple to disable the ability for apps to create their own protocols just because some malware some stupid user downloads might make use of it.

There will always be some way for malware to get on a stupid user's machine.

Re:Some notes (0)

Anonymous Coward | more than 10 years ago | (#9223913)

> Umm... are you sure that all it needs is to exist on a mounted volume? Don't you have to execute the app in order to register the URL type with Launch Services?

> Is having the URL type in an info.plist enough?

Yes, according to the testers on MacNN. LaunchServices is just a bit too smart for its own good.

Re:Some notes (0)

Anonymous Coward | more than 10 years ago | (#9223970)

> Umm... are you sure that all it needs is to exist on a mounted volume?

Yes, just try the sample exploit on the linked page.

Re:Some notes (1)

Anonymous Coward | more than 10 years ago | (#9224043)

The root issue is actually Apple's best usabilty feature -- the OS knows where programs are and what they can hadnle without an install routine or hardcoded paths.

Re:Some notes (1)

Anonymous Coward | more than 10 years ago | (#9224124)

> The root issue is actually Apple's best usabilty feature -- the OS knows where programs are and what they can hadnle without an install routine or hardcoded paths.

In other words, a classic Convenience versus Security issue.

Re:Some notes (1)

aristotle-dude (626586) | more than 10 years ago | (#9225667)

I would rather put up up with the chance of having an exploit use this rather than putting up with complicated install routines and a central registry.

There is no way to exploit this if you disable auto-mounting of disk images on download and the disk:/disks: protocols by with the default apps prefs pane.

If Apple does release a patch to deal with this, I hope it only performs a check to see if the disk/disks protocols are called from the internet and provides a warning/confirmation dialog as the user if he/she wishes to mount the dmg.

Safari should also have open downloaded files on download switch off by default.

Re:Some notes (1)

klui (457783) | more than 10 years ago | (#9223811)

Although I changed the permissions back to 755 via sudo before I applied the update, it really shouldn't matter because the updater is run as root. Root can read files/directories with permissions 000. Tested the problem after update and it fixes it. Those who rm'ed Help Viewer.app, however...

Re:Some notes (1, Insightful)

Anonymous Coward | more than 10 years ago | (#9223943)

> On its own, 'disk://' does nothing more than enable the remote mounting of disk images.

The problem is that it does this without user notification and there is not easy way (without third party apps) to disable this.

Re:Some notes (1)

maxentius (603949) | more than 10 years ago | (#9225622)

  • Incidentally, the people who removed Help Viewer altogether, or did things like chmod 000 (without setting it back) will be screwed and unable to properly install this update. Hopefully there's not too many of those people...

If you did the chmod fix, the download from software update will install -- but SU won't recognize that it has done so. That's what happened to me. Disk Utility's "Repair Permissions" fixed the changed permissions, and then all was back to normal.

Apple Download Page (2, Informative)

SillyWilly (692755) | more than 10 years ago | (#9221986)

This update is available from the Apple website here [apple.com] for 10.3.3 and here [apple.com] for 10.2.8.

The safety of many URI protocols may be in doubt (3, Informative)

babbage (61057) | more than 10 years ago | (#9222424)

I posted this late to the earlier discussion about this hole, but chances are not many people saw it. Looks like I'm not the only one thinking this now though, so why not post it twice...

It occurs to me that the help:// URI protocol problem could be broader than is generally being portrayed so far.

Consider: the fundamental issue here is that an OSX web browser -- Safari in the original reports, but apparently also Mozilla etc -- is acting as a broker for any URI that the user may come across, delegating the request out to external handler programs. Whether those external programs handle their URIs safely may be an open question.

The problem isn't really that Safari or Help is broken, but that the interaction between them, arising from the URI handling mechanism on OSX, is leading to Unintended Consequences.

OSX can handle many different URI namespaces, some of which seem to be used nowhere other than OSX. I'm having a hard time finding an exhaustive list of the URI protocols that OSX supports, but a partial list [macosxhints.com] includes, in no particular order:

http://
https://
ftp://
mailto://
ssh://
telnet://
aim://
afp://
nfs://
smb://
sherlock://
itms://
daap://
help://

So far, I can think of published vulnerabilities in the telnet:// and now help:// protocols [and this article expands on those points], but is that the end of it, or is the whole framework vulnerable to these sorts of attacks?

I have a hunch that we're just seeing the thin edge of the wedge. If that's the case, then a real fix is going to hit a lot of the system, which in turn will mean that Apple is going to have a hell of a time doing proper bug testing on whatever fix they come up with. And if that is the case, then the patches we see for this through Software Update seem likely to be partial, possibly unreliable or ineffective, and may lead to system instability. (I'd hope that isn't the case, but if the fix has to be at some fundamental level of the UI then it can't be ruled out.)

It may be that we don't see a true correction to this situation until at least the next 10.3 point release, if not 10.4...

telnet bug was fixed as well (5, Informative)

Anonymous Coward | more than 10 years ago | (#9222640)

From Apple's own Security Announce mailing list [apple.com] :

*snip*
APPLE-SA-2004-05-21 Security Update 2004-05-24


Security Update 2004-05-24 is now available and contains security enhancements for the following:

HelpViewer: Fixes CAN-2004-0486 to ensure that HelpViewer will only process scripts that it initiated. Credit to lixlpixel for reporting this issue. This issue has been widely reported as a problem with the Safari web browser, but can affect other web browsers. This update will fix the issue for Safari and other web browsers.

Terminal: Fixes CAN-2004-0485 to improve URL processing within Terminal. Credit to Reni Puls for reporting this issue.
*snip*


There was no disk:// hole (though it was used in conjunction with help://) and telnet:// is fixed as well... nothing else to see here... move along...

Still not fixed. (0)

Anonymous Coward | more than 10 years ago | (#9223944)

There was no disk:// hole (though it was used in conjunction with help://) and telnet:// is fixed as well... nothing else to see here... move along...


Except the 2 OSX machines I've applied the security update on are still vulnerable to the telnet:// bug

Still not fixed.

telnet://-nlibrary%2fsafari%2fbookmarks.plist deletes my safari bookmarks.

Re:telnet bug was fixed as well (0)

Anonymous Coward | more than 10 years ago | (#9224007)

> There was no disk:// hole (though it was used in conjunction with help://) and telnet:// is fixed as well... nothing else to see here... move along...

There is, see the other posts in the thread. The demo on the Paranoid Android page still works after the Apple Security Update (and is using disk:// again). The disk:// protocol is not so much a hole as a dangerous default setting that cannot easily be undone without third party software. I haven't seen this confirmed yet, but ftp://, aft://, smb://, webdav:// (basically anything that automounts volumes) may suffer the same problem.

Apple Patch 2004-05-24 ? (1)

HaloZero (610207) | more than 10 years ago | (#9222896)

Today is the 21st. Does this mean that a company is actually thinking ahead in the security process?

KDE (2, Interesting)

ensignyu (417022) | more than 10 years ago | (#9223061)

There's an advisory [kde.org] listed on dot.kde.org that seems similar, although not as bad.

As much as love to mock OS X (4, Informative)

RzUpAnmsCwrds (262647) | more than 10 years ago | (#9223173)

As much as I love to mock OS X, a similar exploit existed in Windows before SP1.

Like OS X, Windows allows applications to create their own protocols. You can make an "irc://" protocol (and many applications do) or an "outlook:" protocol (as Outlook does) or many other protocols.

The risk with OS X (and Windows) is that one of these protocols is registered to an application with a security flaw.

Windows has had this technology since 1995; I don't know how long the functionality has been in Mac OS but from the looks of things it seems to be relatively new (perhaps it was introduced with OS X?). Apple has to get the bugs shaken out of the built-in applications. 3rd party applications also present a danger, but it is less (it is more difficult for an attack to work when it relies on a specific non-standard application).

Internet Explorer (on the PC) has one of the most unique security models of any browser. IE has multiple security "zones"; it is possible to set the security settings for files on your intranet to be different from the security settings on the general internet (similar to having different users for different pages). Unfortunately, this also carries a risk: flaws in IE have lead to "cross zone" scripting which allows privelage elevation. IE SP2 a completely new zone system which is supposed to prevent this, but only time will tell if it is truly effective.

Re:As much as love to mock OS X (0)

Anonymous Coward | more than 10 years ago | (#9224052)

> The risk with OS X (and Windows) is that one of these protocols is registered to an application with a security flaw.

It's more serious than that: through info.plist you can associate any program with your own protocol and LaunchServices will automatically register these on any mounted volume (e.g. through disk://). So you don't need to rely on HelpViewer or other already installed apps.

Re:As much as love to mock OS X (1)

Gropo (445879) | more than 10 years ago | (#9224520)

I don't know how long the functionality has been in Mac OS but from the looks of things it seems to be relatively new (perhaps it was introduced with OS X?).
I recall using "hotline://" as early as MacOS 8.5 on my local http portal.

Re:As much as love to mock OS X (2, Funny)

fastgood (714723) | more than 10 years ago | (#9224602)


Apple Computer on Friday issued an update to Mac OS X to address flaws
that security firms said could allow malicious code to be run on a Macintosh.

From the sounds of this NEWS.COM release, it sounded as if Apple blocked the ability to execute future Windows emulators...

The help bug (-1)

Anonymous Coward | more than 10 years ago | (#9223344)

Couldn't run any command with non-alphanumerics in it.

What does this mean? Well, the "hack" could only do the following horrible commands on your system sure to cause death:

ls
mpg123
um...

ok thats about it.

Modest security threat (3, Informative)

saha (615847) | more than 10 years ago | (#9223666)

I feel this is a modest security threat because,
http://bronosky.com/pub/AppleScript.htm [bronosky.com] Only runs "du" command.

1) To have the maximum potential you need to be running as admin user, not standard user. I encourage everyone to be standard user when they run their computer. I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix trick to prevent one from deleting their whole directory by accident. Another method is to have "alias rm rm -i" in your .cshrc or .tchrc environment configuration.

2) A malicious website would have to be catered specifically for Mac users and have them navigate to this website by clicking on the link. Most serious threats on the Windows side comes from you having your computer simply being plugged into the network. i.e. worms. I would classify this more under the realm of a Trojan Horse, which requires some trust on the users part.

3) One can kill the unix terminal with in seconds of it launching. The script doesn't and can't surreptitiously launch in the background. You can actually see the script and terminal run in front of you.

Re:Modest security threat (2, Informative)

smcv (529383) | more than 10 years ago | (#9224056)

You assume that because the demo page can't do commands containing spaces, you're immune to commands containing spaces. Unfortunately, if an attacker can get a program of their choice placed at a location of their choice using an auto-mounted DMG file, they could write and compile, say, a shell script, or a C program which does the equivalent of "rm -rf /".

That aside, further nitpicking:

I also have a "-i" file in my home directory which forces a "rm" command to ask before deleting. This is an old unix trick to prevent one from deleting their whole directory by accident.

If the attacker can't use command-line args, you're probably OK there:

smcv@linuxbox:~/foo$ rm

rm: too few arguments
Try `rm --help' for more information.


If the attacker does "rm *" in your $HOME, yes, a file called "-i" could save you. None of these would be stopped, though: rm -rf /, rm -rf $HOME, rm $HOME/*, rm ./*, or even (if MacOS X's rm implementation has GNUish command-line options) rm -- *.

Another method is to have "alias rm rm -i" in your .cshrc or .tchrc environment configuration.

Everything *you* run in an interactive csh or tcsh has that run first. If a malicious program is run through /bin/sh or just exec'ed directly (both are much more common ways to launch a program), csh isn't consulted. (The various variants of csh are designed as interactive shells; whatever you use for interactive use, /bin/sh is the standard noninteractive shell for scripting, and often also the interactive shell (e.g. on Linux, the interactive shell is usually /bin/bash, and /bin/sh is usually also bash).)

Re:Modest security threat (0)

Anonymous Coward | more than 10 years ago | (#9224772)

1) You seem to think that the worst thing someone can do to you is "rm -rf". What's the point of setting up a website that deletes data from random users? The real evils are people who try to install backdoors or keyloggers, send mass email from your account, steal personal information, etc. Basically they can do everything YOU can do when you're not root, and that is still a lot.

2) WTF? Every MSIE exploit works this way. Arguing that the threat is modest because it is not a worm or a remote root exploit is just dumb.

3) Only the linked example used du. There are other examples that launch things in the background without terminal.

Switch (2, Funny)

Neillparatzo (530968) | more than 10 years ago | (#9223952)

See, you guys should just buy a Mac. We don't have this sort of problem.

Re:Switch (1)

AcornWeb (770294) | more than 10 years ago | (#9225023)

Oh wait ... :-)

Security Update 2004-05-24? (1)

painfall (169576) | more than 10 years ago | (#9225446)

It seems Apple's programmers have access to a time machine.

I'd also like to point out... (4, Informative)

mattkime (8466) | more than 10 years ago | (#9225612)

that Little Snitch helps to prevent some of these exploits as well...

http://www.obdev.at/products/littlesnitch/

when i tried to run the example hack on the Paranoid Android site, Little Snitch warned me that I was trying to mount a remote disk image which i was able to cancel.

apple patch servers DOS? (1)

billo (166194) | more than 10 years ago | (#9236763)

I don't know about anybody else, but none of my Macs can get to apple's patch servers today to get the HelpViewer patch. I had no trouble getting it yesterday on one of them, but today I get a timeout from three different T1s.

Also, their main web site is pretty slow/hurtin. :-(
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?