COMSEC: March 2008 Archives

 

March 26, 2008

I'm not a WoW player but a bunch of my friends are, and they seem to put in a really enormous amount of hours just acquiring experience and loot. I guess this is pretty boring even by WoW standards, so it's not at all surprising that people have developed automatic WoW players. Now Blizzard is suing MDY, the creator of one such bot, MMO Glider Unsurprisingly, Blizzard doesn't like bots, since they provide a very substantial advantage to bot users over everyone else (again, I'm not a WoW player, but I think one has to concede they have a point here) and go to a lot of effort to block them.

Unfortunately for Blizzard, determining what software is running on a remote computer controlled by your adversary is known to be an incredibly difficult problem—as far as I know there is no general solution that doesn't involve some sort of trusted computing base on the remote computer (cf. TCG), 1 which of course most people don't have. That hasn't stopped Blizzard from trying, of course. They install a program called Warden on your computer which tries detect whether you're running cheat programs in parallel with WoW itself. Unsurprisingly, MDY has circumvention technology which evades Warden. So, from a technical perspective, this is a losing game for Blizzard. However, that doesn't mean that they can't win their lawsuit.

As I understand the situation, Glider isn't a WoW reimplementation, it's just a control program for WoW. So you start up WoW (or rather Glider does) and then Glider runs the various WoW operations for you. Blizzard argues that running WoW this way exceeds the EULA and so by building a tool designed to be used this way, MDY is engaged in contributory copyright infringement.

I'm not a lawyer, so I'm not going to offer an opinion on the value of this argument, but say that this holds up in court, does MDY have a technical recourse? That's a difficult problem. Since Glider depends on WoW, if they're enjoined from doing that, then life gets a lot harder. They obviously could do a WoW client implementation from scratch, but aside from that being a lot of work, it is actually incredibly easy for Blizzard to detect; they simply can have the server ask the client for a randomly chosen (by the server) section of its code. In order to emulate a real client, Glider would need to have a copy of the WoW client floating around. Would sending the requested copy to Blizzard then constitute copyright infringement as well?

1. The two contexts in which this problem is most relevant are DRM (where the content provider wants to be able to determine that the playing application will enforce its content controls) and network access control/network endpoint assessment, where the network wants to determine that an endpoint is uninfected. In neither case are there adequate solutions against an adversarial endpoint.

 

March 13, 2008

The topic of routing security has started to heat up quite a bit in IETF. Historically, there have been two general types of routing security measures:
  • Trying to defend against outsider attacks by securing adjacencies between routers.
  • Trying to defend against insider attacks by authenticating (and more importantly, authorizing) route advertisements to make sure that routers are only advertising permitted routes.

The second class of mechanisms (e.g., S-BGP) haven't really seen any significant deployment, despite the fact that there is a real threat from incorrect advertisements. (See this post about the Pakistan/YouTube outage for an example.)

The first class of mechanisms have seen modest deployments, but the protocols are fairly primitive, with insecure (or at least pre-modern) MAC function and minimal support for key management. Basically, you used a shared key between the communicating routers (a pair in the case of unicast protocols like BGP or LDP, or a group in the case of multicast/broadcast protocols like IS-IS or OSPF). All was well—or at least quiet—until 2005, when Bonica et al. published a draft which was intended to make key rollover easier for integrity protected TCP and also to update the MAC algorithms. This, coupled with some concerns about the lack of automated keying mechanisms, caused an avalanche efect of interest in revising all the routing adjacency security mechanisms.

IETF 71 had two meetings addressing this topic:

  • TCPM which covered standardizing TCP integrity protection.
  • KMART which covered keying for the average

For some reason that's not entirely clear to me, I got sucked into this stuff. My materials are below:

  • A draft discussing strategies for keying for TCP.
  • Extensive comments on the current TCP authentication option draft
  • A presentation on the generic key management problem.
 

March 6, 2008

There's more than one way to censor information you don't like on the Internet. At the end of February, Pakistan's Telecommunication authority decided they didn't like a specific YouTube video and issued an order requiring ISPs to block access to YouTube. The ISPs responded by advertising BGP routes to blackhole YouTube's traffic. Unfortunately, they screwed up and the routes leaked, bringing down YouTube for everyone. Danny McPherson at Arbor Networks has the story.
Either way, the net-net is that you're announcing reachability to your upstream for 208.85.153.0/24, and your upstream provider, who is obviously not validating your prefix announcements based on Regional Internet Registry (RIR) allocations or even Internet Routing Registry (IRR) objects, is conveying to the rest of the world, via the Border Gateway Protocol (BGP), that you, AS 17557 (PKTELECOM-AS-AP Pakistan Telecom), provide reachability for the Internet address space (prefix) that actually belongs to YouTube, AS 36561.

To put icing on the cake, assume that YouTube, who owns 208.65.153.0/24, as well as 208.65.152.0/24 and 208.65.154.0/23, announces a single aggregated BGP route for the four /24 prefixes, announced as 208.65.152.0/22. Now recall that routing on the Internet always prefers the most specific route, and that global BGP routing currently knows this:

  • 208.65.152.0/22 via AS 36561 (YouTube)
  • 208.65.153.0/24 via AS 17557 (Pakistan Telecom)

And you want to go to one of the YouTube IPs within the 208.65.153.0/24. Well, bad news.. YouTube is currently unavailable because all the BGP speaking routers on the Internet believe Pakistan Telecom provides the best connectivity to YouTube. The result is that you've not only taken YouTube offline within your little piece of the Internet, you've single-handedly taken YouTube completely off the Internet.

The problem here is that BGP security is a complete mess. To a first order anyone can advertise any route and they'll be believed. In other words, the Internet is horribly vulnerable to routing attacks. There's been some work in trying to prevent this sort of thing happening (whether via accidental misconfiguration or worse yet, maliciously) but none of the solutions (S-BGP, SoBGP, etc.) but none of it has gone very far, in part because many of the proposed designs are really heavyweight and in part because (or so I'm told) the database of who actually owns what prefix is in such bad shape that you can't use it as a basis for cryptographic assertions about who can advertise what.