SMBlog -- Steve Bellovin's Blog

The Open Source Quality Challenge

Wed, 29 Apr 2009 21:41:41 GMT

I realized this morning that I had to upgrade Firefox -- again. It seems that 3.0.9 had a security problem. It's less than a week since the last time I had to upgrade: 3.0.8 had security problems, too. In fact, in the year or so that Firefox&nbs;p3 has been out, there have been about 50 official security advisories, 30 rated critical or high severity. What's going on?

We have known for a long time that most security holes are simply a particular form of bug. The corollary, of course, is that reducing bugs in general is a good way to reduce the incidence of security problems. Is Firefox too buggy, and hence too insecure?

We've also known for a long time that good, structured development process do work. They may be expensive in the short run, but they do pay off. This is the challenge for the open source movement: can it impose such discipline?

Microsoft committed publicly to security improvements several years ago. From where I sit, the effort has been working. Windows is neither bug-free nor security hole-free, and probably never will be; that said, it's a lot better today than it would have been had Bill Gates not gotten religion about security. I've heard a number of theories about why that happened, but those aren't important; what counts is the end result.

I've also heard the claim that Firefox has had fewer days of vulnerability. That sounds great, until you realize that one way to achieve that is by shipping patches quickly, without adequate testing. Consider this security advisory:

One of the security fixes in Firefox 3.0.9 introduced a regression that caused some users to experience frequent crashes. Users of the HTML Validator add-on were particularly affected, but other users also experienced this crash in some situations. In analyzing this crash we discovered that it was due to memory corruption similar to cases that have been identified as security vulnerabilities in the past.

Was 3.0.9 released too quickly, necessitating the very rapid release of 3.0.10?

It has been said that "given enough eyeballs, all bugs are shallow". That may be true. What we need now is a way for the many eyeballs to prevent the bugs in the first place. It won't be easy. Submitting to discipline is difficult for many, and fun for very few. Programmers like to write code, not requirements, design documents, test scripts, and the like. I fear, though, that there are no other choices. Just as there is no royal road to geometry, I fear there is no royal road to correct software.

I'm a fan of open source software. Indeed, I'm not just writing this on a machine running an open source operating system, NetBSD, I'm a NetBSD developer (albeit not a very active one). However, if the open source movement is to fulfill its promise, it needs to solve its buggy code problem. We have several decades of experience that teach us there are no magic solutions or tools that will solve that problem. We're going to have to do it the hard way.

The Cybersecurity Act of 2009

Mon, 13 Apr 2009 02:36:32 GMT

Four senators (Rockefeller, Bayh, Nelson, and Snowe) have recently introduced S.773, the Cybersecurity Act of 2009. While there are some good parts to the bill, many of the substantive provisions are poorly thought out at best. The bill attempts to solve non-problems, and to assume that research results can be commanded into being by virtue of an act of Congress. Beyond that, there are parts of the bill whose purpose is mysterious, or whose content bears no relation to its title.

Let's start with the good stuff. Section 2 summarizes the threat. If anything, it understates it. Section 3 calls for the establishment of an advisory committee to the president on cybersecurity issues. Perhaps that's Just Another Committee; on the other hand, it reports to the president and "shall advise the President on matters relating to the national cybersecurity program and strategy". That's good -- but whether or not the president (any president!) actually listens to and understands their recommendations is another matter entirely.

Section 10 ("Promoting Cybersecurity Awareness") and Section 13 ("Cybersecurity Competition and Challenge") are innocuous, though I'm not convinced they'll do much good. (I suspect that folks reading this blog already realize this, but I'll state it explicitly anyway: the odds on anyone, whether in a "challenge" or not, finding a magic solution to the computer security problems are exactly 0. Most of the problems we have are due to buggy code, and there's no single cause or solution to that. In fact, I seriously doubt if there is any true solution; buggy code is the oldest unsolved problem in computer science, and I expect it to remain that way.)

As an academic, I am, of course, in favor of more research dollars (Section 11). Once again, I'll state the obvious: I would hope to benefit if that provision is enacted.

Section 21, on "International Norms and Cybersecurity Deterrance [sic] Measures", is problematic. I don't think that lack of international norms or cooperation -- to the extent that this provision might actually accomplish something -- is much of a problem. But what does the bill mean by "deterrence"? There is no substance in that section. The proper role of government in dealing with cyber threats from abroad is indeed worthy of discussion; I've written about this elsewhere. This bill is silent on it, except for the title of this section.

I'm intrigued by Section 15, on risk management. The proper role of liability and insurance in cybersecurity has long been a topic of discussion; I would very much like to see a full-blown study of the question (probably by the National Academies), but I don't think that can be done in one year.

