December 24, 2024

Posts Comments

Archives for May 2010

Regulating and Not Regulating the Internet

May 26, 2010 by

There is increasingly heated rhetoric in DC over whether or not the government should begin to “regulate the internet.” Such language is neither accurate nor new. This language implies that the government does not currently involve itself in governing the internet — an implication which is clearly untrue given a myriad of laws like CFAA, ECPA, DMCA, and CALEA (not to mention existing regulation of consumer phone lines used for dialup and “special access” lines used for high speed interconnection). It is more fundamentally inaccurate because referring simply to “the internet” blurs important distinctions, like the difference between communications transport providers and the communications that occur over those lines.

However, there is a genuine policy debate being had over the appropriate framework for regulation by the Federal Communications Commission. In light of recent events, the FCC is considering revising the way it has viewed broadband since the mid-2000s, and Congress is considering revising the FCC’s enabling statute — the Communications Act. At stake is the overall model for government regulation of certain aspects of internet communication. In order to understand the significance of this, we have to take a step back in time.

Before 2005

In pre-American British law, there prevailed a concept of “common carriage.” Providers of transport services to the general public were required to conduct their business on equal and fair terms for all comers. The idea was that all of society benefited when these general-purpose services, which facilitated many types of other commerce and cultural activities, were accessible to all. This principle was incorporated into American law via common-law precedent and ultimately a series of public laws culminating in the Communications Act of 1934. The structure of the Act remains today, albeit with modifications and grafts. The original Act included two regulatory regimes: Title II regulated Common Carriers (telegraph and telephone, at the time), whereas Title III regulated Radio (and, ultimately, broadcast TV). By 1984, it became necessary to add Title VI for Cable (Titles IV and V have assorted administrative provisions), and in 1996 the Act was revised to focus the FCC on regulating for competition rather than assuming that some of these markets would remain monopolies. During this period, early access to the internet began to emerge via dial-up modems. In a series of decisions called the Computer Inquiries, the FCC decided that it would continue to regulate phone lines used to access the internet as common carriers, but it disclaimed direct authority over any “enhanced” services that those lines were used to connect to. The 1996 Telecommunications act called these “enhanced” services “information services”, and called the underlying telephone-based “basic” transport services “telecommunications services”. Thus the FCC both did and did not “regulate the internet” in this era.

In any event, the trifurcated nature of the Communications Act put it on a collision course with technology convergence. By the early 2000s, broadband internet access via Cable had emerged. DSL was being treated as a common carrier, but how should the FCC treat Cable-based broadband? Should it classify it as a Title II common carrier, a Title VI cable service, or something else?

Brand X and Its Progeny

This question arose during a period in which a generally deregulatory spirit prevailed at the FCC and in Congress. The 1996 Telecommunications Act contained a great deal of hopeful language about the flourishing competition that it would usher in, making unneccessary decades of overbearing regulation. At the turn of the milennium, a variety of revolutionary networking platforms seemed just around the corner. The FCC decided that it should remove as much regulation from broadband as possible, and it had to choose between two basic approaches. First, it could declare that Cable-based broadband service was essentially the same thing as DSL-based broadband service, and regulate it under Title II (aka, a “telecommunications service”). This had the advantage of being consistent with decades of precedent, but the disadvantage of introducing a new regulatory regime to a portion of the services offered by cable operators, who had never before been subject to that sort of thing (except in the 9th Circuit, but that’s another story). The 1996 Act had given the FCC the authority to “forbear” from any obligations that it deemed unnecessary due to sufficient competition, so the FCC could still “deregulate” broadband to a significant extent. The other option was to reclassify cable broadband as a Title I service (aka, an “information service”). What is Title I, you ask? Well, there’s very little in Title I of the Communications Act (take a look). It mostly contains general pronouncements of the FCC’s purpose, so classifying a service as such is a more extreme way of deregulating a service. How extreme? We will return to this.

