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.

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).

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.

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.