what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

macnav-escalate.txt

macnav-escalate.txt
Posted Nov 2, 2007
Authored by William A. Carrel | Site blog.carrel.org

Symantec's Norton AntiVirus for Macintosh (NAV) contains a vulnerability that can lead to local privilege escalation from group admin to root.

tags | exploit, local, root
SHA-256 | 28901a071fdeefc06e5ebdcbb1f2e864de15ac88b6e88309dfae7a15d7e4da5b

macnav-escalate.txt

Change Mirror Download
Text from URL: http://blog.carrel.org/2007/11/security-advisory-norton-antivirus-for.html

== 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/DiskMountNotify.
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...
<<EOF
#!/bin/sh

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

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.

Login or Register to add favorites

File Archive:

December 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    0 Files
  • 2
    Dec 2nd
    41 Files
  • 3
    Dec 3rd
    25 Files
  • 4
    Dec 4th
    0 Files
  • 5
    Dec 5th
    0 Files
  • 6
    Dec 6th
    0 Files
  • 7
    Dec 7th
    0 Files
  • 8
    Dec 8th
    0 Files
  • 9
    Dec 9th
    0 Files
  • 10
    Dec 10th
    0 Files
  • 11
    Dec 11th
    0 Files
  • 12
    Dec 12th
    0 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close