Extra Pepperoni

To content | To menu | To search

Tuesday, May 22 2007

Adobe Lies, Badly

Adobe just posted a workaround for a security bug in their installer: Security bulletin: Workaround available for security vulnerability caused by installing Adobe Version Cue CS3 Server on some Mac systems.

Thanks to Daring Fireball for the heads-up.

In the Details section of the advisory, Adobe says:

To be granted access to these ports, the installer must first turn off the personal firewall. Currently, it is not automatically re-activating the firewall once it sets up Version Cue CS3 Server, creating a potential security vulnerability.

This is a lie. There is no need to turn off the firewall to add rules. I just discovered that Apple's System Preferences appears to flip the firewall off and on to pick up new rules. This makes things simpler, as Apple can just use existing code to a) edit the configuration file, b) turn the firewall off, and c) turn the firewall on, rather than doing "live insertion" of rules. The truth is, though, that there are two different ways to add rules such as Adobe requires. Both are described in Apple's ipfw manual page.

Adobe's Details tells you what they require:

On Mac OS X, customers can turn on a personal firewall to control how Internet services communicate with their systems. During the installation of Adobe Creative Suite 3, the installer sets TCP ports 3703, 3704, 50900, and 50901, in accordance with Apple’s specification, to allow controlled access to Adobe Version Cue CS3 Server through the Mac OS X firewall service.

One way is to simply add rules individually, such as:

ipfw add 8001 allow tcp from any to any dst-port  3703 in
ipfw add 8002 allow tcp from any to any dst-port  3704 in
ipfw add 8003 allow tcp from any to any dst-port 50900 in
ipfw add 8004 allow tcp from any to any dst-port 50901 in

This is tricky, since Adobe doesn't know what rules their users have, and it's important to insert them into the right place in the sequence.

Another way is to update the rules file and then reload it, as described in the manual page:

 To ease configuration, rules can be put into a file which is processed
 using ipfw as shown in the last synopsis line.  An absolute pathname must
 be used.  The file will be read line by line and applied as arguments to
 the ipfw utility.

In Tiger, Apple's dispensed with the BSD-style rules file, and replaced it with an XML document. I don't know how Apple manages the XML configuration, and perhaps they don't provide a hook to update the live ruleset. Apple's tools should be doing this, but don't. At a guess, someone at Adobe decided to follow Apple's (bad) example and stop & start the firewall, rather than updating the XML configuration file (as they already do), figuring out where the new rules would show up, and then live inserting them (see "ipfw add", above).

Stopping the firewall temporarily is opening customers to unnecessary risk. It's bad, but Adobe's in good company here. On the other hand, saying this is necessary is either a lie about security (never a good idea) or gross technical incompetence (not a real improvement).

If they didn't have the unfortunate bug, whereby the installer neglects to restart the firewall after it's disabled it, we might never have noticed.

Monday, February 12 2007

Sensitive Data: Things to Delete

I'm sending my 3-year-old PowerBook off to Apple for repair before AppleCare runs out, and here's my checklist of confidential things to remove (after SuperDuper! finishes backing up) for security reasons. This would also be a good idea whenever a sensitive computer is going beyond personal control for a while. On a machine that travels a lot, most of this data would be on an encrypted filesystem or not present at all, but this PowerBook mostly moves around within our home.


Hopefully this list will help someone else remember what to delete/protect.

  • All personal Keychains (~/Library/Keychains/); if you have multiple accounts, don't forget the others; if your System keychains are sensitive (AirPort password, mostly) don't forget /Library/Keychains
  • All my ssh files, except authorized_keys, in ~/.ssh/
  • Any sensitive email (in my case email is on an iPod, but backed up to the PB)
  • Password wallets (Web Confidential, etc.)

Also, I create an admin user apple, with a one-time password, and set it to enable auto-login (System Preferences:Accounts:Login Options).

When the PB returns, I'll restore the sensitive files and delete the apple account.

What am I forgetting? Leave a comment!

Update: Someone asked about deleting their account and all their files before sending a PowerBook in for service. This is more paranoid than I am, but here's my answer:

