Brian Mastenbrook

Financial incentives for Mac malware

Sat, 26 Sep 2009 21:36:09 GMT

Apple's days of flying under the radar are over: there are now serious financial incentives for Mac malware. These incentives will spur development of drive-by malware as it's significantly more effective than trojans. OS X does not provide sufficient defenses against browser-based threats: I've found too many issues that could be used for drive-by malware installation just through simple logic errors that should have been flagged in code review.

If you're a researcher and would like to see where the problem areas, I wrote up a guide to finding issues on OS X earlier this year. Everything listed in this article is still applicable on Snow Leopard.

Regarding 37signals and communication

Wed, 09 Sep 2009 22:53:21 GMT

37signals has responded to my original post regarding the cross-site scripting security issue I brought to their attention last month. I'm genuinely pleased to see that they are making changes in their communications process as a result of this issue. I am, however, disappointed that they have labeled the entire issue as a communications problem.

A mindset problem was at work which goes much beyond communications. In all of the time that 37signals has been in business, nobody had given thought to the idea that there should be a dedicated security contact process, or that it was inappropriate (even deceitful) to make blanket promises of data security. A failure of inaction like this always has two causes. The proximate cause, and the easiest answer to give, is that it was just a mistake: a detail overlooked in the daily scramble of business. The hard answer to give (and to accept) is that nobody thought there was a problem.

There is a neat symmetry: just as it can only take one major exploited vulnerability to utterly destroy users' trust in a company, it only takes one person who is utterly devoted to the issue of security to spot a fundamental process problem. There was no such person at 37signals when I contacted them about a security issue in their applications.

At its core, good security starts and ends with a vow to take the security of the user personally. What I saw from my own experience and the experience of other researchers convinced me that this commitment had not yet been made by 37signals. I fear that in characterizing the issue as one of communications, this larger point has been lost.

I would like challenge 37signals to publicly pledge to become the unquestioned industry leaders in cloud application security. The commitment to lead is the only method by which you can truthfully state that you are doing all that you can to fulfill your obligations to your users. It is a difficult but attainable goal, and one which will pay dividends in trust.

There is one another detail which has not yet been completely addressed. I have not yet been able to account for what happened to the originals of the emails that were re-sent to me on August 13th by 37signals support. For my peace of mind, I hope that this issue will be laid to rest soon.

How I cross-site scripted Twitter in 15 minutes, and why you shouldn't store important data on 37signals' applications

Thu, 03 Sep 2009 23:52:30 GMT

Today the Ruby on Rails security team released a patch for a cross-site scripting issue which affected multiple high-profile applications, including Twitter and Basecamp. If you're concerned about the issue and would like to see the patch, please read the advisory from the Rails security team. In this post, I discuss the overall process of finding the issue, and the reason why I'd suggest that no important information be stored on the 37signals applications (Basecamp, Highrise, Backpack, and Campfire).

Finding software security issues is a creative art. With multiple layers of stacks and protocols combining to form a single application, finding an issue requires seeing which layers and components can be mixed together to create a behavior not originally intended by the program's designer. Sometimes, inspiration strikes and the pieces fall into place quickly. After seeing a bug in Unicode handling in an unrelated program a few weeks ago, I suddenly had an idea: "I wonder if there are any web applications which have Unicode handling problems that might be security issues?"

My attention quickly turned to Twitter, the only web application I had open at that moment. A few minutes later, I had JavaScript from a URL query parameter falling through the escaping routines and running in the main body of twitter.com. Bingo! Cross-site scripting, the stuff that Twitter worms are made of. But was this a Twitter-specific issue, or did it affect other sites too?

I quickly pulled up a test Basecamp account I had made a while ago. Basecamp, like Twitter, uses Ruby on Rails for its web frontend, so this would be a good way to determine whether the issue was in Rails or if it was specific to Twitter. Sure enough, the same malformed UTF-8 sequence that worked on Twitter also worked on Basecamp.

At this point I was nearly convinced that the issue affected all Ruby on Rails applications, so I pulled up a demo Rails application I had lying around my sandbox and constructed a malicious URL for that application. Lo and behold, it did not work! Nor did several other Ruby on Rails sites, including the official Rails site.

