Breaking Mac OS X Program Security

by Sibios  (sibios@gmail.com)

Mac OS X has been released with a program that limits what program users are allowed to run based on a simple set of files.  This program is called MCX.

This article is aimed at displaying the weaknesses in MCX and the XML files that Mac OS X uses to define both the applications that are installed on the system and the applications that a user can run.  Most of my research is based around the Macs that I use daily around my school, which are set up as an environment in which all student data, apps, and user settings are stored on the local XServes.

The physical computers that one interfaces with act as terminal clients to the servers.  As with most documents I will simply remove all responsibility from myself as a writer for what you do in front of one of the computers you use.  I will also lie about how this article is purely for educational purposes and is not intended for any malignant uses.  I don't care what you do, enjoy the knowledge or exploit it, but I'm not responsible for your actions.

After logging in to a user account one can view the MCX preferences that have been ascribed to them by accessing:

/Users/<USER AC COUNT>/Library/Preferences/com.apple.MCX.plist

All Mac OS X applications are defined by a specific sequence based on the URL at which they could be found online.

Examples:

  • Apple's Safari is: com.apple.Safari
  • Mozilla Firefox is: org.mozilla.Firefox
  • Adobe Photoshop is: com.adobe.Photoshop

This seems to mimic the D-Bus program that one can find on Linux intended to provide means for communication between applications.

All of these texts are used to define what the application is.  Now that we know this, the question remains, "How can one exploit this?"

This question has a simple answer: when one cannot exploit the server, one exploits the client.

In this case, we will modify our applications so that MCX thinks that we are running a program that we are allowed to run.  But if you have access to a terminal you should be able to run any application you want without any MCX interference.  However, we will demonstrate the method of tricking MCX to gain access to the Terminal.

After logging in, one would open up the Finder app and access:

/Applications/Utilities

If you are lost in the world of the Finder, click the little icon of a house in the dock to open a Finder window and access your hard drive (there is an icon on the left on the standard install).

You will see an "Applications" folder, double-click that, followed by the "Utilities" folder.

At this point you may want to try running the Terminal normally (just double-click it).

If MCX has been set up by a semi-competent admin you should get a warning that reads "You do not have permission to open the application 'Terminal'.  Contact the person who administers your computer or your network administrator for assistance."

I should also mention that the Finder hides many things from the user.

Anything with a . before the name (standard *NIX hidden syntax) will be hidden, any directory with some name followed by a .app or a .pkg will appear as a double-clickable application.

On that note, let's copy the Terminal app to a folder in which we can do some work on it (your home directory would be appropriate).

After returning to your home directory (or wherever you copied the app to) you should find a fresh copy of the Terminal (or whatever you copied).  At this point you want to control-click the icon and select "Show Package Contents".

A new Finder window will pop up showing the contents of the Terminal.app.  Inside you should see a folder named "Contents".

Inside the "Contents" folder you should find three files and two folders: Info.plist, PkgInfo, version.plist, MacOS, and Resources (respectively).

You will want to edit Info.plist so go ahead and open it in a standard ASCII/UTF-8 text editor.

Inside you should find a bunch of fun little variables that control the interactions between Darwin and the Terminal.

If you want to be able to double-click the .app and run the program you will want to modify the <string> associated with the: CFBundleldentifier <key>

This variable identifies the program and reports to MCX.  You will want to modify this to something you know that you are allowed to run.

I usually change it to com.apple.Safari or com.apple.Preview.

If you really want to be able to run this app, change it to something the admins cannot block with MCX: the Finder, the quintessential Mac OS X app: com.apple.finder

You should be able to back out of the Contents, *.app folder, and double-click the app icon to start it.

I have noted that the system does not always recognize the updates.  We can force an update by renaming the application and changing it back to its original name.

If you are a GUI sort of person just repeat this for all of the applications that you want to run.  On the other hand, if you are willing to get your hands dirty, you need only free up access to the Terminal to access these programs.

For example, suppose that you really want to run the installed version of iTunes.  Pop open a Terminal and toss it the following command:

$ /Applications/iTunes.app/Contents/Macos/iTunes

Or, for about any other application just follow the general rule of:

$ /<Location of .app>/<App Name>.app/Contents/MacOS/<App Name>

Any program that is run via the Terminal app is not checked by MCX for permissions.

These commands however fall under the protections that are built into the UNIX core (Mach kernel) that Darwin runs on top of.

This knowledge will not make anyone a figurative deity on a Mac OS X system but it can give a clueless admin a shock.  The uninformed often tote Mac OS as the smart alternative to Windows for safety purposes, however it is quite obvious that it is not nearly as secure as many like to believe.

When in doubt use UNIX permissions for actual security, have fun on any OS X systems you encounter, and inform the rest of us if you find anything cool.

Viel Spass Kinder!  (Have fun kids!)

Return to $2600 Index