First, don't delete the account -- you'll get a different UID when you recreate it after service, and this complicates things. If you are concerned that Apple will somehow snarf your password, change the password temporarily (System Preferences:Accounts); don't forget any other accounts (if you have a root password to protect, "sudo passwd root").

Don't delete any files without having a tested backup first. Disk Utility can handle this nicely -- just make a compressed disk image of your home directory.

To delete your home directory:

  1. Enable root ("sudo passwd root", if you haven't already).
  2. Set System Preferences:Accounts:Login Options to "Display login window as:" "Name and password" (by default, you must pick the name of a non-root account from the login window).
  3. Log out and log back in as root.
  4. Go to /Users, and delete any home directories you want to get rid of (and have already backed up & verified).

When you get the computer back, restore your password(s), delete the apple account, and restore your home directory.

Wednesday, January 17 2007

MoAB: Ambivalence

So the MoAB released a bug announcement with exploit code for Colloquy, an IRC client.

MOAB-16-01-2007: Multiple Colloquy IRC Format String Vulnerabilities Colloquy is vulnerable to a format string vulnerability in the handling of INVITE requests, that can be abused by remote users and requires no interaction at all, leading to a denial of service and potential arbitrary code execution. Further information: Multiple Colloquy IRC Format String Vulnerabilities Exploit: MOAB-16-01-2007.rb

Apparently someone used their exploit:

Thanks to str0ke for donating to the project and mirroring exploits and other code. In other news, we've heard rumors about someone using this exploit to take people down from several Mac-related IRC channels (#macdev, #mac, #macosx, #opendarwin, #colloquy itself...). This is an unfortunate prank, and has no relation with us at all (except the fact of developing the proof of concept and distributing it to some people). They had fun for sure, anyway. Definitely ranting on IRC is a high risk activity.

Do you see anything strange here? They announced several bugs to the world, and provided instructions for exploiting them. People did exploit them, and MoAB now says "no relation to us at all". Well, no. If you made these activities possible, there's a strong relationship.

We're lucky this happened with Colloquy, a relatively obscure product with a more sophisticated audience and very quick developers. Things would have been much worse with a serious attack on Mac OS X or Office.

Monday, January 15 2007

MoAB: AppleTalk Bug! The Sky Is Falling

MOAB-14-01-2007: AppleTalk ATPsndrsp() Heap Buffer Overflow Vulnerability

The Month of Apple Bugs project has just announced an AppleTalk bug! This is much more a 'real' Apple issue than cross-platform VLC issues, but who cares about AppleTalk bugs? What proportion of people/Macs have AppleTalk running on their systems -- 1%? More importantly, ISPs don't carry AppleTalk traffic, so this is really only a concern for Local Area Networks (particularly colleges).

I am impressed they found it, though.

Thursday, January 11 2007

MoAB: Feh!

The Month of Apple Bugs guys wrote a (deliberately limited) piece of spyware which tracked IPs of people who ran their (pre-release) exploit sample. Then they complained because it leaked (not really a surprise here, at least).


People complained they were "installing root-kits", and MoAB responded that the users did it to themselves. Well, duh! That's how most viruses & spyware get distributed and installed, through ignorance combined with malicious intent on the part of the distributor. It doesn't make this any less obnoxious.

Monday, December 25 2006

2 Security Posts on Securosis

I just posted a couple pieces on Rich's site: HTTP Authentication: a Primer & When Community Is Bad: Community and Commerce — Don’t Cross the Streams!.

Thursday, February 23 2006

Safari: Killing Safe Files

There's been a lot of discussion this week about a serious Safari bug. Basically, it can be tricked into running a script automatically if its 'Open "safe" files after downloading' setting is on. Shell scripts are not safe, but Safari can be tricked into thinking they are.


To check your systems if you can't see Safari (over ssh, etc.), use:

defaults read com.apple.Safari AutoOpenSafeDownloads

If you get back 0 or false, you're okay. If you need to turn it off, use:

defaults write com.apple.Safari AutoOpenSafeDownloads 0

page 2 of 2 -