macosxhints - How to securely control another Mac over the internet
A LOT of tips in one place. One of the best I've read in a while. Includes SSH and tunneling configuration.
Monday, May 09, 2005
QuickTime 7 document: revolutionary
QuickTime 7 Update Guide: Changes to QuickTime Player and QuickTime Pro
What a radical concept. Actual QuickTime documentation.
What a radical concept. Actual QuickTime documentation.
Macintouch thread on Tiger OS X widgets security flaw
The disturbing thing here isn't even this particular flaw. It's that Apple's developers clearly aren't thinking seriously about security.
10:50 EDT A question we posed previously about abuse of Tiger desktop "widgets" by malware has suddenly turned into a hot topic:
[Randy B. Singer] There is a grave concern that Tiger's new Dashboard feature, combined with Tiger's auto-installation of widgets, could provide a wide open door for malware. See: http://64.70.134.217/widgets/zaptastic/ but be prepared that just visiting this site installs a fairly innocuous proof-of-concept widget.
[Jim Vonkas] This link [at Slashdot] has a description about a web page that downloads and installs a Dashboard Widget by simply going to the page with Safari. All this happens completely WITHOUT any user interference! This behavior is worse than any danger you can encounter when browsing with the latest Windows XP!
[follow-up] ... It would have been easy enough to disable automatic downloads by default - it's an unforgivable oversight, I think, and if Apple gets a bit stirred up about it, perhaps it will be more careful in the future. ...
[Dave Schroeder] When Safari is in its default state, i.e., with "Open 'safe' files after downloading", what happens is the following:
* The widget is downloaded, unpacked, and moved to ~/Library/Widgets (a website could do this automatically)
* The next time you run Dashboard, the widget is in your shelf (when you press the "+")
* You must deliberately run the widget
Mac OS X likely assumes that if you click it, you intend to run it. The only problem I see here is that a widget could be auto-downloaded (and installed) somewhat surreptitiously, and you might not notice it for a while. There probably should be some sort of prompt in Safari at download time (which it now does for applications).
In the meantime, the sure fix for this any many other past questionable download situations is to always uncheck "Open 'safe' files after downloading" in Safari's preferences. This way, the file is downloaded, but it remains in its packed/compressed form.
[Peter da Silva] Last June [Apple] "fixed" the hole in LaunchServices by popping up an occasional warning dialog, a technique that doesn't address the real problem - the fact that they're using the same set of helper applications for trusted and untrusted references. I put up an article on it, and predicted that there would be more of these problems until they fixed the real problem.
Because popping up a dialog that's almost always answered "yes" is just getting people used to answering "yes", so by the time they need to say "no" they don't realize it until too late. Microsoft has this problem in spades, and I've had to dig viruses and spyware out of people's computers because they got used to saying "yes" one time too often. This dialog is no different.
The latest security update for Panther... what does it do? Why, it patches another example of the same problem. And it's going to happen again and again, though hopefully Apple won't take ten years to realize that they've got a deeper problem, like Microsoft has.
Dashboard. I've been worried about Dashboard. A Dashboard widget is a web page, basically, that can include native code. Native code objects for Internet Explorer - ActiveX - have been the biggest security problem there. For a while it looked like Apple had dodged the bullet... you can't run native code objects in Safari even if you're displaying a widget in Safari. No mechanism to run native code, no potential hole in Safari. I thought.
But, no, they went and decided that widgets are safe for opening and opening installs them in Dashboard. Not only that, but Dashboard doesn't have the equivalent of a popup blocker, so they can write a widget that makes your computer useless if you don't know how to remove it. So now that's TWO potential attacks. First, you can include native code in the widget and see how many punters just click "OK". Second, you can leave the native code out and they don't even get a chance to say "OK".
Bad idea all around.
First, Safari shouldn't consider Widgets "safe".
Second, it shouldn't default to opening "safe" objects anyway. Let people explicitly take an extra step, so they don't automatically get compromised when someone finds a hole in Expander (for one example).
Third, Dashboard shouldn't automatically run any widgets, it should wait until you ask it to do something with it. Oh, and it really needs some better widget management tools.
We'll see what 10.4.1 does, and in the meantime... don't let them get away with this electronic equivalent of overprescribing antibiotics. Tell them, "Don't pop up a dialog unless the user is doing something that has the immediate possibility of launching an exploit, and if you can't tell... don't do whatever it is you were about to do, let the user ask to run the application or install the widget."
[Gregory Lawhorn] Leaving the philosophical issues behind for a moment (i.e., whether Apple SHOULD allow automatic downloads or automatic installation of widgets), here's how to safeguard your system.
High Security: Disable 'Open "safe" files after downloading' in the General tab of Safari preferences. Files might be downloaded, but they will remain archived and on your desktop.
Medium Security: My preference for the moment (I happen to like having a widget automatically installed - when I know about it, that it is). Go to the ~/Library/Widgets folder. Command-click on it, and select Enable Folder Actions. Command-click on it again, and select Attach a Folder Action. Select "Add - new item alert.scpt". Repeat this for Home/Library/Widgets for each and every user account on your computer.
Now when a new widget is added, intentionally or secretly, an informative dialog box will notify you that that the folder contents have changed, and even give you the option of looking at the new item. If you didn't intentionally add the widget, trash it, and you're safe. At least I'm pretty sure you're safe.
[Mike Jackson] There is one really quick way to disable the auto install of widgets. Run the following command in terminal:
chmod 0550 ~/Library/Widgets/
This puts READ ONLY protection on the Widgets folder. Now going back out to http://64.70.134.217/widgets/zaptastic/ will put the auto downloaded widget onto the desktop. You can then use the finder to move it to the ~/Library/Widgets Folder. The finder will ask you to authenticate. Once the new widget is in place, you can double click the widget to run it in Dashboard.
Essential Tiger utility: manage dashboard widgets
MacInTouch Home Page: "Widget Manager 1.0 is a Tiger Preference Pane that makes it possible to inspect, disable, and even remove Dashboard Widgets. It also shows individual widget version numbers. Widget Manager is free (donations requested) for Mac OS X 10.4."
Add 'Find Target' to XP Right Click (Context) Menu
MSFN Forums > Add 'Find Target' to Right Click...
Once upon a time, in the first golden age of the PC, PC Magazine ran a regular "utility" column that featured ingenious solutions to the limitations of what was then DOS. This continued into the first generation of Windows 3.1 and even into Windows 95, then it died out as many of the advertising supported hobbyist magazines went under (of which the greatest loss, by far, was BYTE).
I thought of this when I went looking for a fix to an age-old annoyance -- a quick to go from a windows 'shortcut' (file/folder alias) to the original. (The usual route is RMB, then properties, then 'Find Target ...').
It turns out this is not hard to do. I found sample code in several places, and a registry hack on this page.
However, it's not "packaged" the way things were in the old days. The "hobbyist" energy that used to provide a myriad of such solutions has faded away. I'm sure this has been done a hundred times, but each solution has been lost in a mass of noise.
In the OS X world, the enthusiast energy, and the general coherence of the OS, means these problems get solved and the solution is maintained and available.
Once upon a time, in the first golden age of the PC, PC Magazine ran a regular "utility" column that featured ingenious solutions to the limitations of what was then DOS. This continued into the first generation of Windows 3.1 and even into Windows 95, then it died out as many of the advertising supported hobbyist magazines went under (of which the greatest loss, by far, was BYTE).
I thought of this when I went looking for a fix to an age-old annoyance -- a quick to go from a windows 'shortcut' (file/folder alias) to the original. (The usual route is RMB, then properties, then 'Find Target ...').
It turns out this is not hard to do. I found sample code in several places, and a registry hack on this page.
However, it's not "packaged" the way things were in the old days. The "hobbyist" energy that used to provide a myriad of such solutions has faded away. I'm sure this has been done a hundred times, but each solution has been lost in a mass of noise.
In the OS X world, the enthusiast energy, and the general coherence of the OS, means these problems get solved and the solution is maintained and available.
Subscribe to:
Posts (Atom)