Xamarin Studio For Mac 6.2.1 (Build 3) / 6.3 (Build 863) Privilege Escalation

Type packetstorm
Reporter Yorick Koster
Modified 2017-08-14T00:00:00


Xamarin Studio for Mac API documentation update affected by local  
privilege escalation  
Yorick Koster, April 2017  
Xamarin Studio is an Integrated Development Environment (IDE) used to  
create iOS, Mac and Android applications. Xamarin Studio supports  
developments in C# and F# (by default). The API documentation update  
mechanism of Xamarin Studio for Mac is installed as setuid root. This  
update mechanism contains several flaws that could be leveraged by a  
local attacker to gain elevated (root) privileges.  
See also  
- CVE-2017-8665  
Tested versions  
This issue was successfully verified on Xamarin Studio for Mac version  
6.2.1 (build 3) and version 6.3 (build 863).  
Microsoft released a new version of Xamarin.iOS that addresses this  
Looking at the script, the first thing that probably stands out is the fact the script uses an insecure work directory. This directory is created under /tmp, the only 'random' part is the process identifier of the script. Since these identifiers are sequential it is not very hard for an attacker to predict what the folder name will be. It is even possible to pre-create all possible folder names (as symbolic links). The script performs very little error checking, if a certain step fails (eg, the target directory exists) the script usually continues executing the next command.  
This folder is used for storing a number of .NET Assemblies (DLLs) that are later used by the mdoc application. If the folder ~/Library/Developer/Shared/Documentation/DocSets does not exist, the script will download a DMG file from internet, mount it and extract files from a PKG files that is located in the DMG file. Since the attacker can control the work directory it is (partially) possible to control where the files are extracted.  
Before the DMG is mounted and the files are extracted, the script first checks the MD5 digest of the DMG file against a hard coded value. This check can be circumvented using a named pipe. In this case the attacker can return the original DMG file when the MD5 check is done, and return a different one when it is mounted with hdiutil. Using symbolic links the attacker can control the mount root where the DMG file will be mounted, for example the DMG file can be mounted under /etc. The files located in the DMG file will appear in a folder under this mount root.  
# See if we have apple doc and if not get it  
if test -d $APPLE_DOCSET_PATH; then  
if test x$TMPDIR = x; then  
echo TMPDIR is invalid.  
exit 1  
mkdir $TMPDIR  
curl -o $target_path $full_url  
#cp /tmp/ios-docs-download.4184/091-9917-A.dmg $target_path  
sum=`md5 -q $target_path`  
if test x$sum = x$EXPECTED; then  
mkdir $mount_path  
if hdiutil attach $target_path -mountroot $mount_path -nobrowse > $TMPDIR/output; then  
dir_path=`awk '$2 ~ /Apple_HFS/ { print $3}' $TMPDIR/output`  
pkgutil --expand $dir_path/iOSDocset.pkg $tmp_unpack  
cd $tmp_unpack  
bzip2 < Payload | cpio -dmiv  
A local attacker could in theory craft an attack that creates a folder at a particular location, which is used by another process running with elevated privileges. An example would be to mount the DMG at /etc/sudoers.d to add a sudo configuration that allows the local user to run a command as root without requiring a password. On most systems the /etc/sudoers.d is already present, in this case hdiutil will mount the DMG at another location (usually /etc/sudoers.d 2) preventing this particular attack scenario.  
Another approach for attacking this script is to look at the binaries it uses. Often these binaries have their own set of environment variables and or configuration files they use. In case of setuid root binaries the environment is partly controllable by the user calling the binary. One of the binaries used is curl that supports a number of environment variables. In addition, it checks whether a configuration file is present in ~/.curlrc. In our case it will check the home folder of the user running apple-doc-wizard. Consequently, the curl configuration file is fully controllable by the local attacker. Exploiting this issue is very trivial, using the url and output configuration options it is possible to download a file from any URL and store it in any arbitrary location. Since curl is run as root, it is possible to overwrite or create any local file. The following proof of concept can be used to demonstrate this issue:  
# WARNING: this scripts overwrites ~/.curlrc and /private/etc/sudoers (when successful)  
rm -rf ~/Library/Developer/Shared/Documentation/DocSets  
cat << __EOF > /private/tmp/sudoers  
%everyone ALL=(ALL) NOPASSWD: ALL  
cat << __EOF > ~/.curlrc  
echo "*** press CRL+C when the download starts ***"  
sudo -- sh -c 'rm -rf /private/tmp/ios-docs-download.*; su -'  
rm -f /private/tmp/sudoers ~/.curlrc