Search the Community

OVERVIEW ========== The 4/8/2015 security updates from Apple included a patch for a Safari cross-domain vulnerability. An attacker could create web content which, when viewed by a target user, bypasses some of the normal cross-domain restrictions to access or modify HTTP cookies belonging to any website. Most websites which allow user logins store their authentication information (usually session keys) in cookies. Access to these cookies would allow hijacking authenticated sessions. Cookies can also contain other sensitive information. All tested Safari versions on iOS, OS X, and Windows were vulnerable. The number of affected devices may be of the order of 1 billion. Technically, the attacker can spoof the âdocument.domainâ property. Itâs possible that this could lead to compromise of other resources apart from cookies. However, cookies was the only practical attack scenario found with the tested versions of Safari. The HttpOnly and Secure cookie flags represent an important mitigating factor albeit with some caveats (see below). DETAILS ======== Safari supports the FTP URL scheme allowing HTML documents to be accessed via URLs beginning with "ftp://". These URLs can be of the form [url]ftp://user:password@host/path[/url]. The problem arises when encoded special characters are used in the user or password parts. Consider the following URL: [url]ftp://user%40attacker.com%2Fexploit.html%23@apple.com/[/url] If correctly interpreted, the URL refers to a document on apple.com. However, when loaded by a vulnerable browser, the network layer uses an extraneously decoded version of the URL: [url]ftp://user@attacker.com/exploit.html#apple.com/[/url] The document would be loaded from attacker.com, not apple.com. Yet the document properties such as âdocument.domainâ and âdocument.cookieâ are correctly initialised using âapple.comâ. The attacker-supplied document, exploit.html, can therefore access and modify cookies belonging to apple.com via JavaScript. Itâs possible that cookies arenât the only resource accessible this way, but at least recent Safari versions (tested desktop only) use the document origin instead of only host or domain for most other access control, e.g. password autofilling and geolocation permissions. The attack can be performed on normal web pages by embedding an IFRAME pointing to an FTP URL. MITIGATING FACTORS =================== The cookie attack requires JavaScript so existing cookies with the HttpOnly flag canât be seen by the attacker. Support for this flag reportedly appeared in Safari 4. Earlier versions would be vulnerable even with the HttpOnly flag. Safari allows (over)writing of HttpOnly cookies so the flag doesnât prevent this vulnerability to be exploited for session fixation and similar attacks. Cookies with the Secure flag arenât accessible for documents loaded via FTP. VULNERABLE VERSIONS ===================== The following versions were tested and found vulnerable: - Safari 7.0.4 on OS X 10.9.3 - Safari on iPhone 3GS, iOS 6.1.6 - Safari on iOS 8.1 simulator - Safari 5.1.7 on Windows 8.1 Earlier versions werenât available for testing, but according to available statistics their usage should be negligible. SOLUTION ========= Apple was notified on January 27, 2015. The following patches were released in April 2015: - APPLE-SA-2015-04-08-3 iOS 8.3 - iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later - APPLE-SA-2015-04-08-1 Safari 8.0.5, Safari 7.1.5, and Safari 6.2.5 - OS X Mountain Lion, Mavericks, Yosemite For more information see: [url]https://support.apple.com/en-us/HT201222[/url] WORKAROUND ============= The attacker has to set up an FTP server or use an existing public one. Such server can run on any TCP/IP port number. One way to stop such attacks (e.g. for older devices with no available patch) would be to deny all traffic to the public internet and configure the device to use a HTTP proxy located in the internal network. This should prevent access to all FTP URLs. CREDITS ======== The vulnerability was found and researched by Jouko Pynn??nen of Klikki Oy, Finland. -- Jouko Pynnonen <jouko@iki.fi> Klikki Oy - [url=http://klikki.fi]Klikki Oy -[/url] - @klikkioy Source: http://packetstorm.wowhacker.com/1504-exploits/safari-crossdomain.txt

Apple on Tuesday pushed out new versions of its Safari browser that address 17 security vulnerabilities in the WebKit engine. Safari 8.04, 7.14 and 6.24 patch multiple memory corruption issues in WebKit, Apple said. “These issues were addressed through improved memory handling,” Apple said in its advisory. The advisory is sparse in other details on individual CVEs; Apple said that users visiting a website hosting an exploit could put the browser at risk to remote code execution or a crash. A separate WebKit vulnerability affects the user interface and could open the door to phishing attacks. “A user interface inconsistency existed in Safari that allowed an attacker to misrepresent the URL,” Apple said. “This issue was addressed through improved user interface consistency checks.” This is the second set of Apple patches in the last 10 days. The company took care of the FREAK vulnerability in iOS along with another vulnerability that would allow a hacker to remotely restart a user’s phone via a SMS message. Apple iOS 8.2 also patched a vulnerability in the iCloud keychain function that was the result of several buffer overflows. Source

And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded. WebAIM: In the beginning there was NCSA Mosaic...