Safari RSS vulnerability: what went wrong?
Last edited Thu, 12 Feb 2009
How I found the issue
To recap the issue, the version of Safari included with Leopard and the Windows version of Safari were vulnerable to an attack that would allow a malicious web page to read any file you had access to on your computer, and possibly to perform a cross-site scripting attack. This issue was caused by a design error in the RSS feed reader built in to Safari that treated some remote content as if it were loaded from the local computer, thus granting it access to the local filesystem. Specifically, when trying to load a feed which does not exist on the server (404), the web page which is returned is loaded in the local security zone. To exploit this issue, an attacker would configure a web server to return a page containing malicious code when a nonexistent page is requested. The ability to configure this page is a standard feature of web servers, and does not require a significant degree of technical sophistication.
This issue could have been exploited by the malicious developers who construct phishing web sites. Many sites store login cookies on the hard drive so that the login information persists even if the browser is restarted. This issue would have allowed a web site to steal this cookie without tricking the user into giving up any information. Merely clicking on a link would be sufficient.
I discovered this issue quite accidentally while testing a RSS feed. During my testing, I reloaded the feed in Safari after mistakenly removing it from the web server. I immediately noticed that the page which was returned did not appear as it should. For example, here's how Apple's "page not found" site renders normally:
And here's how it appears when loaded as a RSS feed:
The page appears different when loaded as a feed because the image and style resources used to build the page can't be found. When I looked into why that was (assuming a misconfiguration on my server), I was surprised to discover that it was actually searching for them on my local computer.
A six-month delay
Once I discovered the issue, I promptly reported it to Apple, including a proof of concept which demonstrated reading a local file. This issue was reported on July 11, 2008. After six months passed without a fix, I decided to post a warning on January 11, 2009, due to my judgement that this issue could be exploited at any time as long as it remains unfixed.
Many vulnerabilities rely on attack mechanisms which require a fair amount of technical sophistication on the part of the attacker. Vulnerabilities in this class, such as buffer overflow exploits, are tricky to exploit and have been mitigated through improvements to the design of operating systems. Because they are very specific to the version of software being targeted, the same attack is unlikely to work on a Leopard system on a PowerPC processor, a Leopard system with an Intel processor, and a Windows system with an Intel processor.
By contrast, this vulnerability works in exactly the same way on all affected platforms, and does not require intricate knowledge of the processor or operating system to exploit. I discovered it accidentally, which indicates that this issue could also be discovered by others. These two factors should have indicated to Apple that this vulnerability carried a high risk.
So why did it take seven months for Apple to deliver a fix? What does this say about Apple's commitment to protecting the security of its users? Neither I nor anyone else who is not at Apple can answer these questions for certain. However, I can illustrate the degree of the issues Apple faces with securing its products.
Should users of Leopard feel more secure than Windows users?
From October 26, 2007 (Leopard's release date) until at least March 18, 2008 (Security Update 2008-002), users of Leopard were vulnerable to a combination of attacks that would allow a malicious web page to take full control over a victim's computer. Like the Safari issue patched today, these potential attacks do not rely on buffer overflow-style exploits, but are a result of errors in the design and implementation of the operating system, involving multiple different components.
These vulnerabilities could have been used to construct a virus that would spread automatically via local networks, including corporate networks and open WiFi hotspots. Unlike a trojan attack, the user does not need to be tricked into executing a malicious program for this attack to spread. Users would be infected simply by opening up Safari and loading their home page while connected to the same network as an infected computer.
In order to take complete control of a victim's computer from a malicious page, two different vulnerabilities must be exploited in tandem: one which allows the page to execute code as if it were the user logged in to the computer, and another which allows that code to obtain administrator-level permissions on that computer. An vulnerability present in Leopard and not fixed until Security Update 2008-002 allows a malicious web page to execute code as the local user by exploiting an implementation error in Apple's help viewer. The second part of this attack could have been provided in the form of the widely-publicized ARDAgent security problem.
In order to turn this exploit into a virus, the malicious program would use a trick which should be familiar to users of open WiFi hotspots. Many such hotspots are configured so that users who have not registered are redirected to a page to sign in to the access point. When a user attempts to open their home page, the hotspot intercepts the request and instead returns a page of its own choosing. Unfortunately, the ability to do so is not restricted to the hotspot itself, and any other computer connected to the access point can also intercept web page requests and replace them with content of their own choosing, using the same mechanisms that the access point itself would use. When a victim connects to a network, the infected computer would respond as if it is the access point by providing an IP address, router address, and list of name servers. The victim's computer will then attempt to load a web page using the information given to it by the infected computer, and will receive the malicious web page instead of the intended content.
I've brought up this possibility to illustrate the harm that could result from the issues I've seen in OS X. This potential attack carries some worrisome implications for the security of Apple's software. It indicates that better design or security measures built in to UNIX are not responsible for the relative lack of attacks against OS X when compared to Windows (nor is more responsive patching of issues as they are reported). While the specific vulnerabilities I am aware of which could be used to trigger this attack have been closed, any other two vulnerabilities which provide local execution and escalation-of-privileges can be used to build this virus. In fact, an escalation-of-privileges vulnerability is not strictly required to build this virus, as it is also possible for a malicious program running as an ordinary user account to obtain superuser-level access by hijacking programs such as Software Update and System Preferences which prompt the user for administrative credentials. (Apple does not consider this to be a security issue.)
The security sword of Damocles
The most worrisome implication is for Apple itself. If Apple's products were widely perceived to be just as insecure as Microsoft's, a significant amount of the goodwill the company has accumulated since the introduction of OS X would be erased. A basic mistrust of the ability of Windows-based computers to protect users' privacy and security now pervades the industry, and security software vendors such as Symantec and McAfee have capitalized on this. Apple is no less a beneficiary, as many of the issues which user commonly have with their computers can be traced to the prevalence of spyware and malware on the Windows platform.
If a virus of the kind I've described here were to be released, it would spread rapidly through organizations with a high concentration of Mac users, especially academic institutions and possibly even through Apple itself. If it were to infect Apple's own computers, their own intellectual property would be at risk. In short, these issues pose a substantial threat to Apple's accumulated goodwill (which at the end of Q1'09 totaled $207 million).
If you had $207 million in assets, how would you insure them? If you found the bank vault which is supposed to protect these assets left wide open, yet nothing was stolen, how seriously would you address the issues which allowed the vault to be left open in the first place?
The issues I reported that allowed execution of arbitrary code from the web browser were fixed in early 2008. Each one of these is tantamount to finding that bank vault door left open. Apple should have immediately corrected the processes that allowed these problems to ship in the first place, and placed substantial effort on ensuring that future issues would be corrected as soon as possible so as to minimize the chance of exploitation.
They did not. It took seven months for Apple to patch this latest vulnerability in Safari, despite numerous opportunities for it to be addressed in updates that were already scheduled.
What could be done?
If the product is broken, the process which produced it is broken. Apple must improve its process in order to prevent issues like these from becoming exploited vulnerabilities. There are three areas where I can observe a process failure that allows these problems to occur:
- Prioritization: Apple allowed this issue to remain unfixed while spending engineering resources working on features for the upcoming Safari 4. This indicates that there are systemic problems in the prioritization of software security defects. The product team responsible for the affected component must ensure that the security of existing, shipped software is addressed before features of the next version of the software. An independent security software team must independently audit the progress of security fixes in case the product team overlooks the importance of an issue, and management must allow the security team to override the schedule of the product team if progress is not being made on security issues. Issues which have not yet been made public by the reporter should be examined to determine the likelihood that they could be independently discovered by those with malicious intentions, and issues should not be allowed to slip because they have not yet been publicly exposed.
- Review: Independent security experts must be involved in reviewing the design of almost any component that processes information obtained from the network, and changes to this design must be audited as well. These security experts must also be given a significant amount of resources to conduct undirected exploration of the vulnerability space in both shipping and in-development software. I am not a full-time security expert, and the amount of time I've spent on these issues amounts to a few hours per month at most. Dedicated auditing would be able to find the problems I've reported and many more. If auditing is continually revealing problems, more resources should be added until efficacy drops.
- Design: I've been assured that Apple is incorporating significant improvements in security design in future operating systems. I've no way to evaluate this at the moment. Better educating engineers about how to design for security should be a component of design improvements. Engineers should ask themselves the questions that a security design audit would cover when planning components, and all engineers should be encouraged to think like an attacker and find issues in their software.
OS X users are at this point in the unenviable situation of hoping that Apple starts taking these issues more seriously before phishing exploits, drive-by malware, and viruses become widespread on the platform. There is little preventing that at the moment, and little users can do to protect themselves, other than to encourage Apple to address these issues at every opportunity.
Apple shareholders should demand that more effort be spent to address these issues in order to safeguard the company's value. I think many shareholders would be surprised if Apple suddenly started receiving bad press due to poor software security. At this point, I can only hope that Apple decides to take action before that happens.