MOAB Fix #19 Released
Landon Fuller
MOAB_19_and_Java_Extra_Credit.20070120233924.16291.zadder.local.html
Includes:
Transmit FTP URL buffer overflow patch (w.carrel)
Java GIF buffer overflow patch
"Warn before mounting DMG" support
-landonf
frozenINcarbonite
with the vulnerability in the program itself?
> PGP.sig
> 1KDownload
Landon Fuller
On Jan 21, 2007, at 11:04 AM, frozenINcarbonite wrote:
>
> So is it safe to go ahead and use the Application Enhancer patch even
> with the vulnerability in the program itself?
I think so.
A local process, running in the administrator group, can acquire root
without any user interaction. There are a multitude of different
vectors that would allow this due to the administrator-writable
directories in /Library, and Application Enhancer is but one of them.
I believe that the phrasing and timing of the advisory was
specifically intended to censure Application Enhancer, and does not
accurately reflect the broad nature of the issue. The admin-writable
permissions of /Library expose *all* third party frameworks,
application support files, et-cetera to replacement by an admin user.
For better or worse, this is by design. Third parties must install
global frameworks in /Library/Frameworks; only Apple is permitted to
use /System/Library/Frameworks. If Application Enhancer's aped binary
was placed somewhere other than /Library, in conflict with Apple's
guidelines, the libraries it links against would still be vulnerable
to replacement by an administrative user.
http://developer.apple.com/documentation/MacOSX/Conceptual/
BPFrameworks/Tasks/InstallingFrameworks.html#//apple_ref/doc/uid/
20002261-97184-TPXREF101
* Most public frameworks should be installed at the local level
in /Library/Frameworks.
* If your framework should only be used by a single user, you
can install it in the ~/Library/Frameworks subdirectory of the
current user; however, this option should be avoided if possible.
* If they are to be used across a local area network, they can
be installed in /Network/Library/Frameworks; however, this option
should be avoided if possible.
Third-party frameworks should never be installed in the /System/
Library/Frameworks directory. Access to this directory is restricted
and is reserved for Apple-provided frameworks only.
http://developer.apple.com/documentation/MacOSX/Conceptual/
BPFileSystem/Articles/WhereToPutFiles.html
The preferred location for nearly all support files is in the
Application Support directory of the appropriate domain.
Which domain you choose to store your support files depends on the
intended use of those resources.
If the resources apply to all users on the system, such as document
templates, place them in /Library/Application Support.
Ultimately, If you're concerned about the possibility for local admin
to root vulnerabilities due to file system permissions, I'd check out
wac's BOM Shelter script:
http://blog.carrel.org/2007/01/bom-shelter-moab-5-8-15-permissions-
fix.html
-landonf
frozenINcarbonite
fixes all of these issues soon. It stresses me out worrying about being
online.
On Jan 21, 2:36 pm, Landon Fuller <land...@bikemonkey.org> wrote:
> On Jan 21, 2007, at 11:32 AM, Landon Fuller wrote:
>
> > accurately reflect the broad nature of the issue.I should say, "the multi-vendor nature of the issue"
>
> PGP.sig
> 1KDownload
Landon Fuller
On Jan 21, 2007, at 12:28 PM, frozenINcarbonite wrote:
>
> Thanks for the info. This stuff is totally confusing. I just hope
> Apple
> fixes all of these issues soon. It stresses me out worrying about
> being
> online.
Me too =)
Rosyna
correct. None of the files are group or globally writable. The issue
is that Mac OS X itself creates the /Library/Frameworks/ directory
with admin writable permissions.
Note that MOAB 5, 8, 15 all have the *exact* same cause.
[stability-64:~] sexbomb% ls -AFld /Library/Frameworks
drwxrwxr-x 30 root admin 1020 Jan 1 04:48 /Library/Frameworks/
This allows an admin user to copy any framework inside there (which
drops the owner to the current user) and then an admin user (the
current user that duplicated the framework) can change any binary and
put it back in the original location.
This affects any vendor which installs anything into
/Library/Frameworks/ (which is the proper place to put things, as
Landon already said).
This fix is to change the permissions on /Library/Frameworks/. Just
open the terminal (/Applications/Utilities/Terminal) and type:
sudo chmod g-w /Library/Frameworks/
and do not repair permissions afterwards (as it will undo the fix).
Btw, below is a list of the permissions set on the files/folder in
the APE framework. Notice that nothing is group writable and the
actual ApplicationEnhancer binary is not writable by anyone.
[stability-64:~] sexbomb% ls -AFld
/Library/Frameworks/ApplicationEnhancer.framework
drwxr-xr-x 9 root admin 306 Oct 23 01:46
/Library/Frameworks/ApplicationEnhancer.framework/
[stability-64:~] sexbomb% ls -AFlR
/Library/Frameworks/ApplicationEnhancer.framework/
total 48
lrwxr-xr-x 1 root admin 36 Oct 23 01:46 ApplicationEnhancer@ ->
Versions/Current/ApplicationEnhancer
lrwxr-xr-x 1 root admin 27 Oct 23 01:46 Frameworks@ ->
Versions/Current/Frameworks
lrwxr-xr-x 1 root admin 24 Oct 23 01:46 Headers@ ->
Versions/Current/Headers
lrwxr-xr-x 1 root admin 26 Oct 23 01:46 Libraries@ ->
Versions/Current/Libraries
lrwxr-xr-x 1 root admin 26 Oct 23 01:46 Resources@ ->
Versions/Current/Resources
lrwxr-xr-x 1 root admin 22 Oct 23 01:46 Tools@ -> Versions/Current/Tools
drwxr-xr-x 4 root admin 136 Oct 23 01:46 Versions/
/Library/Frameworks/ApplicationEnhancer.framework//Versions:
total 8
drwxr-xr-x 8 root admin 272 Oct 23 01:46 A/
lrwxr-xr-x 1 root admin 1 Oct 23 01:46 Current@ -> A
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A:
total 392
-r-xr-xr-x 1 root admin 200028 Oct 21 03:45 ApplicationEnhancer*
drwxr-xr-x 3 root admin 102 Oct 23 01:46 Frameworks/
drwxr-xr-x 6 root admin 204 Oct 23 01:46 Headers/
drwxr-xr-x 4 root admin 136 Oct 23 01:46 Libraries/
drwxr-xr-x 7 root admin 238 Oct 23 01:46 Resources/
drwxr-xr-x 3 root admin 102 Oct 23 01:46 Tools/
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Frameworks:
total 0
drwxr-xr-x 6 root admin 204 Oct 23 01:46 UNHaxieCommon.framework/
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Frameworks/UNHaxieCommon.framework:
total 24
lrwxr-xr-x 1 root admin 24 Oct 23 01:46 Headers@ ->
Versions/Current/Headers
lrwxr-xr-x 1 root admin 26 Oct 23 01:46 Resources@ ->
Versions/Current/Resources
lrwxr-xr-x 1 root admin 30 Oct 23 01:46 UNHaxieCommon@ ->
Versions/Current/UNHaxieCommon
drwxr-xr-x 4 root admin 136 Oct 23 01:46 Versions/
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Frameworks/UNHaxieCommon.framework/Versions:
total 8
drwxr-xr-x 5 root admin 170 Oct 23 01:46 A/
lrwxr-xr-x 1 root admin 1 Oct 23 01:46 Current@ -> A
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Frameworks/UNHaxieCommon.framework/Versions/A:
total 96
drwxr-xr-x 4 root admin 136 Oct 23 01:46 Headers/
drwxr-xr-x 4 root admin 136 Oct 23 01:46 Resources/
-rwxr-xr-x 1 root admin 47656 Oct 21 03:45 UNHaxieCommon*
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Frameworks/UNHaxieCommon.framework/Versions/A/Headers:
total 16
-rw-r--r-- 1 root admin 350 Oct 21 03:45 UNAPEUtilities.h
-rw-r--r-- 1 root admin 549 Oct 21 03:45 UNHaxieCommon.h
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Frameworks/UNHaxieCommon.framework/Versions/A/Resources:
total 8
drwxr-xr-x 3 root admin 102 Oct 23 01:46 English.lproj/
-rw-r--r-- 1 root admin 677 Oct 21 03:45 Info.plist
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Frameworks/UNHaxieCommon.framework/Versions/A/Resources/English.lproj:
total 8
-rw-r--r-- 1 root admin 196 Oct 21 03:45 InfoPlist.strings
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Headers:
total 40
-r--r--r-- 1 root admin 541 Oct 21 03:29 APEInstall.h
-r--r--r-- 1 root admin 932 Oct 21 03:29 APEManagerPrefPane.h
-r--r--r-- 1 root admin 4193 Oct 21 03:29 APETools.h
-r--r--r-- 1 root admin 4069 Oct 21 03:29 ApplicationEnhancer.h
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Libraries:
total 2448
-r-xr-xr-x 1 root admin 44700 Oct 21 03:46 APETools.o*
-r-xr-xr-x 1 root admin 1206552 Oct 21 03:47 install.o*
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Resources:
total 264
drwxr-xr-x 3 root admin 102 Oct 23 01:46 ApplicationEnhancer.loginPlugin/
-r--r--r-- 1 root admin 1139 Oct 21 03:44 Info.plist
-r--r--r-- 1 root admin 63066 Oct 21 03:29 ape.icns
-r-xr-xr-x 1 root admin 45952 Oct 21 03:45 aped*
-r-sr-sr-x 1 root admin 13620 Oct 21 03:44 rosetta_optimize*
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Resources/ApplicationEnhancer.loginPlugin:
total 0
drwxr-xr-x 4 root admin 136 Oct 23 01:46 Contents/
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Resources/ApplicationEnhancer.loginPlugin/Contents:
total 8
-r--r--r-- 1 root admin 932 Oct 21 03:46 Info.plist
drwxr-xr-x 3 root admin 102 Oct 23 01:46 MacOS/
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Resources/ApplicationEnhancer.loginPlugin/Contents/MacOS:
total 80
-r-xr-xr-x 1 root admin 37184 Oct 21 03:46 ApplicationEnhancer*
/Library/Frameworks/ApplicationEnhancer.framework//Versions/A/Tools:
total 2392
-r-xr-xr-x 1 root admin 1220900 Oct 21 03:47 ape_install*
Ack, at 1/21/07, frozenINcarbonite said:
>So is it safe to go ahead and use the Application Enhancer patch even
>with the vulnerability in the program itself?
--
Sincerely,
Rosyna Keller
Technical Support/Carbon troll/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
It's either this, or imagining Phil Schiller in a thong.
Greg Hurrell
> The permissions for the APE framework and all files inside it are
> correct. None of the files are group or globally writable. The issue
> is that Mac OS X itself creates the /Library/Frameworks/ directory
> with admin writable permissions.
>
> Note that MOAB 5, 8, 15 all have the *exact* same cause.
Yes, the permissions on /Library/Frameworks/ are probably too lax, but
I think the point of the MOAB 8 advisory (the APE flaw) is not just
that those permissions are too loose (Apple's problem) but that APE
shouldn't be executing anything with root privileges before performing
adequate validation on the tool to be run (Unsanity's problem).
Or to put it another way, if it is a known issue that the binary is in
a group-writable location, then APE should either install the tool
somewhere else or validate it before running it with root privileges.
Of course even if it validates it before running there is a still a
possible race condition (check tool, attacker replaces tool,
replacement is run instead) but it's still better than doing no check
at all.
> This fix is to change the permissions on /Library/Frameworks/. Just
> open the terminal (/Applications/Utilities/Terminal) and type:
>
> sudo chmod g-w /Library/Frameworks/
>
> and do not repair permissions afterwards (as it will undo the fix).
It should also be noted that permissions get "repaired" whenever you
install OS updates, or any other installer package which sees fit to
check those permissions.
Rosyna
>El 22/1/2007, a las 5:00, Rosyna escribió:
>
>> The permissions for the APE framework and all files inside it are
>> correct. None of the files are group or globally writable. The issue
>> is that Mac OS X itself creates the /Library/Frameworks/ directory
>> with admin writable permissions.
>>
>> Note that MOAB 5, 8, 15 all have the *exact* same cause.
>
>Yes, the permissions on /Library/Frameworks/ are probably too lax, but
>I think the point of the MOAB 8 advisory (the APE flaw) is not just
>that those permissions are too loose (Apple's problem) but that APE
>shouldn't be executing anything with root privileges before performing
>adequate validation on the tool to be run (Unsanity's problem).
>
>Or to put it another way, if it is a known issue that the binary is in
>a group-writable location, then APE should either install the tool
>somewhere else or validate it before running it with root privileges.
>Of course even if it validates it before running there is a still a
>possible race condition (check tool, attacker replaces tool,
>replacement is run instead) but it's still better than doing no check
>at all.
This is not the issue. It is moot if the aped
binary is in a group writable location or not.
The issue is the framework itself and all
frameworks in /Library/Frameworks/. It can be
modified and anything that links against it (such
as the aped daemon) will automatically load the
modified framework.
> > This fix is to change the permissions on /Library/Frameworks/. Just
>> open the terminal (/Applications/Utilities/Terminal) and type:
>>
>> sudo chmod g-w /Library/Frameworks/
>>
>> and do not repair permissions afterwards (as it will undo the fix).
>
>It should also be noted that permissions get "repaired" whenever you
>install OS updates, or any other installer package which sees fit to
>check those permissions.
Except this is not true. The repair permissions
tasks are not run when you install an OS X update.
Greg Hurrell
> This is not the issue. It is moot if the aped
> binary is in a group writable location or not.
> The issue is the framework itself and all
> frameworks in /Library/Frameworks/. It can be
> modified and anything that links against it (such
> as the aped daemon) will automatically load the
> modified framework.
If you are developing a tool that runs with root privileges and you are
worried about it linking to code which is vulnerable to replacement
then maybe you should use static linking instead? The fact is, those
are the permissions on that folder, so rather than declaim
responsibility for something outside your control I think you should
instead address the issue at a level that you can control.
> >It should also be noted that permissions get "repaired" whenever you
> >install OS updates, or any other installer package which sees fit to
> >check those permissions.
>
> Except this is not true. The repair permissions
> tasks are not run when you install an OS X update.
I was of the understanding that this was not the case, although you may
be right; I guess we'll see when 10.4.9 is released.
Rosyna
> > This is not the issue. It is moot if the aped
>> binary is in a group writable location or not.
>> The issue is the framework itself and all
>> frameworks in /Library/Frameworks/. It can be
>> modified and anything that links against it (such
>> as the aped daemon) will automatically load the
>> modified framework.
>
>If you are developing a tool that runs with root privileges and you are
>worried about it linking to code which is vulnerable to replacement
>then maybe you should use static linking instead? The fact is, those
>are the permissions on that folder, so rather than declaim
>responsibility for something outside your control I think you should
>instead address the issue at a level that you can control.
Mac OS X does not support static linking because mach-o and the ilk suck.
See the bottom of
http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/building/chapter_4_section_2.html
And
http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Link-Options.html
Using the APE framework also has other benefits that bringing in the
code statically cannot offer.
Furthermore, even when this is fixed someone that explicitly wanted
to make APE look bad could just write a setuid root application, link
to the APE framework, then modify the APE framework as non-root and
use that. Completely ignoring the fact that all third party
frameworks installed in the *correct* spot have this same problem.
> > >It should also be noted that permissions get "repaired" whenever you
>> >install OS updates, or any other installer package which sees fit to
>> >check those permissions.
>>
>> Except this is not true. The repair permissions
>> tasks are not run when you install an OS X update.
>
>I was of the understanding that this was not the case, although you may
>be right; I guess we'll see when 10.4.9 is released.
Permissions are only reset to default for two reasons during updating.
1. The updater explicitly changes them (such as the /Library/Widgets/
permissions bug).
2. The updater includes something along the path and "Override
permissions" is set on the package.
Number 2 doesn't apply for Mac OS X 10.4.x updates since nothing in
/Library/Frameworks/ in supplied with an OS X install. So there's no
chance to overwrite the permissions.
Number one is the only case here and it has to be explicitly fixed.
My point is that installing an OS X update won't reset the
/Library/Frameworks/ permissions to the *wrong* permissions after
someone has manually fixed them. Only repairing permissions or
otherwise changing the permissions manually will change them back to
775.
Greg Hurrell
> Mac OS X does not support static linking because mach-o and the ilk suck.
I think that's a bit misleading. I have built static libraries and
linked to them statically on Mac OS X. The links you provide do indeed
show that libSystem is only available as a dynamic library, but what I
was suggesting was not that you try to link statically against system
frameworks intended only for dynamic linking; rather, I wanted to
suggest that if you are worried about your root-tool dynamically
loading code that you wrote but which is vulnerable to substitution by
others then you could entirely forget dynamic linking and use static
linking. And in fact, seeing as you have the source code you could do
whatever you want with it and directly embed the necessary
functionality in any part of APE without linking at all.
> Using the APE framework also has other benefits that bringing in the
> code statically cannot offer.
Evidently your product must take the shape of a framework so that
others who write APE plug-ins can use it at runtime. I wouldn't try to
make the case that you shouldn't ship it as a framework; I just wanted
to point out that as the vendor there's nothing forcing you to blindly
dynamically link against your framework in your root-privileges tool.
> Furthermore, even when this is fixed someone that explicitly wanted
> to make APE look bad could just write a setuid root application, link
> to the APE framework, then modify the APE framework as non-root and
> use that.
I don't really understand your point there. We're talking about local
privilege escalation vectors, not making APE look bad. If someone can
get a setuid root application of their own design on your machine,
that's instant root, no escalation required and no involvement from APE
or any other piece of software either.
> Completely ignoring the fact that all third party
> frameworks installed in the *correct* spot have this same problem.
Yes, it is the correct spot, and yes, the correct spot has overly
permissive default permissions on it, but I think we need to divide the
resulting security risks into two categories:
1. The basic risk wherein any such framework can be replaced by an
admin user.
2. The subcategory in which such a framework is dynamically loaded by a
tool running with root privileges.
Only in the second class do you have an instant local privilege
escalation. In the first class you can do as much damage as the user
running the code, but you don't have instant and automatic root access.
Seeing as your software falls into the second category, I am just
trying to identify ways of reducing the risk of such an attack without
having to relying on your users to not only manually override the
default filesystem permissions but ensure they stay that way.
William A. Carrel
The bom-shelter.py utility I put together helps with this. It sets
permissions a safe sort of way for /Library/Frameworks (among other
things) and also does surgery on the Archive.bom files that "Repair
Permissions" uses to keep things from getting mucked up inadvertently.
That said, I'm not sure if the changes will survive OS upgrades, but
one would hope that Apple will address some of these permission
issues.
At the end of the day, it's not safe for suid processes to access
anything in /Library until the permissions are fixed, either by the
installer itself, or by Apple.
--
wac
Landon Fuller
On Jan 22, 2007, at 4:37 AM, Greg Hurrell wrote:
>
> Rosyna ha escrito:
>
>> This is not the issue. It is moot if the aped
>> binary is in a group writable location or not.
>> The issue is the framework itself and all
>> frameworks in /Library/Frameworks/. It can be
>> modified and anything that links against it (such
>> as the aped daemon) will automatically load the
>> modified framework.
>
> If you are developing a tool that runs with root privileges and you
> are
> worried about it linking to code which is vulnerable to replacement
> then maybe you should use static linking instead? The fact is, those
> are the permissions on that folder, so rather than declaim
> responsibility for something outside your control I think you should
> instead address the issue at a level that you can control.
Unfortunately, any application vendor mitigation strategies appear
stillborn, insofar as /Library/* still retains admin-writable
permissions (eg, /Library/Receipts).
-landonf
antibozo
> Note that MOAB 5, 8, 15 all have the *exact* same cause.
That is *exactly* false. There are at least two distinct
vulnerabilities here:
1. The permissions on /Library/* are moronic.
2. diskutil repairs permissions without checking what it is repairing.
Any correctly implemented tool of this type would have secure digests
squirreled away to compare. Race conditions between digest comparison
and repair could be avoided with an appropriate sequence of fchown(2)
and fchmod(2) (assuming Mac OS X includes these).
Rosyna
because you can arbitrarily overwrite any receipt or arbitrarily
create new ones. This is possible because of #1. Even if receipts
were signed, completely replacing a receipt would also allow for
signed receipts.
--
Greg Hurrell
> These things say the same thing. #2 is especially possible only
> because you can arbitrarily overwrite any receipt or arbitrarily
> create new ones. This is possible because of #1. Even if receipts
> were signed, completely replacing a receipt would also allow for
> signed receipts.
I disagree with you. In arguing that these two different defects are
actually "the same thing", are you arguing that only one of them should
be fixed? (And if so, how do you justify that argument?) Or if you are
arguing that both should be fixed, how can you argue that they are the
"same thing"?
antibozo
> These things say the same thing. #2 is especially possible only
> because you can arbitrarily overwrite any receipt or arbitrarily
> create new ones. This is possible because of #1. Even if receipts
> were signed, completely replacing a receipt would also allow for
> signed receipts.
Wrong again.
Just because the only vector we happen to know about this week for
getting diskutil to do stupid things is the idiotic permissions on
/Library/*, that doesn't mean that diskutil isn't broken by design.
There may be plenty of other vectors (other bugs in setuid programs,
for example) for creating the precondition for exploiting diskutil's
vulnerability. There may also be areas outside of /Library where
diskutil can be exploited. Fixing /Library/* doesn't obviate the
requirement for fixing diskutil--these are completely independent
problems.
You are correct that diskutil's vulnerability is trivial to exploit
because its database isn't properly protected, but even if the
permissions were corrected, diskutil would remain broken because it is
willing to assert setuid privileges on objects that are authenticated
only by pathname. No, you couldn't fix diskutil without fixing the
database permissions, but fixing those permissions alone wouldn't solve
the problem.