Now thoroughly confused, I decided to send the issue to Twitter and 37signals, the company that makes Basecamp, to see if they could determine where the issue was actually coming from. Not being familiar with the Rails framework myself, I figured it would be more efficient to enlist the developers of the applications I knew to be vulnerable to help root cause the issue - especially if it was ultimately caused by a different library or component that both sites happened to share.

That's where the fun began. Most traditional application vendors - especially vendors of large, high-profile applications - have dedicated security contact information which comes up within the first few hits for " security" on Google. This information usually explains the policies that the vendor follows for working with researchers and gives an email address and PGP public key that can be used to contact the security research team directly. Apple, Microsoft, and Google each have good examples of this type of page. There are two very good reasons why these companies all post detailed, easy-to-find contact instructions for security researchers that bypass the usual customer support queues:

The information that a security researcher has to share is likely to be important, and affect many if not all of the users of the company's products, and
Responsible disclosure is a public service; it pays to make it as easy as possible for researchers to inform you of an issue before going public.

It took a fair amount of effort to find Twitter's page, but that wasn't helped by the overwhelming number of results for any Google search involving "Twitter". (The GPG public key listed on that contact page has appeared since I reported the issue.)

37signals was a different matter. They had a security page all right, but it didn't have any contact information for researchers. (That information has since been added to the page.) They helpfully suggested that if I had any questions about how their wonderful security allowed them to make claims like "Your data won't be compromised", I could file a support ticket - into the same queue where all customer support requests go. They promise to handle all requests within a few hours, so I filed it anyway.

After a few days of not receiving a response from either vendor, I decided to ping both of them to get an update. I pinged a security researcher who I knew worked at Twitter, and after a little back and forth things were quickly resolved and Twitter was patched. When it was done, I replied to an email from Jay Edwards and suggested making the security contact page easier to find and including a GPG key, the latter of which has now been done. Overall the process of working with Twitter was smooth, and the issue was fixed quickly.

37signals was a different matter. I asked them if they had a dedicated security contact address, and was told to use the support form. I replied that I had and once again asked for a direct contact, and was now told to check my spambox. A quick grep of my postfix logs showed that there had been no contact attempts from 37signals' mail servers since I submitted the issue, so I was now a little bit peeved. This netted a brief response: "I've resent my email to you." Sure enough, two emails then arrived in my inbox with the first line on each indicating they were being resent, but without any information on the date and time when the originals were sent. I replied and asked for that information to determine if my mail server was dropping mail without my knowledge, but I haven't heard anything since then.

What 37signals said in their email is that the issue was indeed a Ruby on Rails issue, and so I should contact the Rails security team to resolve the issue. This is what I was looking for from the beginning, so I sent a mail off to the Rails team with as much information as I could. Despite the fact that I couldn't provide a complete reduction of the issue, the Rails team was able to root-cause the issue and come up with a patch. Michael Koziarski was my main contact on this issue and did an excellent job of keeping me informed of the progress of the issue and the patch. The Rails security process was pleasant for me to work with as a researcher, and I'd like to thank Michael and everyone involved in putting together the patch.

One surprise I discovered during the process was that IE8 includes a Cross Site Scripting filter which effectively blocked this attack. I'm very impressed with the effort that Microsoft's taken to mitigate one of the most common web application security issues. Every other browser vendor needs to add this functionality yesterday.

Web application security is still an immature field, and many of the layers are sufficiently poorly designed that issues like this will pop up for a good long while. Just like buffer overflows have been a weak spot for C security as long as the Internet has been around, escaping issues will continue to be a weak spot for web security for as long as we're afflicted with this particular architecture. Web application vendors can do more to protect their users. There's no reason why the same filtering technology used in IE8 on the client side can't be used on the server side to protect against these simple type-1 XSS attacks, and even more complex reflected attacks could be caught by a signature-based database. At least one vendor claims to have a firewall that will filter out XSS attacks; I wouldn't be surprised to see more entrants in this space soon.

Winners: Ruby on Rails, Microsoft, Twitter
Loser: 37signals

