March 2007 Archives

There's currently a fair amount of angst about DHS's desire to control the root key for DNSSEC:

The US Department of Homeland Security (DHS), which was created after the attacks on September 11, 2001 as a kind of overriding department, wants to have the key to sign the DNS root zone solidly in the hands of the US government. This ultimate master key would then allow authorities to track DNS Security Extensions (DNSSec) all the way back to the servers that represent the name system's root zone on the Internet. The "key-signing key" signs the zone key, which is held by VeriSign. At the meeting of the Internet Corporation for Assigned Names and Numbers (ICANN) in Lisbon, Bernard Turcotte, president of the Canadian Internet Registration Authority (CIRA) drew everyone's attention to this proposal as a representative of the national top-level domain registries (ccTLDs).

(See for instance this /. thread:

"At an ICANN meeting in Lisbon, the US Department of Homeland Security made it clear that it has requested the master key for the DNS root zone. The key will play an important role in the new DNSSec security extension, because it will make spoofing IP-addresses impossible. By forcing the IANA to hand out a copy of the master key, the US government will be the only institution that is able to spoof IP addresses and be able to break into computers connected to the Internet without much effort [As usual, people on /. seem a little confused about how the Internet works. Needless to say, being able to spoof DNSSEC doesn't let you spoof IPs, nor is being able to spoof DNS queries that much use in breaking into people's computers these days. -- EKR]. There's a further complication, of course, because even 'if the IANA retains the key ... the US government still reserves the right to oversee ICANN/IANA. If the keys are then handed over to ICANN/IANA, there would be even less of an incentive [for the U.S.] to give up this role as a monitor. As a result, the DHS's demands will probably only heat up the debate about US dominance of the control of Internet resources.'"

This is all kind of scary sounding, but it's really a lot less of a big deal than it's made out to be. The basic thing you need to remember is that DNS is a hierarchical system and that DNSSEC follows the hierarchy. Thus, the key in question signs the root zone (or rather the key for the root zone) which just contains the name servers and the keys for the TLDs (.com, .org, .net, .us, etc. The information for your domain (or at least the key for your domain if you had one) would be signed by those keys. So, for instance, they key for educatedguesswork.org would be signed by the key for .org, which itself would be signed by the root zone key.

So, let's say that DHS wanted to forge the address (A) record for educatedguesswork.org. They'd have to sign a fake root zone with a new key for .org and make a parallel tree all the way down to educatedguesswork.org. Since those fake records will end up in people's DNS caches this is not likely to go entirely unnoticed if it happens at all often. Moreover, it's not clear exactly what use spoofing records for someone else's domain would do for you. Because of the slow deployment of DNSSEC and end-to-end IPsec applications which want cryptographic authentication of Internet peers use TLS and X.509 certificates. If you manage to reroute DNS, all that happens is that they get to the wrong host and then the TLS certificate check fails. Now, you can certainly argue that people are lax about certificate errors, but you should expect them to be even more lax about DNSSEC errors, especially since most people aren't prepared to validate DNSSEC at all.

In theory, of course, controlling the root zone signing key means that DHS could completely hijack some large section of the domain space. They'd get court orders or otherwise compel some fraction of the root servers to point to their new parallel zone and sign the records with the top-level key. But of course as soon as this got out, people would most likely program their verifiers to ignore signatures from that key and use whatever zone data was in effect before DHS got involved. And of course why bother with anything so technical? The data in the DNS just reflects whatever assignments ICANN and IANA have made. Both organizations are located in the US, so if DHS wants to hijack some zone, they just force ICANN/IANA to reassign the zone and then whoever does the signatures would presumably sign the new data. Of course, you could say people wouldn't accept this, but then why would you believe that they would accept signatures that didn't reflect ICANN/IANA's assignments?

None of this is to say that DHS controlling the root zone wouldn't be symbolically badly received, but that's mostly what it would be, symbolic.

ICANN has decided not to issue .xxx. Stuart Lawley from ICM does not look that happy about it:

ICANN Board member Susan Crawford is also unhappy:

"No centralized authority should set itself up as the arbiter of what people may do together online," Ms. Crawford said in a statement to the board, adding that political pressures played an undue role. "This is not a technical stability and security question."

I mostly agree that this isn't a technical stability question. As far as the DNS is concerned, there's nothing special about the string .xxx, after all. As far as security goes, the only way in which this would be special would be if ICANN intended to monitor that ICM was enforcing the somewhat vague conditions that were proposed for the domain. That's easily fixed by not doing so. That said, the bit about "no centralized authority" being an "arbiter of what people may do together online" is a bit hard to understand, since that's more or less ICANN's reason for existence. Once we've decided that we're going to issue more TLDS and we're not going to do it in a mechanical fashion (first come/first served, auction, etc.), you're pretty much left with some sort of centralized arbiter, which is what ICANN is. This isn't to say that one can't object to the decisions ICANN has made or the way it makes them, but that's different from having a principled objection to them making such decisions in the first place (not that one can't object to that as well...)

Rep Bruce Braley (D-IA)'s disassembly of GSA Administrator Lurita Doan is all over the Intertubes. Before you get to the actual embarassing content, check out Braley's explanation of PowerPoint:

And that during PowerPoint presentations information is projected in slides and usually those slides are reviewedby the person making the presentation to reinforce verbally the images that are displayed on the slides.

It's almost as if Braley just heard of PowerPoint this morning and figures maybe he needs to explain it to Doan...

One of the innovative new homeland security programs to prevent terrorism is the Office of Foreign Asset Control's Special Designated Nationals List (warning: long). Unfortunately, like the No Fly List, it appears to not be quite as specific as one would like:

Tom Kubbany is neither a terrorist nor a drug trafficker, has average credit and has owned homes in the past, so the Northern California mental-health worker was baffled when his mortgage broker said lenders were not interested in him. Reviewing his loan file, he discovered something shocking. At the top of his credit report was an OFAC alert provided by credit bureau TransUnion that showed that his middle name, Hassan, is an alias for Ali Saddam Hussein, purportedly a "son of Saddam Hussein."

The record is not clear on whether Ali Saddam Hussein was a Hussein offspring, but the OFAC list stated he was born in 1980 or 1983. Kubbany was born in Detroit in 1949.

Under OFAC guidance, the date discrepancy signals a false match. Still, Kubbany said, the broker decided not to proceed. "She just talked with a bunch of lenders over the phone and they said, 'No,' " he said. "So we said, 'The heck with it. We'll just go somewhere else.' "

...

Saad Ali Muhammad is an African American who was born in Chicago, Illinois, and converted to Islam in 1980. When he tried to buy a used car from a Chevrolet dealership three years ago, a salesman ran his credit report and at the top saw a reference to "OFAC search," followed by the names of terrorists including Osama bin Laden. The only apparent connection was the name Muhammad. The credit report, also by TransUnion, did not explain what OFAC was or what the credit report user should do with the information. Muhammad wrote to TransUnion and filed a complaint with a state human rights agency, but the alert remains on his report, said Sinnar.

There's an inherent tension in any blacklist mechanism in that it's very susceptible to false negatives, both because the databases are inherently messy and because you don't want some terrorist bypassing your carefully (or not so carefully) gathered blacklist by spelling his name "Osama bin Liden". But the fuzzier the matching the more likely it is that some poor loser gets branded a terrorist. Obviously, any testing procedure has this problem, but since the inherent accuracy of blacklists is so low, you basically have to choose between two unappealing alternatives. And since the penalties for doing business with someone on the prohibited list are so severe (up to $10 million and 10-30 years in prison!) it's unsurprising that financial institutions err on the side of caution.

I do wonder whether Hector Garcia-Molina has any trouble here...

"JOHN 40" (a.k.a. GARCIA MOLINA, Gener; a.k.a. "GUTIERREZ, Jhon";
a.k.a. "HERNANDEZ, John"; a.k.a. "JHON 40"; a.k.a. "JOHNNY 40");
DOB 23 Aug 1963; POB San Martin, Meta, Colombia; Cedula No.
17353242 (Colombia) (individual) [SDNTK]

I'm also glad I'm not named "Mike":

"MIKE" (a.k.a. RODRIGUEZ OREJUELA, Miguel Angel; a.k.a. "DOCTOR
M.R.O."; a.k.a. "EL SENOR"; a.k.a. "MANOLO"; a.k.a. "MANUEL";
a.k.a. "MAURO"; a.k.a. "PAT"; a.k.a. "PATRICIA"; a.k.a. "PATRICIO";
a.k.a. "PATTY"), Casa No. 19, Avenida Lago, Ciudad Jardin, Cali,
Colombia; DOB 23 Nov 43; alt. DOB 15 Aug 43; Cedula No. 6095803
(Colombia) (individual) [SDNT]

Outstanding!

As you may have heard, someone recently inserted a back door into WordPress 2.1.1. What appears to have happened is that the attacker broke into WordPress's servers and modified the distribution:

Longer explanation: This morning we received a note to our security mailing address about unusual and highly exploitable code in WordPress. The issue was investigated, and it appeared that the 2.1.1 download had been modified from its original code. We took the website down immediately to investigate what happened.

It was determined that a cracker had gained user-level access to one of the servers that powers wordpress.org, and had used that access to modify the download file. We have locked down that server for further forensics, but at this time it appears that the 2.1.1 download was the only thing touched by the attack. They modified two files in WP to include code that would allow for remote PHP execution.

What's interesting about this incident is how it was detected. In many such incidents, what's detected is that there is something funny on the systems hosting the code (e.g., the CVS repository in the 2003 Linux kernel backdoor attempt. The relevant change then gets tracked down and studied very carefully. According to the WordPress people, however, what happened here was that someone detected the vulnerability and then they tracked it to an intrusion.

This is interesting because there are two major ways for someone to insert a back door into some piece of open source software:

• Compromise one of the development or distribution servers.
• Make a legitimate change that contains a back door.

The first is easier to do because most systems aren't very well secured and so all you need to do is break in and replace the distribution. However, it's also a lot easier to detect. First, breaking in often leaves signs. Second, the source code typically exists in multiple copies and so eventually the inconsistency gets noticed, especially because it's typically the download servers that are easiest to attack but they can be compared with the main source repository.

The second is harder to do but can be much more effective. You just submit a fair-sized patch to the project that happens to contain a security vulnerability. Most patches don't undergo particularly thorough review, especially on non-security projects, and it's quite easy to hide a buffer overflow or other vulnerability in your code once you get above a hundred lines or so. This is a little more work since you actually have to implement a semi-useful feature, but the bar for that is pretty low on most projects as well. I don't think I've ever heard of a backdoor being inserted this way. It's hard to know if that reflects that nobody does this or just that nobody catches it.

OK, we've got spam and spit (spam over VoIP) and spim (spam over IM). As soon as people actually start using VoIP—and I'm talking end-to-end VoIP where you "dial" a URL—we're going to start seeing phishing with VoIP. What'll that be called? "phit", "phitting"? Somebody make it stop.

UPDATE: Now that I've slept on it, I predict "vishing". In fact, it sounds so familiar I fear I've heard it already.

According to this article Boeing is designing an "Uninterruptible Autopilot System". The idea here is that if the plane is being hijacked you trigger the UAS. Once it's engaged, the plane can't be controlled by the pilot but is remotely controllable from the ground.

It's important to remember here that there are two kinds of hijacking:

• The old style "take me to Cuba" hijacking where you threaten the pilot or passengers to get them to take you where you want, get your demands met, etc.
• The newer 9/11 style hijacking where you take control of the plane and crash it into something.

This seems to be mostly targeted at the second type of hijacking, since the first type depends principally on people complying under a threat and this threat is at least 95% as credible when the pilot is on the ground as if they're in the air with you. You just threaten someone on the plane instead of the pilot. On the other hand, if your objective is to fly the plane into some building, presumably the flight controllers on the ground won't allow that no matter how much you threaten to kill passengers.

That said, it's not entirely clear that 9/11-style hijacking can work even without this technology. If you're a passenger on a hijacked plane and you expect the hijackers to fly it into a building you've got a pretty good incentive to try to take back the plane regardless of what weapons the hijackers have. As has been often observed, 9/11 was successful because people's responses to hijacking were predicated on the assumption that it was the first type—who had heard of the second?

From a security guy's perspective, the interesting question is what safeguards are in place to prevent accidental activation and control by attackers? Imagine you get your hands on the control unit for an aircraft and can somehow get it put into UAS mode. Congratulations, you've got yourself a remote controlled, manned cruise missile. Presumably there are safeguards in place to defend against this sort of attack. Minimally, one would hope that some sort of cryptography is used to limit control to authorized units. The COMSEC techniques here are of course relatively straightforward.

The second thing you would like would is for it to be impossible to remotely put the plane into UAS mode, thus minimizing the damage from any compromise of a control unit/control unit keying material. For instance, the UAS radio receiver could be physically disconnected until engaged onboard the plane.

Even if proper COMSEC techniques are used, there still is a residual risk if it's possible to jam the signal. In order for the system to work, it needs to be fairly sensitive so that any attempt to take over the cockpit triggers it (hence the proposed pressure sensors on the cockpit door). But this potentially enables an attacker onboard to trigger the UAS while a confederate on the ground holds the plane hostage by jamming the control signal. Again, there are techniques to make signals harder to jam (though the authentication techniques you're likely to use make the control channel very sensitive to errors so you'd need a lot of forward error correction).

I'd certainly be interested in hearing more about the design of the proposed system. p

When a young man dies in battle, we all agree that it's a bad thing, but it's generally considered particularly tragic if he leaves a family behind, especially if he has a young child. Apparently, things were somewhat different in Sparta:

In 480 the ephors sent Leonidas with the 300 men of an all-sire unit (soldiers who had sons to carry on their bloodline) and 6700 allies to hold the pass of Thermopylae against the hundreds of thousands of Persian soldiers who had invaded from the north of Greece under Xerxes.

What's interesting here is that it's not that the Spartans thought children were unimportant—quite the contrary—it's obvious they were incredibly important in some impersonal sense. It's just that the attitude seems to have been rather more instrumental.

I'm one of those people who prints out every draft that they need to read for each IETF. This usually takes me an afternoon of going through each agenda manually getting a copy of each draft, printing and stapling. To make matters worse, there's a fine timing issue because the agendas change up until the very last minute. So, if you want a head start you print early but then you need to go back later to get a complete list. This often ends up with missing drafts or printing out duplicate copies. This time I got tired of it and wrote myself a little tool to do the job for me.

The job is mostly simple:

• Suck down the agenda for each WG.
• Scrape through the agenda looking for anything that might be a draft name (i.e., matches draft-[a-z0-9\.-]+-\d\d).
• Fetch each draft from the ID repository (assuming you don't have it)
• Print out the drafts that were successfully retrieved.
• Remember which drafts were printed so you don't print them again.

I did add one bonus feature: I print out a burst/header page for each WG containing the WG name and a checklist of the drafts. This makes for easier sorting (not all drafts have the WG name in the name) and gives you a convenient list of the drafts. Now if I just had some tool to staple them together..

I happened to come across WebMD's Symptom Checker and thought I'd give it a shot. Here's what it offered me when I gave it the symptoms for illiotibial band syndrome:

• Tendinitis
• Bursitis (pre-patellar)
• Gout
• ACL knee injury
• Repetitive motion injuries
• Dislocated knee
• Sickle cell crisis
• Patellofemoral pain syndrome
• Septic arthritis
• Stress fractures
• Chondromalacia patella
• Psoriatic arthritis
• Posterior cruciate ligament (PCL) injury
• Pseudogout
• Knee meniscus tear
• Knee strain
• Lupus (systemic lupus erythematosus)
• Lyme disease
• Obesity
• Osteochondritis dessicans

I also fed in the symptoms of poison ivy on my arm and got:

• Allergic reaction
• Contact dermatitis
• Lice
• Drug allergy
• Narcotic abuse
• Poison ivy, oak, and sumac
• Hives
• Alopecia
• Atopic dermatitis
• Dermatitis
• Dermatitis herpetiformis
• Phlebitis
• Scabies

First, note that poison ivy is an allergic reaction which causes contact dermatitis, which is a form of dermatitis, which just means a skin inflammation. Second, narcotic abuse???? I wouldn't have this drug problem if my lupus didn't hurt so much!

I just finished Dan Simmons's impressive new The Terror. The Terror is a novel based on the 1845-1848 Franklin Expedition to discover the Northwest Passage. Both ships, the The Terror and The Erebus get frozen into the ice off King William Land (actually King William Island) and as the men slowly starve to death they find themselves being stalked by some sort of polar ice monster (no spoilers here, this is all laid out in the first 50 pages). Things just get worse from there (think frostbite, scurvy, rampaging monsters, etc...)

Sort-of spoilers below.

Bay Area burrito classic El Burrito Real just closed its doors. I must have eaten hundreds of burritos there and while I'd seen them made I thought before it went out of business, it would be interesting to see things from the other side of the counter. Cisco, the manager, was kind enough to teach me the basics and let me work a shift last Monday. Plus, I got a nifty shirt. No hair net, though.

The setup at EBR is simple: there's a long line of ingredients on a steam tray. You walk down the line and point to what you want. They pile it on the tortilla and then wrap it all up at the end. This turns out to be the tricky part of the operation, so they teach it to you first. I showed up at 4:30 and Cisco pointed me to a tortilla piled with rice and beans. He showed me how to do the wraps and set me to practicing. After about 50 wraps and more than a few ruined tortillas I was pronounced ready to try making a whole burrito.¹ My first official burrito was for Mrs. Guesswork but then I stuck around and worked the counter for a while. I'm also fully qualified to make tacos and combo plates, so if the whole security thing doesn't work out...

^1. The important things to know here are (1) get the fillings centered on the tortilla (2) once you get the tortilla half-rolled to collect the filling and pull it back into the roll (3) fold the edges of the tortilla back in before you give it one final roll.