I don't know why the bill allots three years (Section 9) to implement DNSSEC; NIST already has that project well underway for the .gov zone. It would be good if the root zone and .com were signed, but I don't think that that's NIST's responsibility. Calling for a review of IANA's contracts to run the root zone of the DNS is just plain wrong; while IANA does administer the root zone, it does so under ICANN's direction. ICANN is an international organization; a legislative attempt to wrest control of the root for the United States would not be well-received.

So much for the sections I like. The bad parts of this bill, I fear, outweigh the good parts.

Section 17 has a good title -- "Authentication and Civil Liberties Report" -- but it worries me. It calls for a study on the feasibility of "an identity management and authentication program ... for government and critical infrastructure information systems and networks." Such a system is a bad idea.

The idea seems to have come from the "Securing Cyberspace for the 44^th Presidency" report, about which I've written earlier. True, this bill calls for "appropriate civil liberties and privacy protections", but a centralized authentication system is likely to lead to serious security risks. As a National Academies study noted, "A centralized password system, a public key system, or a biometric system would be much more likely to pose security and privacy hazards than would decentralized versions of any of these." (Disclaimer: I was part of the committee that wrote that report. Naturally, I'm not representing the Academy in this posting.) The 44th President report wanted to ensure that certain actions were strongly tied to authorized individuals, but this approach simply won't accomplish that goal. I say that for many reasons; now, I'll mention just one: consider the effect of a tailored virus that infected the computer of someone who is supposed to control critical infrastructure systems. That virus could do anything it wanted, with the proper person's credentials.

