We all use network based applications all day long: web browsers, instant messageing clients, mail readers, streaming media players, games, etc. They have become a central part of all Internet users life. One problem with them all is that they might be vulnerable for different types of attacks. One attack type is to craft malicious data (a movie, an url, etc) that will be threated as executable code by the receiving end. This has become standard operating procedure by attackers and is done by exploiting bugs in the graphics engine, the XML parser, the input buffer in some program, or similar means.
We believe that one large and important attack trend, since several years back, has been on server-to-client attacks. A too common example is a hostile web site, malicious or a victim by themself, can inflict harm to your browser. We developed IronSuite because we want to be able to use web browses, IM software et al with a reduced fear that the next site I visit will have an infected banner ad that pwns my machine.
By using sandbox mechanism, the attack surface of a specific MacOSX application should be lowered by restricting that application to a minimum of system level interaction (e.g. file reads, process creation, etc). Network-savy applications face the risk of beeing remotely exploited by stack smashing attacks, heap corruptions, getting injected malicious javascript or other malicious code.
The sandbox technology used by Apple is built on a domain specific control language based on the well-known Scheme language. By writing specific Scheme constructs one can restrictor permit a specific system call, or specific parameters to that system call.
The general idea behind IronSuite is to act as an additional barrier, in case any existing protection mechanism fails, and prevent the controlled program from misbehave. e.g. read files that should be protected (e.g. the web browser controlled by an injected program by a buffer overrun could steal pgp keyring or documents or the users mailbox).
What does it NOT do
One important limitation that all IronSuite protected tools have, is that they cannot update themself while running in sandboxed mode. This is because they do not have write access to the /Application directory or subdirectories there. This is important to know, since it is a design choice to limit the possibility for an attacker to manipulate your program and configuration. The drawback is that updates have to be done outside the sandboxed mode, e.g. close program and then download updates manually and install. Or temporarily restart the program without the IronSuite sandbox, use the built-in update feature, restart again into sandboxed mode.
So be aware. An updated program certainly can have change its internal structure and have added features which the sandbox blocks, so the program can start to misbehave.
There are no such thing as a catch-all security solution, so, to be very clear -
- it is not a replacement for noscript + friends. A nasty javascript that does something INSIDE your browser might still be able to hurt you. The objectives of IronSuite is to restrict what an application can do to the surrounding environment, other applications and data
- It is not a replacement for patching. Some types of bugs are hopefuly catched by the sandbox. Other bugs, in the interfaces that we permit from a sandboxed program might still hurt you.
- It will not protect against kernel bugs or bugs in the sandbox mechanism.
- Attacks that occur elsewhere in the system might still affect your application security. A keylogger or something that records your desktop can still steal passwords, sensitive data you are watching, etc, since it is outside the sandboxed application.
- It is not a replacement for your firewall. Other processes running on your machine can possibly still be remotely exploitable if you does not block them on the network.
- It does not help you protect data-in-transit. You still need TLS/SSL for that.
- your privacy setting (cookies, browsing history, etc) is still using its standard settings.
- Last, but not least, it is not a replacement for street smartness. You still might want to avoid that pr0n or hacking site.
A different packaging of the IronSuite concept is available for MacOSX Tor users. That bundle have the additional objectives to ensureing the users privacy, and thus is more picky on what is read from the file system and work hard to not leave a footprint on the installed system.
IronSuite browsers (IronFox and IronSafari) vs Chrome
A very simple question is to ask what is the differece between using Googles Chrome browser and the browsers developed in the IronSuite project? The major difference lays in where the sandboxing is performed.
Chrome is a program running as a number of collective processes on the computer. One of these processes perform the actual rendering of the finished web page. Each of these processes needs to be protected separately.
The the sandboxes that the IronSuite project have developed for the Firefox and Safari browsers will sandbox the complete browser. Including any add-on programs, components, subsystems, etc that is started from that browser. So a quicktime player or a pdf viewer started by safari will inherit the sandbox restrictions, thus a bug triggered by a malicious PDF or a maliciously crafted movie, will not be able to access your computing environment. But this might also be a problem, since a plugin might not run as anticipated, especially if it has not been tested and rules have been created for it by the IronSuite crew or by yourself.
Some other important differences between Chrome and the IronSuite approach include:
- The Chrome sandbox library was developed by and for the Chrome application. The developers have more introspection possibilities on what the Chrome browser does. The IronsSuite sandbox is developed for sandboxing 3rd party programs. We have no source code access or other means for introspections of many of these applications. The only way to know what to block or accept is to run the program in sandbox debug mode and read the log file, adjust rule file, rinse and repeat.
- IronSuite sanbox runs from process creation until termination. Chrome sandbox runs from the point that the process calls LowerToken()
- The Chrome sandbox is a C++ library distributed with the Chrome distribution. The Apple sandbox mechanism is included in MacOSX 10.6 and later.
However, the mac port of the Chrome browser actually use the Apple Sandbox Policy Language. Searching for files installed by Chrome in /Applications/Google Chrome.app/Contents/Versions/5.0.375.86/Google Chrome Framework.framework/Resources will show:
- nacl-loader.sb
- renderer.sb
- utility.sb
- worker.sb
Besides the MacOS specific details for the Mac implementation of Chrome, one real advantage that the Chrome sandbox have over the IronSuite approach is that Google has implemented their sandbox as a portable C++ library that can be used on many platforms. The IronSuite sandboxing only works on Apple MacOSX since it is just custom sandbox profiles using the sandboxing feature in the OS.
More information on the chrome sandbox can be found Chrome sandbox design description and in the Chrome sandbox FAQ
File system access
For applications that need to access the file system for saving data, the parts of the file system that should be accessible, should be restricted and deterministic.
There are difference on how tightly one can control operations such as file write, file read, file read metadata, file read extended attributes. Several component libraries and MacOSX functions seem to show lots of odd behaviour, such as stat-ing various libraries and standard files. Removing access to these would lead to strange and sometimes unknown side effects.
File creation and file write
- The /private subdirectories
- /tmp subdirectories (which links to /private)
- /var subdirectories (which links to /private)
- Some .plist-files associated with the specific program
- Some lock files used by the program (flaging in the file system that some action is ongoing)
- /dev/dtracehelper device file, used by the sandbox functionality itself
For a web browser, file creation should only be allowed in:
- The "Download Files" area. This is a very important point. When you download files, you cannot save things on the desktop, in a random subdirectory in your home directory, etc.
- The browser cache area
- The browser cookie database
- The browser history database
In addition, file creation is also allowed for various plugins, such as flash and java. These directories include:
- The flash user directory, where tmp files and cookies are stored
- The java cache
- The java console log
File read and file metadata read
There is a difference between letting a process checking the file metadata and letting it read the file content. Where possible, we restrict access to reading metadata, not content
There is alot of files, and even more directories, that needs to be checked when running any MacOSX program. File reads are done all over the place. SOME of those places and files include:
- The applications subdirectory in /Application
- Your home directory. Here we normally only allow metadata checking on the home directory, not general process read access to files or subdirectories contained in that directory
- subdirectories of /Library that contain font, audio, language, graphics drivers, etc, information
- subdirectories of /System/Library that contain font, audio, language, graphics drivers etc, information
- subdirectories of ~/Library that contain font, audio, language, graphics drivers etc, information
- subdirectories of /private
- subdirectories of the /var and /tmp directories that are linked to /private
Process creation
No additional processes should normaly be allowed. Only very specific well-known subprocesses should be allowed.
Some subsystems, add-ons and plugins such as flash support and java runtime support is to be allowed by a sandbox controlled process. The same restrictions are inherited by these subprocesses, so certain flashbased programs or java programs might break since they might require additional system access, e.g. writing certain files.
For IronFox that should be:
- netstat, since that is used as a source for entropy. Removing that ability will probably render a situation where less entropy is collected and we have broken the crypto security.
We seriously consider this a bug in the firefox implementation for MacOSX. The operating system provides /dev/random and /dev/urandom, but obviously firefox uses this weird netstat output as antrophy anyway.
This also highlights some of the problems with doing our approach to 3rd party sandboxing. If we not had have the opportunity to check the NSS library source code, we would probably had denied netstat to run, and thus probably robbed firefox its source for entrophy.
Interprocess communication
Unix signals are normally allowed only to be sent from the process to itself.
Lots of communication is happening with the MACH subsystem. This is because apple have several interacting subsystem and service functions that all need to cooperate that way, e.g. font handling, cut-and-paste functionality, language support, sound and multimedia support, etc.
Network access
For programs not needing network access, no incoming or outgoing network access should be allowed.
For processes needing inbound network traffic, only well-known network ports should be allowed.
For processes needing outbound network traffic, only well-known network ports should be allowed.
Shared sandbox profiles
When a generic sandbox profile is used for inclusion by other profiles, the definitions and controls used there should be as restrictive, not permissive, as possible. At ROMAB we try to find common policy code segments and extract them to a file containing common profile rules that can be shared between the different tools we harden.
Performance
We believe that there is little or no performance penalty for running programs in sandbox. The text file containing the is compiled into a binary format when a profile is used the first time. This binary is then saved and cached for efficient handling by the operating system.
Logging, debuging and customizations
The sandbox protected tools will normaly log any policy violations to the normal system log (/var/log/system.log) with all violations getting the "sandboxd" prefix.
Jun 15 14:04:48 mbp sandboxd[5126]: Adium(5282) deny file-read-metadata /Users
To debug any problems with IronSuite protected applications, start to examine the system log file, for example by filtering out the last blocked system calls.
tail -100 -f /var/log/system.log | grep sandboxd
Please be vary that the log file will most certainly show several lines of logs with error messages. Several of those blocked system calls, e.g. file access that we have analysed and considered non essential. Ergo, the log file can be noisy and filled with crap.
To debug one of our sandboxes, start it directly from the command line with the command sandbox-exec with the appropriate options. Plese note that sandbox-exec is very picky. One have to give a complete and absolute path to the sandbox profile and the executed binary!
$ sandbox-exec -f `pwd`/Safari5-policy.sb /Applications/Safari.app/Contents/MacOS/Safari
We are very interested in any comments, bug reports, extensions and enhancements that you or someone else might create. please send those to:
ironsuite-bugs@romab.com
Users of the IronSuite should be able to customizations from the release, e.g. if someone wants to use an addon that we have not used or tested when we developed the initial sandbox profile.
The way to do customizations is simple: running the program, using that extra feature, examine the logfile, update the rule set, rinse and repeat.
This is also why we use the 2 clause BSD license, if someone want to release their stuff to the world. We would certainly appretiate if people would mail us their customisations, and we might be able to redistribute them.