The FCC chose this more extreme approach, announcing its decision in the 2002 Cable Modem Order. This set off a prolonged series of legal actions, pitting the deregulatory-spirited FCC against those that wanted cable to be regulated under Title II so that operators could be forced to provide “open access” to competitors who would use their last-mile infrastructure (the same way that the phone company must allow alternative long distance carriers today). This all culminated in a decision by the 9th Circuit that Title I classification was unacceptable, and a reversal of that decision by the Supreme Court in 2005. The case is commonly referred to by its shorthand, Brand X. The majority opinion essentially states that the statute is ambiguous as to whether cable broadband is a Title I “information service” or Title II “telecommunications service”, and the Court deferred to the expert-agency: the FCC. The FCC immediately followed up by reclassifying DSL-based broadband as a Title I service as well, in order to develop a, “consistent regulatory framework across platforms.” At the same time, it released a Policy Statement outlining the so-called “Four Freedoms” that nevertheless would guide FCC policy on broadband. The extent to which such a statement was binding and enforceable would be the subject of the next chapter of the debate on “regulating the internet.”

Comcast v. FCC

After Brand X and the failure of advocates to gain “open access” provisions on broadband generally, much of the energy in the space focused to a fallback position: at the very least, they argued, the FCC should enforce its Policy Statement (aka, the “Four Freedoms”) which seemed to embody the spirit of some components of the non-discriminatory legacy of common carriage. This position came to be known as “net neutrality,” although the term has been subject to a diversity of definitions over the years and is also only one part of a potentially broader policy regime. In 2008, the FCC was forced to confront the issue when it was discovered that Comcast had begun interfering with the Bittorrent traffic of customers. The FCC sought to discipline Comcast under its untested Title I authority, Comcast thought that it had no such authority, and the DC Circuit Court agreed with Comcast. It appears that the Title I approach to deregulation was more extreme than even the FCC thought (although ex-Chairman Powell had no problem blaming the litigation strategy of the current FCC). To be clear, the Circuit Court said that the FCC did not have authority under Title I. But, what if the FCC had taken the alternate path back in 2002, deciding to classify broadband as a Title II service and “forbear” from all of the portions of the statute deemed irrelevant? Can the FCC still choose that path today?

Reclassification

Chairman Genachowski recently announced a proposed approach that would reclassify the transport portion of broadband as a Title II service, while simultaneously forbearing from the majority of the statute. This approach is motivated by the fact that Comcast cast a pall over the FCC’s ability to fulfill its explicit mandate from Congress to develop a National Broadband Plan, which requires regulatory jurisdiction in order for the FCC to be able to implement many of its components. I will discuss the reclassification debate in my next post. I’ll be at a very interesting event in DC tomorrow morning on the subject, titled The FCC’s Authority Over Broadband Access. For a preview of some of what will be discussed there, I recommend FCC General Counsel’s presentation from yesterday (starting at 30 minutes in), and Jon Neuchterlein’s comments at this year’s Silicon Flatirons conference. I am told that the event tomorrow will not be streamed live, but that the video will be posted online shortly thereafter. I’ll update this post when that happens. You can also follow tweets at #bbauth. [Update: the video and transcripts for Panel 1 and Panel 2 are now posted]

A New Communications Act?

In parallel, there has been growing attention to a revision of the Communications Act itself. The theory here is that the old structure just simply doesn’t speak sufficiently to the current telecommunications landscape. I’ll do a follow-up post on this topic as well, mapping out the poles of opinion on what such a revised Act should look like.

Bonus: If you just can’t get enough history and contemporary context on the structure of communications regulation, I did an audio interview with David Weinberger back in January 2009.

Filed Under: Broadband, National Security & Surveillance Tagged With: ,

Privacy Theater

May 26, 2010 by

I have a piece in today’s NY Times “Room for Debate” feature, on whether the government should regulate Facebook. In writing the piece, I was looking for a pithy way to express the problems with today’s notice-and-consent model for online privacy. After some thought, I settled on “privacy theater”.

Bruce Schneier has popularized the term “security theater,” denoting security measures that look impressive but don’t actually protect us—they create the appearance of security but not the reality. When a security guard asks to see your ID but doesn’t do more than glance at it, that’s security theater. Much of what happens at airport checkpoints is security theater too.

