Fred is Gone

Our trusted companion of the last couple years is gone. Fred came to us from Pasado's Safe Haven, rescued from death row at a local shelter. After we heard from vets that he only had months left, he proceeded to live two years of enthusiastic tromps in the snow, trips to the beach and hikes in the woods or just around the neighborhood. Slowly though, the degenerative myelopathy which afflicted him claimed his ability to control the back half of his body. Despite this, he soldiered on determined to follow his pack leaders and have fun doing it, until recently when he turned melancholy because he simply couldn't manage any more.

In his last hours we went, sat and relaxed along a sandy rivershore, watched the waves and the trees move and felt the breeze. He was treated to a special meal out and then we let him go. It is sad to lose him, but hopefully the two years we were able to provide him were as enjoyable for him as they were for us.

Security Advisory: Norton AntiVirus for Macintosh

Synopsis

Symantec's Norton AntiVirus for Macintosh (NAV) contains a vulnerability that can lead to local privilege escalation from group admin to root (the super-user) without any of the usual password prompts Mac OS X presents for gaining super-user access. Group admin includes any users with the "Allow this user to administer this computer" box checked, this generally includes the first user created in an OS X install. This vulnerability is caused by a setuid-root binary in NAV which automatically runs another binary in a location where it can be replaced by users with group admin permissions. Since most Mac OS X users are in group admin on their computers, most NAV users will be vulnerable.

Mitigation

