Imagine you have a network product, perhaps a router let's say, and you've crafted a feature you think people might like. You might embed something in the documentation about it or perhaps even enclose a glossy brochure with the product. Alternately, you might want to just sniff network traffic and, about once every eight hours, redirect a randomly selected HTTP (you know, the Hyper-Text Transfer Protocol, the protocol used to browse the Web) session to an ad for your product.
A company that I'll call Company X just started doing this with one of their wireless routers.
The intent is obviously to sell a product to home users. However, commercial users might also install this product or one like it. Lots of people use computers. Lots of people use networks. Lots of people use wireless routers.
Imagine, if you will, a carefully crafted and meticulously implemented system which uses a wireless network to exchange information. It's designed to run in a fairly stable environment, so it doesn't do a whole lot of error-checking or second-guessing. It does, however, use HTTP to transfer data.
So in this system, every eight hours a randomly selected device from a set of devices will receive a Web page that's an ad instead of snagging useful, business-related information. The results can range from amusing (maybe it's an airport departure schedule listing) to inconvenient (maybe you're in a hurry at the airport) to fatal (maybe it's a piece of medical equipment).
The idea -- that it could be okay to reroute a user's request without any kind of permission or confirmation -- is a strange one. What if the user was trying to communicate with a bank or otherwise had private or secret information in the HTTP request?
Of course, you can conveniently opt-out. As always, opt-out is a cop-out. It's like the police telling you that they can't arrest someone for assaulting you until you tell them to stop hitting you. But that's not the scariest part.
What's really scary is how the opt-out feature works. When you click on a link in the advertisement, your router stops redirecting you to the ad. And how does it do this? The server sends a packet that changes that particular configuration option.
In a Usenet post, a representative of Company X explained how to change the configuration option locally, in case your firewall blocked the special message that changes the configuration setting. By default, the machine at the Web site for Company X can change the configuration of your router if it knows where your router is.
That's right. Something can be sent to your router from outside of your network which will change its configuration. How many other settings can be changed remotely? Can you disable this? These are hard, and as of now, unanswered questions.
So how do reps for Company X answer this criticism? The initial response is probably not what you might have hoped for. In the same Usenet post in which the remote configuration "feature" was disclosed, a Company X employee provided a few details.
One detail was that information gathered when you registered went to a third party, rather than to Company X. A second item was that the design goal was to provide ease-of-use for product registration.
So, the users of your router experience one unexpected redirect every eight hours. Until you tell your router to stop doing it. And even then, if you're on a secure network, you may have to manually go in and reconfigure the router. Instructions for this were posted to Usenet, but apparently nowhere else.
This post was deleted from the archives about two days after it was first posted to Usenet. It was replaced by a shorter message explaining that Company X agreed an issue existed and that a firmware update fixing this would be made available shortly.
This idea was approved once. The fact that someone in control thought this was a good idea once means that it might happen again.
Without knowing why and how this happened (or the intentions behind this kind of reasoning), I'm not sure what to think about statements that the issue is resolved. Do the people at Company X see the same issue that I do? Are software actions that go beyond the advertised intent of software merely an ease-of-use issue?
This highlights that users really need to be able to trust their hardware. The traditional assumption is that hardware is trying to do what it's supposed to do -- conform to specifications, route packets, store data, whatever. All of the reliability features of the Internet depend on some degree of good faith. Just as VeriSign's SiteFinder caused a certain amount of technical trouble, Company X's ad-routing feature raises some issues. The worst part for users is the difficulty of working around such a feature. If I send an HTTP request to a site and the request doesn't complete, the TCP/IP software on my computer is supposed to know that the request failed so it can try to resend. And it won't do this if the router gives it bad data.
If it's possible that hardware might perform a questionable act, then users need a way to verify that the hardware is performing the acts that they bought it for. That pretty much means reviewing the source code for the router's firmware -- the software it has recorded on a little chip, which tells it what to do.
Ken Thompson did a wonderful presentation once, titled "Reflections on Trusting Trust," in which he demonstrated that you cannot trust code that you don't have complete control over. His demonstration involved building a C compiler which introduced a backdoor into a system-authentication routine. You might think you could just check the compiler source, but you see, the code also inserted itself into the C compiler whenever it found itself working on the compiler. As a result, the code could be removed from the compiler and an inspection would reveal nothing suspicious.
Consider the implications of this for a router. It has code to load new firmware software. How do you know that this code is trustworthy? You don't. You can't. The only defense you have is the assumption that router vendors are trustworthy.
But, then, if vendors were always trustworthy, you wouldn't need to examine the code in the first place.
This week's action item: Ask a handful of network technicians what they would think of a router behaving in this way. Is the response generally positive or negative?
- Read "Thoughts On Winning An EFF Pioneer Award" and ponder the question, "What if censorship is in the router?".
- In the "'Net threats" series, learn how viruses can overwhelm a router and cause HTTP request misdirection (developerWorks, October 2001).
- Review "Information assurance powwow" for a security model that discussed guidelines for router security (developerWorks, August 2001).
- Visit the developerWorks Tivoli collection, a great place to start for resources on network security.
Peter Seebach would like to be able to trust hardware manufacturers' software, but sometimes their misguided actions speak louder than their apologetic words. If you'd like to talk about product trust, you can reach him at crankyuser@seebs.plethora.net.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