Privacy theater is the same concept, applied to privacy. Facebook’s privacy policy runs to almost 6000 words of dense legalese. We are all supposed to have read it and agreed to accept its terms. But that’s just theater. Hardly any of us have actually read privacy policies, and even fewer consider carefully their provisions. As I wrote in the Times piece, we pretend to have read sites’ privacy policies, and the sites pretend that we have understood and consented to all of their terms. It’s privacy theater.

Worse yet. privacy policies are subject to change. When sites change their policies, we get another round of privacy theater, in which sites pretend to notify us of the changes, and we pretend to consider them before continuing our use of the site.

And yet, if we’re going to replace the notice-and-consent model, we need something else to put in its place. At this point, It’s hard to see what that might be. It might help to set up default rules, on the theory that a policy that states how it differs from the default might be shorter and simpler than a stand-alone policy, but that approach will only go so far.

In the end, we may be stuck with privacy theater, just as we’re often stuck with security theater. If we can’t provide the reality of privacy or security, we can settle for theater, which at least makes us feel a bit better about our vulnerability.

Filed Under: Privacy & Security Tagged With: ,

School's Laptop Spying Software Exploitable from Anywhere

May 24, 2010 by

This post is by Jay Novak, Jon Stribley, and J. Alex Halderman.

Absolute Manage is a remote administration program that allows sysadmins to supervise and maintain client computers over the Internet. It has been in the news since early February, when Lower Merion School District in Pennsylvania was alleged to be using it to spy on students at home via their laptop webcams. The story took a new twist last Thursday, when Threat Level reported that researchers at Leviathan Security Group had discovered serious vulnerabilities in the program. These problems let attackers carry out a number of exploits, including installing malware or running other arbitrary code on the students’ laptops. The major limitation in the reported attacks is that the bad guy needs to be on the same local network as the victim, and the program’s developers, Absolute Software, says it’s a largely theoretical threat.

Unfortunately, the security problems are worse than has been reported so far, and are far from theoretical. In fact, any machine with a public IP address running Absolute Manage can be taken over by attackers anywhere on the Internet. Such an attacker can command the machine to run arbitrary code, steal data, or take photographs using the computer’s camera.

We have been investigating Absolute Manage for several months, hoping to gain a better understanding of the security measures it employs to protect users. We are disclosing this information now because, following the Threat Level post, we believe it’s only a matter of time until real attackers discover it. Users need to be aware of the vulnerabilities and take proper measures to protect themselves.

Broken Cryptography

The security issues revolve around the way Absolute Manage encrypts commands sent to the clients. The software has two parts: the Absolute Manage Agent, which runs on client machines, and the Absolute Manage Server, which tracks clients under its supervision and sends commands to perform remote operations like installing new software. The clients and server exchange messages using a TCP-based protocol. Clients continuously listen for messages containing instructions from the server, and they also periodically send “heartbeat” messages to the server to deliver status updates and pull down any queued commands.

The programs compress and encrypt each message before transmitting it. They use an encryption algorithm called Blowfish, which is a credible, if outmoded, choice. The problem is how the keys are managed. Strong encryption protocols like SSL negotiate a new secret key for each communication session, but Absolute Manage uses the same hard coded key every time, in every client. Blowfish can use variable-sized keys from 1-56 bytes, and the programmers decided to use secret textual phrases for the keys. We know what the keys are. We won’t publish them here, but they were easy to figure out by inspecting the program files.

Using hard coded keys neutralizes the benefits of cryptography. Since the same, easy-to-discover key is used in every client, it’s straightforward for an attacker to unwrap the encrypted messages, modify them, or encrypt messages of his own. This problem is very similar to the broken cryptography in Diebold voting machines that Ari, Alex, and Ed discovered years ago. Diebold also used a simple fixed key, which allowed an attacker with access to one machine to learn the key and attack all the other machines.

The broken cryptography in Absolute Manage enables a variety of attacks. For instance, an attacker can eavesdrop on a command sent from the server and rewrite it to issue a new command that installs and executes malicious code. Or, he can act as a man-in-the-middle between the client and server and insert evil commands in response to a client heartbeat message. An attacker could easily do these by sniffing wireless LAN traffic, as in school and office environments where Absolute Manage is often deployed. These seem to be the attacks referred to in the Threat Level post.