Sections 6 and 18 are seriously flawed. For one thing, they make the assumption that there is some easily-distinguished set of crucial networks. I doubt that there is. The 1999 National Academies report Trust in Cyberspace (again, I was on the committee; again, I'm speaking only for myself) stated

The study committee believes that implementing a single MEII ["Minimum Essential Information Infrastructure"] for the nation would be misguided and infeasible. An independent study conducted by RAND (Anderson et al., 1998) also arrives at this conclusion. One problem is the incompatibilities that inevitably would be introduced as nonhardened parts of NISs are upgraded to exploit new technologies. NISs ["Networked Information Systems"] constantly evolve to exploit new technology, and an MEII that did not evolve in concert would rapidly become useless.
A second problem with a single national MEII is that "minimum" and "essential" depend on context and application (see Box 5.1), so one size cannot fit all. For example, water and power are essential services. Losing either in a city for a day is troublesome, but losing it for a week is unacceptable, as is having either out for even a day for an entire state. A hospital has different minimum information needs for normal operation (e.g., patient health records, billing and insurance records) than it does during a civil disaster. Finally, the trustworthiness dimensions that should be preserved by an MEII depend on the customer: local law enforcement agents may not require secrecy in communications when handling a civil disaster but would in day-to-day crime fighting.

Looking more narrowly, we come to the same conclusion. Suppose that we only wanted to protect the water, power, and communications systems, and hence their networks, while other networks were under attack. How would spare parts be ordered, if the vendors' factory networks weren't functioning? Where would fuel come from, if trucking and shipping company networks were not protected? Could these companies even communicate with their employees, given how many rely on commercial ISPs for telecommuting? For that matter, these companies themselves rely on commercial ISPs to link their various locations. The ability of the Presiden to "declare a cybersecurity emergency and order the limitation or shutdown of Internet traffic to and from any compromised Federal Government or United States critical infrastructure information system or network" would be of dubious utility. (The political and social wisdom of granting such power is itself an interesting question; for today at least, I'll concentrate on the technical issues.)

Section 6 has other questionable provisions. 6(a)(1) calls for research in cybersecurity metrics. Research is a fine thing and security metrics are an active research area. Why should asking NIST to focus on this result in new answers? I've asserted that the most interesting question -- how secure is a given piece of software -- is not answerable, even in principle. Known weaknesses (see (6)(a)(2) and (6)(a)(3)) aren't very interesting; if a site hasn't fixed them, it's generally because of overriding concerns, such as budget, backwards compatibility, or the sheer difficulty of updating a large-scale production system without breaking the applications you're trying to run.

(6)(a)(4) is just strange. Yes, configuration management is difficult and security-relevant. That doesn't mean that a standard configuration language would solve such problems. Why, for example, should the proper security settings for a web browser bear any relationship whatsoever to the settings of a laptop's built-in firewall? Neither bears any particular relationship to permission setings for a database server, let alone permissions within the database itself. It's not just comparing apples to oranges, it's comparing apples to magnetic alloys of neodymium or some such. There might be a small benefit to having one parser, but the real problem is the policies configured, rather than the language. Perhaps the goal is to make it easy to swap out one box and get a different model that does the same thing, but that simply won't work; the new box will have different concepts, and hence different secure configuration requirements.

The same can be said for (6)(a)(5), on standard software configurations. (That and some other sections apply to "grantees", among others. Does that mean that NIST will have to set standards for NetBSD, to accomodate people like me? Or does it mean that I can't run NetBSD, despite the threat posed by software monocultures?

A vulnerability specification language ((6)(a)(6)) isn't a bad idea, though I note that such a thing is inherently OS-dependent. Two things are necessary, though, to make it useful: sufficient knowledge of what components are implicated, and sufficient knowledge of what the vulnerability is, to permit realistic assessment of the actual risk to a given site. I'll give a concrete example: the system I'm typing this on has a version of Ghostscript with a buffer overflow when processing PDF documents. Yes, that sounds serious -- except that I never use Ghostscript to read external PDFs; I use a variety of other programs. To me, then, there is no risk.

Section (6)(a)(7) sounds great -- national compliance standards for all software -- but it's doomed. We've been down that road before, ranging from the Orange Book to the Common Criteria. All of these projects tried to establish standards and evaluation criteria for trusted software systems. The problem is that building and testing such systems, and going through external evaluations, are slow and expensive processes. Far fewer systems were evaluated than should have been, because purchasers wanted to buy cheap commercial hardware and software. The result was an endless set of waivers. Is the government willing to pay premium prices, for all of its systems? Let me rephrase the question: will each and every government agency be willing to spend its own budget dollars on such systems, and will Congress appropriate enough money? Allow me to express serious doubt. "C2 by '92" (an attempt by DoD to enforce minimal levels of security via use of C2-level systems by 1992) never went anywhere; I don't think this one will succeed, either. There are many further reasons for skepticism -- who will pay for private sector deployments; what security model is appropriate (the Orange Book was geared to the military classification model, which is simply wrong for most civilian use); whether the flaws are in the OS at all, etc.), and more -- and we can't just legislate useful, usable standards into being. Legislation may be appropriate when we know the goal (we don't), or we have good reason to believe we'll know it and can reach it in not very many years. Neither is the case here.

I could go on and on. Section 7, for example, calls for licensing of cybersecurity professionals. What is that supposed to do? The big flaws lie not in the ways we configure our firewalls and crypto boxes; rather, they're in the software we choose to run, and in management that doesn't listen to (or doesn't understand) security warnings. Are the authors of the legislation concerned about sabotage by security folks who aren't trustworthy? I'd start by worrying about supply chain vulnerabilities in hardware and software.

It's fair to ask what I would recommend instead. Suppose I were drafting a bill or an executive order. Suppose (heaven help us all) President Obama appointed me as his National Cybersecurity Advisor. What would I suggest? A full answer would call for a much longer post than this; indeed, it would probably take at least a full-fledged technical paper and perhaps a book. The short answer is that just as there is no royal road to geometry, there is no presidential or Congressional road to cybersecurity. You have to do it step by step, system by system. Things we can do today -- more cryptography, following industry best practices, and so on -- are the low-hanging fruit; while we should do more of these, such things are demonstrably insufficient. A more drastic move is to accept that there are some things we just can't do safely at any reasonable cost: the complexity will get us. We need to be more humble in our designs. At this point, to a first approximation all computer systems are interconnected; we cannot realistically hope to limit the spread of certain attacks. We can make progress if and only if we accept that as the starting point, ask "what then?", and build our systems accordingly.

Internet Records Retention Bill

Fri, 20 Mar 2009 17:13:19 GMT

A lot of pixels have been spilled lately over an Internet records retention bill recently introduced in both the House and the Senate. The goal is to fight child pornography. That's a worthwhile goal; however, I think these bills will do little to further it. Worse yet, I think that at least two of the provisions of the bill are likely to have bad side effects. Unfortunately, the text is quite bad; we will have to wait for regulatory action and/or overzealous prosecutors to see just how far the language will stretch.

The first troublesome provision is Section 3, which amends Chapter 95 of Title 18 of the U.S. Code to add

(a) Offense-- Whoever, being an Internet content hosting provider or email service provider, knowingly engages in any conduct the provider knows or has reason to believe facilitates access to, or the possession of, child pornography (as defined in section 2256) shall be fined under this title or imprisoned not more than 10 years, or both.

This might criminalize things like onion routing, an important privacy-preserving technology. (Ironically, onion routing got its start at a government agency, the Navy Research Lab.) Since the clause is limited to "Internet content hosting providers" and "email service providers", most Tor nodes won't affected. Besides, very many Tor nodes are outside the country, so this provision likely won't hinder any would-be viewers of child pornography.

There are other infelicities in the definitions. "Internet content hosting provider" is defined broadly enough to include web caches; "Email service provider" requires that the site provide "transmission" and "retrieval" services, which excludes companies that offer only one. Besides, any networking technology "facilitates access to" all sorts of content, good and bad. Is the Internet being outlawed?

The records retention provision adds

(h) Retention of Certain Records and Information-- A provider of an electronic communication service or remote computing service shall retain for a period of at least two years all records or other information pertaining to the identity of a user of a temporarily assigned network address the service assigns to that user.'.

to the end of 18 U.S.C. 2703. The problems start with the definitions. Given the location of the clause, the relevant definitions are in 18 U.S.C. 2510 and 18 U.S.C. 2711. These define "electronic communication service" and "remote computing service" but not a "provider" of those services. What does the clause mean? Is it intended just to cover ISPs? Probably not; elsewhere in that part of the law, there are explicit references to "providers ... to the public". Who else is covered? Employers? Hotels? Universities? WiFi hotspots, free or not? Almost certainly, all of the above are included. Home users? Many people (myself included) have wireless routers or access points in our houses; clearly, any guest of mine or my family's is more than welcome to use our Internet connection. How am I supposed to "retain" logs of what IP addresses they get? By chance, I happened to need information just two days ago on what machines were associated with which access points. The logs kept by the devices were utterly useless for this purpose. Am I required to install a (currently non-existent) newer firmware release? for this purpose? Does anyone believe that the average home user is even slightly capable of finding such a thing, let alone installing it? By the way -- as best I can tell, installing new firmware erases all of the current log information on my boxes... And of course, even if I do have such logs, all they would include are timestamps and MAC addresses. I do not retain records on who visits my house when (do I need a log book at the front door?); I have no idea what their devices' MAC addresses are. These people are my friends; I just give them the SSID and encryption key.

Of course, the law requires providers to "retain" records. Does that imply "create"? What if providers have no records? Must they start creating them? If not, home users would be excluded, but some ISPs may decide they don't need to create them, either.

The most troublesome provision of this clause is the restriction to "temporarily assigned network address the service assigns to that user". Presumably, this is intended to cover IP addresses assigned by DHCP or PPP. From a technical perspective, however, that clause is often useless, technically infeasible, or both. Many ISPs, some employers, and virtually all hotels and home WiFi routers use a technology known as Network Address Translation (NAT). When NAT is in use, the address assigned by DHCP is visible only within the provider's network. Law enforcement officials would have no access to this network until after they had identified a suspect. Log files or wiretaps from a child pornographer's site would reveal the external address of the client downloading the material, but that address implicates all users of provider during that period. The internal IP address is not visible on the outside.

Now -- for every connection, a unique IP address and port number is allocated by the NAT box. This, coupled with accurate timestamps and DHCP records, would indeed identify the particular MAC address involved. However, this would require tracking every TCP connection of that user. Apart from being a gross invasion of privacy -- does every hotel I stay at need to know every web site I visit? -- it is probably infeasible to collect this data; there would be far too much of it. The Internet was never designed for this sort of fine-grained record-keeping.

There's another problem: what if the offender is using a Web proxy service? Many hotels and ISPs require use of these; any corporation with an application-level firewall does as well. In that case, the "guilty" IP address would be that of the proxy. Must proxies keep logs? No -- the bill applies to "temporarily assigned network addresses", not proxy devices.

Then there's IPv6. It has a feature known as the Privacy Extensions for Stateless Address Autoconfiguration in IPv6. If this extension is in use, a computer can generate new IP addresses any time it wants to, precisely to avoid linkage across different transactions. This feature is not covered by the law, since the addresses are self-generated and not temporarily assigned by a provider.

I could go on, but I think the point is clear: the bill is poorly drafted, affects legitimate users, creates impossible requirements, leaves too much wiggle room for law enforcement mission creep -- and doesn't do what it's intended to do.

Access to Old Information

Sun, 08 Mar 2009 16:03:46 GMT

There has been a lot of controversy about Google's book-scanning project. A lot of the controversy concerns payments to authors of copyrighted works. While I'm all in favor of copyright -- I earned a non-trivial amount of money from a book -- some recent experiences have left me strongly in favor of the project, but worried about abuse of ownership of physical media.

I've recently been doing some research that has required access to some very old printed works. (Access to the Columbia University Libraries -- definitely a world-class research resource -- has been invaluable to this project. I owe a great debt of gratitude to the generations of librarians who have built and maintained such organizations.) As a result, I very much appreciate the efforts to scan in books. While there are very valid concerns about the permanence of digital file formats and media, books also decay over time. I've been working with 85-year-old books that are very fragile; they clearly will not be usable 85 years from now. The pages are yellow and crumbling, the bindings are failing, any use is a threat to the volume's existence. (Aside: there is a certain undeniable thrill to checking out a book for the first time in more than 70 years, judging from the dates stamped in the back. It brings to mind Gandalf's comment to Boromir in Lord of the Rings: ``there lies in Minas Tirith still, unread, I guess, by any save Saruman and myself since the kings failed, a scroll that Isildur made himself.'') But of what use is a physical volume of knowledge if no one can access it?

Sometimes, this has already been done. I visited Columbia's Rare Book and Manuscript Library, and felt privileged to be able to handle Smith's Secret Corresponding Vocabulary, an 1845 publication by Samuel Morse's business partner. But I was even happier when I found that Google had already scanned a copy. There is a danger, however: who owns the material? The following text appears in public domain books downloaded from Google's archive:

We designed Google Book Search for use by individuals, and we request that you use these files for personal, non-commercial purposes.

Is scholarly researdch a "personal, non-commercial purpose"? Note that this statement explicitly applies to works that are in the public domain.

The issue isn't simply electronic documents. Consider this work, which is a microfilm of a U.S. government document and hence never subject to copyright. The catalog entry bears this note:

Reuse of record except for individual research requires license from Congressional Information Services, Inc.

What is ``individual research''?

What we are seeing is the use of contract law to obtain rights not granted by copyright. If we are not careful, we will see public information locked up. Worse yet, digital records can be protected by so-called Digital Rights Management (DRM) technology, making them inaccessible except on terms dictated by the physical record's owner.

To be sure, a company that goes to the expense of scanning or photographing old books and documents is entitled to make a profit. That begs the question -- at least two of them, in fact. We need to ask about the fate of public documents (such as government records) and about the role of libraries.

Government documents, in a very strong sense, belong to the people. It is perhaps reasonable to let a private company reproduce such documents and be compensated for its efforts, though I prefer the attitude that since public documents do belong to the people, they should be made available by the government itself. That said, if a private company is going to be the designated publisher, it should not control how the documents are used. Their profit should be from the collection -- a collection copyright, if you will -- rather than from the individual documents. It is certainly within the government's power to impose that restriction in any contracts it signs for such reproductions.

Libraries have a different problem. They frequently don't own the originals; however, their mission is to make information broadly available. By agreeing to stringent restrictions, above and beyond what would be permitted under the Fair Use doctrine of copyright law, they undermine their own goals. If libraries, as a matter of principle, decline to purchase works that are unduly encumbered, I suspect that many publishers will back off. (I doubt that there are many purchasers of the collected works of the War Department from a hundred years ago other than for research libraries.)

To sum up: there are two ways we can lose access to information, physical and legal. In avoiding the first problem, we have to take care that we do not create the second. This is especially serious for digitized materials, where technology can enforce restrictive contracts.

EFF's Surveillance Self-Defense Website

Wed, 04 Mar 2009 00:40:19 GMT

The Electronic Frontier Foundation (EFF) has a new website on Surveillance Self-Defense. (Not surprisingly, it -- and as best I can tell the rest of the EFF's site -- can be accessed via an encrypted channel. In fact, if you visit the SSD web site via unencrypted HTTP, you'll be redirected to the encrypted version.) It's a very good guide to the legal and technical issues surrounding surveillance; while I have a few minor quibbles, overall it's an excellent guide. (Caveat: while the technical information is broadly applicable, the legal discussion is specific to US law.)

Highly recommended.

The White House Removes Videos from YouTube

Tue, 03 Mar 2009 01:32:28 GMT

In January, I wrote twice about the government and privacy when using YouTube videos. Chris Soghoian now reports that White House videos have been moved to Akamai. This is indeed a very good move from a privacy perspective.

Of course, now that that's settled, the Supreme Court is at least viewing YouTube videos as part of its deliberations. Does this allow Google to track the viewing habits of Supreme Court justices? Or do they take proper privacy precautions? (The video in question was posted to the Court's own web page -- but hosted by the Court itself, rather than any outside provider.)

Update: the White House denies any change in policy. That's too bad -- they did the right thing; why apologize for it? Are they afraid they'll be seen as having caved to "pressure"? Or is the concern that the new scheme won't work as well, so they want to be prepared in advance in case they have to regress?