The easiest (and most foolproof) mitigation strategy is to uninstall NAV. (I sure don't feel very secure when a vendor allows a local privilege escalation vulnerability to fester in their security software for over 9 months. Your feelings may vary.)

Set the sticky bit on all directories between the vulnerable binary and the filesystem root that are writable by group admin. This can be done in Terminal.app with sudo chmod +t / /Library /Library/Application\ Support /Library/Application\ Support/Symantec /Library/Application\ Support/Symantec/SmallScanner.app etc. Keep in mind that running "Repair Permissions" on your disk will remove this change and leave your NAV install vulnerable once again. Apple has set the sticky bit on / and /Library by default on Mac OS X 10.5, but not /Library/Application Support and obviously not on the directories that NAV is installed into.

What Symantec Had to Say

The last time I heard from Symantec was August 29th:

As you know, Symantec developers reviewed the issue concerning NAV for the Mac that you sent to us, and agreed that there is cause for concern. However, they felt that the same problem could potentially affect other vendor’s[sic] software as well. We contacted Apple Product Security, and suggested some changes that could improve security for everyone.
...
Symantec does not currently plan to make changes to our existing products to directly address the problem you reported. The changes would require considerable architectural modifications for those products, and the changes could cause other problems for those products if Apple subsequently release an OS update to address the underlying problem.
...

Timeline

Just in case people think the vendor didn't have enough time to address this, here's the timeline:

• 2007-Jan-16 - Reported issue to Symantec


• 2007-Jan-17 - Symantec will "review as soon as possible"


• 2007-Jan-31 - Symantec "working on planning a fix", will coordinate release when product update has ETA


• 2007-Apr-20 - Symantec thinks it would be better if Apple made changes to Mac OS X to fix the problem in NAV


• 2007-Jun-21 - Contacted Apple for status


• 2007-Jun-22 - Apple communicates the changes they're going to make for Leopard. These changes are not enough to workaround Symantec's vulnerable software.


• 2007-Aug-29 - Symantec says they've made suggestions to Apple, but otherwise aren't going to do anything to fix this issue (see the quote in the previous section)


• 2007-Oct-01 - It turns out that Apple's Leopard builds at the time didn't do enough to cover up the vulnerability in NAV


• 2007-Oct-11 - Contacted Symantec and Apple to let them know I was going to post this Nov-1


• 2007-Nov-1 - Today.

Details

SmallScanner is run as root by the setuid-root binary
/Library/Application Support/Symantec/AntiVirus/DiskMountNotify.app/Contents/MacOS/DiskMountN
otify. E.g. after inserting a data cdrom:
root 8734 28.9 -2.1 616152 43596 ?? U 7:51PM 0:16.13
/Library/Application Support/Symantec/AntiVirus/SmallScanner.app/Contents/MacOS/SmallScanner

Unfortunately /Library/Application Support/ is writable by group admin and by
mv'ing the Symantec subdirectory out of the way and installing a tree of
symlinks in its place except for malware in place of SmallScanner arbitrary
code can be executed as root. That is you can trampoline from group admin to
user root. (There were a variety of other ways to do this that were coming out
of the woodwork back in January.)

Using the symlink method described above to replace SmallScanner with the following shell script...

#!/bin/sh

touch /tmp/uhoh.this.is.very.bad.news
exec /Library/Application\ Support/Norton\ Solutions\ Support/Norton\ AntiVirus/SmallScanner.
app/Contents/MacOS/SmallScanner


And then inserting a disk (or using hdiutil to mount a disk image) results in normal looking behavior along with a new file...
-rw-r--r-- 1 root wheel 0 Jan 15 20:10 /tmp/uhoh.this.is.very.bad.news

Etc.

I'd like to thank the Apple Product Security team for being more forthright in their communication with me on this issue, it was a lot better than my previous interactions. I'd like to apologize to all the users that have been unknowingly insecure for the past 289 days, I think I like full disclosure better too given the way vendors seem to drag their feet.

Review: Issaquah Brew House

After a long day of Eileen and Jeanie studying constitutional law and me painting an interior wall, Tom stopped by and we decided to head out to the Issaquah Brew House for dinner. We were met with what I can only describe as the most untimely service I've ever received at a restaurant.

It made a good excuse to give the "Submit a review" feature of Google Maps a whirl. The review is online.

The experiences have led me to wonder what the optimum server to table ratio is. I know there's a lot of clamor on the internet that claims that the gruff service in Europe is because servers handle more tables and (as a result) have to be somewhat more efficient, and have less time to be personable. Presumably someone with experience in restaurant management would have a good idea, but 6 tables seems like a reasonable maximum from what I'm reading online.

How Long Do You Wait For Responsible Disclosure?

A vocal minority of people were critical of the timeline last time I found a security flaw so let's try this: (names changed to protect the innocent and the guilty)

• 2007-Jan-16 - Reported local privilege escalation issue to Vendor D
• 2007-Jan-17 - Vendor D will "review as soon as possible"
• 2007-Jan-31 - Vendor D "working on planning a fix", will coordinate release when product update has ETA
• 2007-Apr-20 - Vendor D thinks it would be better if Vendor J made changes to fix the problem in Vendor D's software
• 2007-Jun-21 - Contacted Vendor J for status
• 2007-Jun-22 - Vendor J says precisely which changes they're going to make for their next release (slated for Q4). These changes are not enough to protect Vendor D's software.
• 2007-Aug-29 - Vendor D says they've made suggestions to Vendor J, but otherwise aren't going to do anything to fix this issue
• 2007-Oct-01 - It turns out that Vendor J's recent builds indeed don't do enough to cover up the vulnerability in Vendor D's software

Beyond that, people running current versions of vendor J's software will be vulnerable forever because vendor D says they aren't going to do anything about it: (from Vendor D's August 29th email)

[Vendor D] does not currently plan to make changes to our existing products
to directly address the problem you reported. The changes would require
considerable architectural modifications for those products, and the changes
could cause other problems for those products if [Vendor J] subsequently
release[sic] an ... update to address the underlying problem.

My immediate thoughts are that a disclosure deadline late this month would be appropriate at this point. That'll give me time to prepare a third-party patch to make the fix that Vendor D should've made ages ago, and give the parties some additional PR prep time (beyond the 9 months they've already received). I have to say that Vendor J really isn't at fault here, Vendor D made a stupid mistake and now doesn't want to take the time to fix it.

But this is blog land, so maybe people have thoughts.

Update: I've told the vendors November 1 (or earlier at their discretion).

...but how many Big Macs will it buy?

There was a conversation about investment at work that mentioned stocks, gold and the "Big Mac Index" so I decided to do a quick analysis.

Year	Big Mac	DJIA	Big Macs per DJIA	$/oz Gold	Big Macs per oz Gold
2001	$2.54	10790	4248	271	106
2002	$2.49	10259	4120	278	111
2003	$2.65	8601	3245	343	129
2004	$2.90	10409	3589	417	143
2005	$3.15	10827	3437	428	135
2006	$3.15	10883	3454	530	168
2007	$3.22	12474	3873	640	198

It didn't quite work out the way I had expected it to. Plotting the CPI (or the Euro) against these numbers might also be interesting.

Data Validation Rant

I just signed up to renew my ACM membership for the first time since I was a student back at WWU. I have to admit to feeling kind of bad about having finally caved in to the direct mail they've been bombarding me with, but it did offer a reasonable discount. So I'm busy filling out their online form that asks for all sorts of information they can use to direct additional marketing at me and I click the "continue" button, but alas I cannot continue.

So why can I not continue? Everything I entered is correct, I double-checked. It turns out I put a dash in my zip+4 code, and for them that's an error. The US Postal Service disagrees, and in fact insists that xxxxx-xxxx is the "standard format" for a zip code. One would hope that the ACM of all organizations could figure out how to validate data without looking stupid, but apparently that's too much.

This is a real frustration in lots of other online settings as well. There are quite a few online merchants that refuse to process your payment unless you leave the spaces out of your credit card number. They display stern warnings like "Important: Please do not put spaces or dashes between credit card numbers." If they can't even figure out how to remove extraneous spaces or dashes from the information I give them, should I be trusting them to get the rest of my order correct and not have my personal information stolen? Dealing with that input is maybe 4 lines of code if you're trying to make it hard. It's usually not the merchant's fault, they're just buying some third party service. Any service that merchants are having to pay for that can't manage to get this right should be publicly shamed for their lack of competence.

Email addresses are also apparently a tricky beast for people who are building online tools. There are a lot of characters that are valid in an email address that various online services tend to choke on. There are numerous examples online disguised as "how-tos" that are actually "how-not-to-dos". The example I'm picking on in this case doesn't accept addresses with a + in them. Addresses like learn+to+read@rfc2822.int are in fact perfectly legitimate email addresses, as are addresses with hyphens, underscores, carets, tildes, equals and a lot of other somewhat obscure characters. Mail servers seem to deal successfully with these things, one would hope most
web application writers could cope with it too.

Come on all you folks that are building tools for the web, it's not hard to get these things right by just being little bit more pragmatic about it.

Moved to Blogger

As you may have noticed, I’ve moved the blog part of the site over here to Blogger’s new custom domain feature. Some old links to the blog pages may not work any more, but I've tried to get the majority of them to redirect correctly. My old custom hacked up Typo install was getting frayed around edges and its easier to let a free service handle this stuff for me as long as I can extract my data later.

It turns out that it's not too hard to take the data from Typo articles by getting them by id number and then finagle it into something that the Blogger API will take and do the migration programmatically. I did have to clean up the XHTML in places where tags hadn’t quite lined up, but it wasn't all that much work.

BOM Shelter: MoAB 5, 8, 15 Permissions Fix

Mac OS X, and a number of programs by third parties, have some risky permissions by default. I’ve taken the work I did a couple weeks ago and updated it to cover over more of these problems (MoAB days 5, 8, and 15). It also has a new more clever name: bom-shelter.py (sig)

To get this script, simply save the bom-shelter.py link to your disk.

To verify the script you get is one I wrote, you can download the signature and gpg --verify bom-shelter.py if you happen to have GnuPG installed and have a reason to trust my public key (0x4185664C).

To use this script, you must, from an admin account, run sudo python bom-shelter.py in Terminal, iTerm, or some other reasonable equivalent.

This script does the following for each of the MoAB advisories listed above:
#5: The permissions on BOM files are made more secure and /Library/Receipts (and important descendants) get a sticky bit to prevent shenanigans.

#8: /Library/Frameworks gets a sticky bit to prevent potential adversaries from being able to replace components that Application Enhancer runs as root inside Application Enhancer.framework.

#15: The three setuid root programs that can be overwritten by members of the “admin” group in /Applications/Utilities mentioned in the advisory are changed to not be “admin”-writable. This is also done to /Applications/System Preferences.app/Contents/Resources/installAssistant which has a similar vulnerability.

For all of these things, the script also edits the BOM files in /Library/Receipts to ensure that if you “repair permissions” on your disk these vulnerabilities will not reappear. The BOM file format is not very well documented so these edits may or may not work for you, but they should not corrupt the file. The editing function is careful to only change values if they are what is expected, otherwise it’ll print a warning and not make a change. Backup versions of your BOM files are saved as part of this process.

If you happen to have Application Enhancer installed, in order to secure your machine with Landon Fuller’s awesome MoAB Fixes or any other reason, please take the time to secure /Library/Application Enhancers outside your home directory and ~/Library/Application Enhancers inside your home directory. Malicious code can write things there without your permission and if Application Enhancer uses those patches without asking you, it might make you sad.

Counting Trigrams for Fun

There is a thread over at the forums for the xkcd comic strip with a puzzle game to find trigrams. To help out my brain which has been full of number-related work lately, I whipped up a Python script “trigramtastic.py” to help find more challenging trigrams for the game. Feeding it things like /usr/share/dict/web2 can produce some helpful results, although there are a lot of other potential data sources.

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.