Category: apple

The big fruit company from Cupertino.

WWDC 2004

Posted on by david

I’m sitting in the lobby of the Hilton San Francisco as they clean my room (the one I requested with high speed internet access) luckily the lobby is equipped with WiFi.

Sorry for the dearth of posts recently, I’ve been fighting to get a major project put to bed before this trip and although I still have some stuff to do, but I’m hoping I can squeeze it around the conference (like on the bus to the Campus bash 🙂

I ran into some Apple folks on the plane down (Hi Steve, Hi Bruce), which was nice, and we all took the BART SFO Extension in to the city. I was feeling sorry for myself about the 6 hour flight until I spoke to a guy from Apple Belgium (I think) who had just spent 17 frikin hours in the air. Man that’s gotta hurt…

I’m booked into the Cocoa session tomorrow, which should be fun. I’m hoping we can spawn some sort of grassroots WebObjects BOF during the show as well, I made up some “Powered by WebObjects” badges to slip into name tags. Hopefully no one (in Apple legal) will get upset and maybe that can help spawn some conversations.

I’ll post more later, though I won’t be able to say much about the sessions. NDA, y’know.

Exploit 3

Posted on by david

Well, this whole topic has been beaten to death, so I will attempt to minimize my contribution.

Apple’s Security Update 2004-05-24 eliminates the need for my Help Viewer hack (see below). However it doesn’t close all of the URI scheme holes.

For details on that topic I’ll send you over to John Gruber at Daring Fireball.

Right! Now back to our regular scheduled programming..

Exploit 2:

Posted on by david

The Mac net is a buzz with this news: There is a vulnerability in OS X that is potentially dangerous. When given a correctly structured (and possibly malicious) URL, Safari (and other browsers) can respond by asking the Help Viewer application to execute an AppleScript on a volume that is not the startup disk. When coupled with a disk image’s ability to auto mount after download we have a serious opportunity for a security exploit.

This is very reminiscent of the AutoStart worm from 1998 that took advantage of a security hole in QuickTime 2.0 and used to infect Syquest and Zip cartridges.

The first fix I documented just removed the execute privilege from the Help Viewer executable. This fix is a little more elegant and only disables AppleScript in Help Viewer.

Better fix:

  • cd /System/Library/CoreServices/Help Viewer.app/Contents
  • sudo cp Info.plist Info.plist.bck
  • sudo pico -w Info.plist
  • Scroll to the bottom of the document and change the NSAppleScriptEnabled entry from true to false

There is a benign example of the exploit that you can use to test your systems.

via: macfantic in MacCentral’s comments

Exploit:

Posted on by david

Fix:

sudo chmod 444 /System/Library/CoreServices/Help\ Viewer.app/Contents/MacOS/Help\ Viewer

Break again:

sudo chmod 755 /System/Library/CoreServices/Help\ Viewer.app/Contents/MacOS/Help\ Viewer

Untill something better comes along

Bad, bad mailserver! (redux)

Posted on by david

As a follow up to my initial post on the subject, an additional problem that seems to be affecting people with OS X and Cyrus pertains to new log files. Apparently Cyrus roll’s its log file when it exceeds 10MB. For some people the ownership of the new log file is incorrect (root/wheel instead of cyrus/mail) and it causes Cyrus to fail.

This Apple forum thread offers a fix by Matthias Stegner. He suggests creating a bunch of log files in advance:

touch log.0000000002 
... 
touch log.0000000099 
touch log.0000000100 
chown cyrus:mail *

This might buy you some time until Apple has posted a fix