As I mentioned in the intro, I don't think it's a wise idea to store important information on the 37signals suite of web applications. My experience working with them on this issue was so thoroughly poor that I am convinced that they can't be trusted with any data of mine. The grandiose claims made on their security page are simply factually incorrect. Your data can be compromised, and you can lose important data, and there might not be anything that 37signals can do about it if their upstream vendor's software is vulnerable or your browser is vulnerable. 37signals' confidence in their security was so complete that they didn't even bother to list a dedicated security contact. I'm not the only researcher to have issues with the 37signals security contact process recently either. They've since rectified this issue, but simply adding a contact address in response to a few researchers complaining won't change the attitudinal problem. 37signals seems to believe that its security is beyond reproach, and until they publicly commit to a robust security process and drop the self-congratulatory statements on security, I won't believe that they're following a process which will protect my data at least as well as I protect it.

If you've installed Snow Leopard and your fonts are fuzzy, clap your hands

Fri, 28 Aug 2009 20:11:04 GMT

Users of third-party monitors who are performing a fresh install of Snow Leopard may notice a preference that's missing. Ever since Apple first implemented subpixel font antialiasing in Jaguar, there's been an option to adjust the style of antialiasing used on your monitor. If OS X couldn't determine that your third-party monitor was a LCD monitor, you could still set the kind of antialiasing used manually.

That control has been removed in Snow Leopard. The only option now is labeled "Use LCD font smoothing when available", but the definition of "available" doesn't include the majority of LCDs on the market. Users who upgrade from a 10.5 install will keep their setting (as far as I can tell), but new users or fresh installs will revert back to the default grayscale-only antialiasing.

Fortunately there's a workaround. Just open up Terminal and run the following command:

defaults -currentHost write -globalDomain AppleFontSmoothing -int 2

If you used the "weak" setting on Leopard, replace the last number with 1; if you used the "strong" setting, that'd be a 3. Then log out and log in again for the setting to take effect. When you look at the Appearance preferences now, you'll see a checkbox in indeterminate state like this:

That's what it should look like; don't touch it!

It's More Fun To Compute

Wed, 12 Aug 2009 02:03:01 GMT

Steven Frank posts about a reply from Phil Schiller about the iPhone developer program and his self-imposed iPhone boycott. Phil promises that they're working on the issues Steven raised, and his recent communication with influential technical bloggers shows that Apple is serious about changing people's perception. The problem is that the approval process won't ever be good enough.

It's ironic that the company that "ignited the personal computer revolution in the 1970s with the Apple II" would also make the first touchscreen device I've owned that isn't programmable. Over the past decade I've always had a programmable computer that I could carry almost anywhere. My Pilot Pro with cBasPad was followed by a sequence of ever more powerful devices and more interesting programming languages. I'm now carrying a T-Mobile G1 (HTC Dream) with Google's own Android Scripting Environment. Each of these devices has allowed me to relive the simple joy I discovered long ago on an Apple IIc in solving problems by writing software.

My iPod touch has better software and hardware than any of the other portable devices I've owned in almost every way. It's smaller, faster, smoother, and generally put together with more thought and care. It's not perfect, but I like it quite a lot. It's the best portable music player I've ever owned. But it still couldn't replace the Pilot Pro I owned ten years ago.

Apple is so committed to the idea of controlling my experience on the iPhone OS platform that it's unwilling to allow me to create my own experiences on the device. It doesn't matter to me if they're going to be more open or less arbitrary about the app approval process in the future. It still won't compute.

A Guide to Finding Security Problems on OS X

Wed, 03 Jun 2009 20:33:04 GMT

Note: this is recapped from a conversation I had with Landon Fuller about how to find security vulnerabilities on OS X.

I use Mac OS X, Windows, and Linux on various different laptop and desktop computers, but most of my time is spent on Mac OS X owing mostly to some Mac-specific programs I frequently use. This doesn't bother me as OS X is a very pleasant environment to spend my time in. However, I am distressed by the security weaknesses of OS X as a desktop computing environment, especially with how poorly Apple seems to handle these issues.

I've reported a number of issues to Apple so far. Generally I can find an issue within a few hours of searching for a problem, and most of the problems I've found are design flaws which should have been caught with even a cursory security-focused review. However, I've very little time to spend on this. While I'd prefer that Apple allocate more resources in this direction, it would certainly help if more people were searching for issues to report.