Exploitable from Anywhere

The limitation of these attacks is that the bad guy usually needs to be on the same physical network as the victim. However, we discovered that potentially more dangerous attacks are possible. In these attacks, a bad guy anywhere on the Internet can exploit any Absolute Manage client with a publicly reachable IP address.

Here’s an example of a message from the server to the client, with the encryption and compression removed. The client tries to authenticate the command using a parameter called the SeedValue. This value is provided by the server when a client initially attempts to contact it after booting. After that, the client requires the SeedValue to be the same in subsequent commands. The client basically ignores all of the other parameters that look like they would be hard to guess, so the SeedValue is the only thing that makes it difficult for the attacker to generate his own command messages from whole cloth.

In our example message, the SeedValue is:

D969E2CD0CB67F4063F45CEAC7D145B12D76A969306AE0CE

It turns out that it is encrypted using a second hard-coded textual phrase. Decrypting it yields the following bytes:

00 00 00 00 e0 03 10 03 40 03 00 00 31 00 34 00 37 00 35 00 00 00 00 00 00

The length is misleading; the value is actually just a 16-bit unicode encoding of a 7-digit number, 1401475. This is the server’s “serial number,” which was provided by Absolute Software along with the product activation key when we purchased our license.

Thus, an attacker who wants to send arbitrary commands to Absolute Manage clients just needs to figure out the server’s serial number. One way he can do that is to guess it. The attacker could try contacting the client with different values until one of them turns out to be correct. If all serial numbers are 7 digits (like ours) or less, and there is no pattern to there assignment, then an attacker can guess among 10 million possibilities. If there is a pattern (the likely case) then the attacker’s job may be much easier. Our tests show that we can make more than 330 guesses/second over a fast network link, so even assuming no pattern an attacker could expect to succeed after about four hours of guessing. Each server uses the same serial number for all its clients, so after the attacker guesses it for one client, he can compromise all the server’s other clients without any additional guesswork.

Brute forcing the server’s serial number is one method attackers can use, but there is a much more efficient attack for targeting a large set of clients: the server will tell the correct SeedValue to any client that asks. If the attacker knows the IP address of the server a client is trying to contact, he can just impersonate a freshly-booted client and ask the server to send him the correct SeedValue. The server will respond with all the information the attacker needs to impersonate the server.

A bad guy could extend this method to target all Absolute Manage clients in one attack. He could scan the entire Internet address space to discover all hosts running Absolute Manage Server and build a list of active SeedValues. (Servers generally run on public IP addresses so that they can receive status updates from clients that are away from the local network.) Such a scan would take only a few days. The attacker could then do a second Internet-wide scan to discover Absolute Manage Clients. For each of them, he would need only a few seconds to try all the active SeedValues from his list and determine the correct one. This attack could be exploited to quickly install and run malicious code on all computers running the Absolute Manage client on publicly accessible IP addresses.

Defenses and Lessons

In the short term, users can protect themselves by uninstalling the Absolute Manage client. This might be difficult on machines with privileges locked down, so system administrators will need to help.

(Attempts to work around the problem, such as firewalling the server so it can’t be found by an Internet scan, may backfire. If the server is unreachable from outside the firewall, clients that are rebooted away from the local network will be unable to obtain a SeedValue. In this situation, the clients insecurely default to accepting arbitrary commands without even the protection of a SeedValue.)

In the long term, the solution is for Absolute Manage to adopt serious cryptographic authentication. Absolute Software says they will do this in the next version later this summer–let’s hope they get it right next time.

Remote administration products like Absolute Manage carry large risks because they intentionally create a mechanism for a remote third party to take control of the machine. This can be powerful in the right hands but devastating if exploited by attackers. There will always be a risk of abuse by authorized parties, as alleged in the students’ lawsuit against Lower Merion School District, but correctly designed technology should at least prevent unauthorized third-party attacks by making sure only authorized parties can issue commands. This requires getting authentication right–exactly what Absolute Manage failed to do.

Because of these dangers, remote administration software should be designed defensively, minimizing the risk even if the authentication fails. For example, it could only allow installation of signed binaries, or it could give users prominent notification before actions are taken so that attacks can be more easily detected.

