Universal Binary GPG 1.4.6

I’ve made a universal build of GnuPG 1.4.6 (sig). This version is not vulnerable to an attack described in a December security announcement. Copy the contents of this zip into /usr/local/bin to replace the vulnerable binaries.

The source is available from the GnuPG project.
The build was made by making separate directories for Intel, PowerPC and PowerPC 64-bit builds and then using lipo to stitch them all back together again.

The PowerPC 64-bit code may be somewhat slower since certain operations are not optimized in assembly for that platform.

Installing using the MacGPG installer and then copying in the binaries provided above should result in an up-to-date install that is not vulnerable.

MoAB Day 5 Fix Script

The fix for day 5’s bug sadly can’t be affected through runtime patching alone. It requires changing the permissions on disk of a number of files and directories which are vulnerable to being edited by default. I’m providing scripts you can run in Terminal.app to change these permissions to safe values.

• bom-safety.py (sig) changes the permissions to safe values.


• bom-unsafety.py (sig) changes the permissions back to Apple’s original (unsafe) values.

You can run these scripts in Terminal.app as root using sudo:

sudo /usr/bin/python bom-safety.py

It’ll print a message when it is done or if it encounters a problem.

Finlay Dobbie pointed out that certain Apple installers like X11.app or XCode Tools may change these permissions back to vulnerable values again.

In order to re-run the bom-safety script you must rename the backup it creates at /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom.orig.

• Set the sticky bit on /Library/Receipts


• Set the sticky bit on the paths down to each of the critical BOMs


• Unset the group-write bit on the critical BOMs


• Create root-owned 0-length place holders for critical BOMs/paths
  that don’t exist


• Backup /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom


• Make a 1-bit change to the
  /Library/Receipts/BaseSystem.pkg/Contents/Archive.bom file that causes
  repair permissions to keep the sticky bit set on /Library/Receipts
  rather than removing it.


• Print a completed message

As always, you shouldn’t run code when you can’t understand it yourself, trust someone who understands it, or trust the author of the code. For those wondering if I actually wrote the code downloadable above I am providing GPG signatures above for your review. Ironically, the current available GnuPG for Mac has a code execution security hole since early December. I’m building new universal binaries of GPG now and will post them later today.

Month of Apple Bugs

An old friend is posting runtime fixes for the bugs of the Month of Apple Bugs.

Protect yourself. Hopefully Apple will have improved their response time to these sorts of issues, and hopefully the user community will not try to blow smoke at people about real problems.

Update: Some people have asked for my thoughts on response time to these sorts of issues after my own experience interacting with Apple’s product security team.

My experience was over 3 years ago now and presumably Apple has improved from that and similar experiences with others in that time. Three years is an eternity in the software industry, even in large organizations with a lot of inertia. My experience way back then was struggling to get any verifiable confirmation that they were working on the problem.

It was a frustrating experience; trying to overcome any situation of mutual distrust is very difficult. While it is understandable that it takes a while to develop and test changes, that can’t be used as a blanket excuse to keep the people reporting issues in the dark about progress on them.

On the other hand, it sounds like the Month of Apple Bugs folks are giving no advance notice at all to Apple and the open source project VLC. It is impolite of them, even supposing that one or both were notoriously reticent about releasing fixes. I don’t think their actions rise to the level being negligent under current social standards, but then, there’s no law against being a jerk.

Snoqualmie Falls at Flood

Update (January 2009): Just over two years later another flood event, and some more video of the falls and Spring Glen below.

Flood waters pour over Snoqualmie Falls.