With that in mind, here are some focus areas for those who would be interested in finding issues in desktop OS X. I'm sure there are hot spots in OS X Server as well, but I'm not generally too interested in that area as OS X is still very uncommon as a server operating system and many of the issues would be shared with other UNIX-like operating systems. Because the common open source server applications have already received a great amount of attention, there's a lot less low-hanging fruit than in the area of desktop security.

There are two major areas of desktop OS X security which I believe deserve major focus. One is network-based attacks that can make use of applications like Safari to execute arbitrary code. The other is in escalation-of-privileges vulnerabilities which can be combined with network-based attacks to turn a trojan or worm into an automatically-spreading virus.

In the area of network-based attacks, here are some focus areas I think should be investigated:

Problems that allow an arbitrary file on the victim's computer to be opened via the Finder, combined with a file type containing executable content which is not specifically excluded by the quarantine blacklist. The quarantine file type blacklist is far from complete and will never be complete so long as it's an explicit exclusion list. You can find the list of excluded types and extensions at /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/System. Arbitrary files can be placed in predictable locations on the victim's file system using either disk images or remote filesystem URLs (afp, ftp, smb).
URL scheme problems. Safari opens other applications via URL schemes without applications, and most of the system applications haven't received anything resembling a thorough scrubbing. When issues are fixed, they tend not to get fixed all the way. I've reported issues in the Help Viewer application three times already, and it's still not completely fixed. To see the list of registered URL handlers, install RCDefaultApp.
Any problem involving a "safe" file type that Safari will automatically open after downloading. The list of "safe" file types is in the same file as the quarantine blacklist.
Problems where non-SSL content from apple.com or other domains is assumed to be trusted, which can lead to a variety of problems. There's no such thing as a trusted network, especially given how common unsecured WiFi access points are. Even on a supposedly secure network, if a virus manages to gain root through an escalation-of-privileges problem, it can easily set itself up as a DNS server and router to intercept requests from other systems on the network. This area is particularly ill-explored in my opinion.

Escalation-of-privileges vulnerabilities haven't been an area of focus to me, mostly because it would likely take more than a few hours to find an issue here. Nonetheless I think there are some promising areas for these kinds of issues:

Privileges problems. Historically, "donating" files to another user was not allowed on UNIX-like operating systems, but OS X users may create files and directories owned by another user via disk image mounting, and these files may be created in any folder that the user owns via union mounts. The system ignores devices in mounted disk images and the suid/setgid bits on files, but I'm still convinced there's at least one issue lurking here. One approach would be to find a way to make a process running as root move or copy a file outside the union mount, which would allow the suid bit to work on the root-owned file.
Suid binaries shipped with the system have likely not been thoroughly validated. The ARDAgent problem demonstrates that there are large gaps in the process for reviewing what suid-root binaries are allowed to do. Finding a problem here would be tedious, but should be straightforward. For reference, the list of suid binaries installed can be obtained with find / -perm +4000 -print.
Authorization Services. It's complicated and is designed to allow ordinary users to make settings changes like choosing the active WiFi SSID without having to authenticate multiple times. I already know that the authentication prompts can be hijacked silently by another process running as a user, but I'm convinced there's at least one issue lurking in one of the programs that uses Authorization Services that would allow a user process to gain root without waiting for a prompt (System Preferences being a likely culprit).

If you're going to search for issues, please practice responsible disclosure, either by reporting issues directly to Apple or through VeriSign's iDefense VCP or 3com's Zero Day Initiative.

Happy hunting!

Safari: Swiss Cheese of the Internet

Tue, 19 May 2009 17:01:51 GMT

Landon Fuller posts a proof of concept attack using a publicly-disclosed Java applet vulnerability that hasn't been fixed on OS X.

Security is pretty much an all-or-nothing game. If there's a way in, you're insecure, and fixing all but one of the problems doesn't address the issue. Of course not every bug is created equal: some issues only let attackers go so far, while others allow full, arbitrary code execution. The easier it is to exploit a vulnerability, the worse it is. In this case, the ease of exploitation is very high due to the already released public details of the issue. It's also a logic error involving sandboxing, which makes it easier to exploit on all affected OS versions and processors than a buffer overflow vulnerability.