The blatant vulnerabilities in Absolute Manage suggest that this kind of remote administration software requires greater security scrutiny. We will further discuss the problems and the lessons they carry in a forthcoming paper.

Filed Under: Privacy & Security Tagged With:

Developing Texts Like We Develop Software

May 11, 2010 by

Recently I was asked to speak at a conference for university librarians, about how the future of academic publication looks to me as a computer scientist. It’s an interesting question. What do computer scientists have to teach humanists about how to write? Surely not our elegant prose style.

There is something distinctive about how computer scientists write: we tend to use software development tools to “develop” our texts. This seems natural to us. A software program, after all, is just a big text, and the software developers are the authors of the text. If a tool is good for developing the large, complex, finicky text that is a program, why not use it for more traditional texts as well?

Like software developers, computer scientist writers tend to use version control systems. These are software tools that track and manage different versions of a text. What makes them valuable is not just the ability to “roll back” to old versions — you can get that (albeit awkwardly) by keeping multiple copies of a file. The big win with version control tools is the level of control they give you. Who wrote this line? What did Joe write last Tuesday? Notify me every time section 4 changes. Undo the changes Fred made last Wednesday, but leave all subsequent changes in place. And so on. Version control systems are a much more powerful relative of the “track changes” and “review” features of standard word processors.

Another big advantage of advanced version control is that it enables parallel development, a style of operation in which multiple people can work on the text, separately, at the same time. Of course, it’s easy to work in parallel. What’s hard is to merge the parallel changes into a coherent final product — which is a huge pain in the neck with traditional editing tools, but is easy and natural with a good version control system. Parallel development lets you turn out a high-quality product faster — it’s a necessity when you have hundred or thousands of programmers working on the same product — and it vastly reduces the amount of human effort spent on coordination. You still need coordination, of course, but you can focus it where it matters, on the conceptual clarity of the document, without getting distracted by version-wrangling.

Interestingly, version control and parallel development turn out to be useful even for single-author works. Version control lets you undo your mistakes, and to reconstruct the history of a problematic section. Parallel development is useful if you want to try an experiment — what happens if I swap sections 3 and 4? — and try out this new approach for a while yet retain the ability to accept or reject the experiment as a whole. These tools are so useful that experienced computer scientists tend to use them to write almost anything longer than a blog post.

While version control and parallel development have become standard in computer science writing, there are other software development practices that are only starting to cross the line into CS writing: issue tracking and the release early and often strategy.

Issue tracking systems are used to keep track of problems, bugs, and other issues that need to be addressed in a text. As with version control, you can do this manually, or rely on a simple to-do list, but specialized tools are more powerful and give you better control and better visibility into the past. As with software, issues can range from small problems (our terminology for X is confusing) to larger challenges (it would be nice if our dataset were bigger).

“Release early and often” is a strategy for rapidly improving a text by making it available to users (or readers), getting feedback, and rapidly turning out a new version that addresses the feedback. Users’ critiques become issues in the issue tracking system; authors modify the text to address the most urgent issues; and a new version is released as soon as the text stabilizes. The result is rapid improvement, aligned with the true desires of users. This approach requires the right attitude from users, who need to be willing to tolerate problems, in exchange for a promise that their critiques will be addressed promptly.

What does all of this mean for writers who are not computer scientists? I won’t be so bold as to say that the future of writing will be just exactly like software development. But I do think that the tools and techniques of software development, which are already widely used by computer scientist writers, will diffuse into more common usage. It will be hard to retrofit them into today’s large, well-established editing software, but as writing tools move into the cloud, I wouldn’t be surprised to see them take on more of the attributes of today’s software development tools.

One consequence of using these tools is that you end up with a fairly complete record of how the text developed over time, and why. Imagine having a record like that for the great works of the past. We could know what the writer did every hour, every day while writing. We could know which issues and problems the author perceived in earlier versions of the text, and how these were addressed. We could know which issues the author saw as still unfixed in the final published text. This kind of visibility will be available into our future writing — assuming we produce works that are worthy of study.

Filed Under: Uncategorized Tagged With: