Xamarin Studio for Mac API documentation update affected by local privilege escalation


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

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 issue. However, as of 2019 the documentation is no longer available (support ID 4037359).


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).

Xamarin Studio ships with the apple-doc-wizard application that is used to update the API documentation for the Xamarin.iOS SDK. Some steps in this update process require root privileges and consequently the application is installed as setuid root. When it start some housekeeping is done like cleaning the PATH environment variable after which the script apple-doc-wizard.sh is run (through sudo). Letting local users run scripts with root privileges is generally advised against. Some attacks are prevented due to the housekeeping done by apple-doc-wizard/sudo. Yet there are still flaws in the current implementation that (potentially) allow a local attacker to gain elevated privileges.


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

Questions or feedback?