Browser-based vulnerabilities are particularly insidious because the browser is such a ubiquitous environment. Users visit untrusted pages with the confidence that they are protected from malicious content, but this confidence is misplaced. Visiting only trusted pages isn't an option either. Trusted web sites can be attacked and turned into infection-spreading vectors. Requests for trusted pages can be redirected by other systems on the local network as well.

The distressing fact is that users of OS X who browse with Safari have been vulnerable to browser-based arbitrary code exploits since the very first release of Safari in 2003. Several of these vulnerabilities have been slight variants of issues that Apple even attempted to fix. Naive design and poor testing is to blame. Apple has to start taking these issues seriously. That means fixing reported issues promptly before working on next-generation product features. It also means incentivizing researchers to report issues directly to Apple.

One of these days, someone will fall for the temptation to turn one of these exploits into a virus. It's simply too easy. There are no countermeasures built into the operating system, and it's easy enough to gain root access by hijacking calls to the authorization API (this isn't a security problem, according to Apple). Just add a rogue DHCP server that acts like the captive portals which are commonly found on open wireless networks, and any browser-based issue becomes a virus.

When that happens, short AAPL.

Security, safety, and scruples

Fri, 15 May 2009 00:47:09 GMT

John Gruber:

But it rings untrue to most ears to claim that Apple is doing a bad job with regard to security. The evidence suggests that Mac OS X has been and remains secure enough to be safe, and safety is what real people actually care about.

I'd dispute the idea that Apple isn't doing a bad job with regard to security. It remains a mystery to me why OS X is a relatively safe platform. To put it bluntly, it wouldn't be a very safe system if I didn't want it to be. It's hard not to see that situation changing when I know very well that there are people who are just as intelligent and capable as I am who are substantially less scrupulous.

Security Update 2009-002 / Mac OS X v10.5.7

Tue, 12 May 2009 21:41:21 GMT

Security Update 2009-002 / Mac OS X v10.5.7 is now available from Apple for users of OS X 10.4 and 10.5. Two closely-related issues I reported have been addressed in this release:

Help Viewer
CVE-ID: CVE-2009-0942
Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5 through v10.5.6, Mac OS X Server v10.5 through v10.5.6
Impact: Accessing a maliciously crafted "help:" URL may lead to arbitrary code execution
Description: Help Viewer loads Cascading Style Sheets referenced in URL parameters without validating that the referenced style sheets are located within a registered help book. A malicious "help:" URL may be used to invoke arbitrary AppleScript files, which may lead to arbitrary code execution. This update addresses the issue through improved validation of file system paths when loading stylesheets. Credit to Brian Mastenbrook for reporting this issue.
Help Viewer
CVE-ID: CVE-2009-0943
Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5 through v10.5.6, Mac OS X Server v10.5 through v10.5.6
Impact: Accessing a maliciously crafted "help:" URL may lead to arbitrary code execution
Description: Help Viewer does not validate that full paths to HTML documents are within registered help books. A malicious "help:" URL may be used to invoke arbitrary AppleScript files, which may lead to arbitrary code execution. This update addresses the issue through improved validation of "help:" URLs. Credit to Brian Mastenbrook for reporting this issue.

Both of these issues are slight variants on an issue that was originally fixed in Security Update 2004-05-24 for OS X 10.2 and 10.3. While that update addressed the symptom of the issue, it did not fully address the root cause. The Help Viewer application includes a URL scheme "help:" which may be used to open help pages from other applications, including Safari. This URL scheme originally allowed any application to use the "help:runscript" form of the URL to invoke an arbitrary AppleScript on the user's filesystem. Security Update 2004-05-24 changed Help Viewer so that only the Help Viewer application itself could use the "help:runscript" URL to invoke a script.

However, several other forms of the URL could still be invoked by Safari, and it was possible through the use of a file on the user's computer to redirect Help Viewer to a "help:runscript" URL. In combination with a download that placed a stylesheet or HTML file and an AppleScript file on the user's computer, this could be used to execute arbitrary AppleScript code on a victim's computer without any prompting.

This issue affects users of OS X 10.2 or later. Apple does not issue security updates for operating systems earlier than 10.4. I would strongly advise users of earlier versions to upgrade or discontinue use of the operating system as enough information is available in Apple's release note for attackers to construct a malicious web site which takes control of victims' computers.

Running the Safari 4 Beta without replacing Safari 3 on Leopard

Thu, 26 Feb 2009 01:46:33 GMT

I've whipped up a script which extracts a version of the Safari 4 Beta for Leopard from the installation image so that it can be run without replacing Safari 3. This is a quick and dirty hack, so there are no guarantees that it will work. If it breaks, you get to keep both pieces.

All of the new libraries that Safari 4 depends on are placed in the application by the installer script. The Safari 4 beta installs a new version of a program (pubsub) that multiple components of the operating system depend on for RSS feed reading. It seems to run without this new version, but you encounter find bugs, crashes, missing features, and kittens when using RSS feeds. This script only works with the Leopard version of the Safari 4 Beta.

To use the script:

Download and extract the script zip file.
Copy Safari4.0BetaLeo.pkg from the Safari 4 beta download to the extracted directory.
Open the script named Create side-by-side Safari 4 Beta app.
A Safari 4 Beta application should be created in the script directory. Move this to wherever you'd like to keep it.

Safari RSS vulnerability: what went wrong?

Thu, 12 Feb 2009 13:47:06 GMT

Apple today released Security Update 2009-001 to address the security issue in Safari which I wrote about last month. Now that the patch is available, I'd like to share a bit more about the problem and why I decided to issue a warning. I'd also like to share a bit more about the security challenges Apple is facing, and how it may not be meeting those challenges.

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.

Disclosure of information vulnerability in Safari

Mon, 12 Jan 2009 01:56:39 GMT

Note: This issue has been addressed by Apple Security Update 2009-001. All users of Leopard and of Safari on Windows should install this update immediately. An explanation of the issue is available here. The information that follows is of historical interest only.

I have discovered that Apple's Safari browser is vulnerable to an attack that allows a malicious web site to read files on a user's hard drive without user intervention. This can be used to gain access to sensitive information stored on the user's computer, such as emails, passwords, or cookies that could be used to gain access to the user's accounts on some web sites. The vulnerability has been acknowledged by Apple.

All users of Mac OS X 10.5 Leopard who have not performed the workaround steps listed below are affected, regardless of whether they use any RSS feeds. Users of previous versions of Mac OS X are not affected.

Users of Firefox, Camino, and Opera on Mac OS X are substantially better protected against exploitation by a malicious web page than users of Safari or OmniWeb. If users of these browsers are asked to open a link in Safari, they should not allow the request and close the page which triggered the request immediately. All users of Mac OS X may still be affected by clicking on a malicious link from their email client, instant messaging program, or another application, and should perform the workaround steps given below.

Users of Safari on Windows are also affected. Users who have Safari for Windows installed but do not use it for browsing are not affected.

The details of this vulnerability have not been made public to the best of my knowledge, but secrecy is no guarantee against a sufficiently motivated attacker.

To work around this issue until a fix is released by Apple, users should perform the following steps:

Download and install the RCDefaultApp preference pane, following the included instructions.
Open System Preferences and choose the Default Applications option.
Select the "URLs" tab in the window that appears.
Choose the "feed" URL type from the column on the left, and choose a different application or the "<disabled>" option.
Repeat the previous step for the "feeds" and "feedsearch" URL types.

The only workaround available for users of Safari on Windows is to use a different web browser.

Apple has not made information available on when a fix for this issue will be released. Users with questions or concerns should contact Apple as I have no additional information about this vulnerability which can be shared at this time.

For the curious, security issues in Mac OS X which I previously reported to Apple were fixed in Security Updates 2008-001, 2008-002, 2008-003, and 2008-004.

Replacing identifiers in an Emacs buffer

Sat, 10 Jan 2009 03:45:52 GMT

Recently I had a need to replace a large number of identifier names in a collection of source code without replacing other uses of those names in comments or string literals. Not finding a satisfactory solution, I decided to write one. It's based on an earlier function I wrote to do the same thing in Common Lisp code, but is generalized to work on any buffer for which the Emacs functions `forward-sexp', `backward-sexp', `down-list', and `backward-up-list' work properly. I've been using it today to rename types in C, and I'd expect that it'd work properly with most language modes.

If you have similar needs, you might find my ambitiously-named refactor.el to be useful!

SBCL 1.0.22

Fri, 31 Oct 2008 02:11:23 GMT

SBCL 1.0.22 has been released. I forgot to make an entry in the NEWS file for this, but with this release binaries which are built on OS X 10.5 (Leopard) should run on OS X 10.4 (Tiger). New binaries for 32- and 64-bit Intel systems as well as PowerPC systems are now available for download. The previous binary for PowerPC systems was well over a year old. I'll be keeping that binary more up to date from now on.

Those who want to use SBCL for delivering applications that accept arbitrary command-line arguments will appreciate Zach Beane's patch for saving runtime options in saved executables, which allows the SBCL runtime leave all command line argument processing to the toplevel. For details, see the NEWS.

For those who are interested in doing scripting with SBCL, there is a new --script argument for using SBCL as a #! interpreter. The documentation has not yet been updated on the web site, but some details are available on the SBCL mailing list.

paste.lisp.org CAPTCHA in acrylic

Mon, 19 May 2008 17:15:52 GMT

Becky Stern of the MAKE magazine blog recreates CAPTCHAs in acrylic. Her latest creation is the CAPTCHA I created for paste.lisp.org:

The CAPTCHA is done purely using DIVs and CSS2. The font is Chris Cannam's superb Codec monospace bitmap font, which I've used as an Emacs font for years. The code which creates the CAPTCHA can be viewed on paste.lisp.org.

The painting is for sale, if you've got the perfect place to hang a 5x7 acrylic painting of "lisp".

Public Service Announcement to Debian and Ubuntu Users

Tue, 13 May 2008 16:09:20 GMT

A weakness has been discovered in the random number generator used by OpenSSL on Debian and Ubuntu systems. As a result of this weakness, certain encryption keys are much more common than they should be, such that an attacker could guess the key through a brute-force attack given minimal knowledge of the system. This particularly affects the use of encryption keys in OpenSSH, OpenVPN and SSL certificates.

The fix involves updating your OpenSSL packages and regenerating any private keys made on recent versions of Debian (etch and newer) or Ubuntu (Feisty or later). For more information, see:

This issue was caused by a Debian-specific patch to OpenSSL and does not affect distributions which aren't derived from Debian.

MCL 5.2 has been released as open source

Fri, 21 Mar 2008 19:53:12 GMT

Digitool has released MCL 5.2 as open source. From the announcement:

MCL 5.2 is now available at:
ftp://ftp.clozure.com/pub/MCL/MCL-5.2-Final.dmg
It is open source. I am sorry that it does not run on Intel. I hope that some users will be able to find the resources for a port of MCL to Intel processors.
Please let me know of any questions or problems.

MCL is the distribution from which Clozure CL (nee OpenMCL) was derived. Clozure CL's compiler has been much enhanced over MCL's, which is currently PPC-only and not Rosetta compatible. MCL features a Carbon GUI with an Emacs clone named Fred, an interactive inspector and debugger, and a number of other useful tools.

I'd encourage anyone who is interested in making MCL Rosetta-capable or porting to Intel to sign up for the info-mcl mailing list. MCL is an important part of the Common Lisp legacy and it's good to see that it will not be lost to history like some other important implementations (Genera).

New Publication

Fri, 06 Jul 2007 01:17:06 GMT

Frank Weil, Brian Mastenbrook, David Nelson, Paul Dietz, and Aswin van den Berg. Automated Semantic Analysis of Design Models. To appear in ACM/IEEE 10th International Conference on Model Driven Engineering Languages and Systems (MoDELS), October 2007. PDF, 138 kB.

Many of the techniques given in this paper are well known in the compiler community. The application to verification of models of industrial scale telecommunication applications has been able to spot significant but difficult-to-test problems.

There will also be an experience paper given at the 13th System Design Language Forum in September. When I have a copy of this paper, I will post it.

Packrat parsers in Lisp

Tue, 12 Jun 2007 12:18:39 GMT

CL-PEG is a packrat parser generator in Common Lisp. (Found on CLiki.)

New look for Planet Smalltalk

Fri, 09 Mar 2007 13:09:06 GMT

Planet Smalltalk has a new look. While I miss the ability to filter out blogs in languages I don't know, the page is much more readable in its new design.