Brunettes, DNS, and Choice Poisoning Attacks

Listening to a science program on the radio about a psychology experiment, shortly to be published in Science, I was struck by the similarity between the result of that experiment and DNS poisoning. It seems humans work in detached asynchrononous fashion, just as the DNS protocol, which certainly would help in the scalability department. Not so surprising, really, when you think of it.

Let’s start out by describing the psychological experiment. (Sadly, I didn’t catch the names of the authors, but they were mostly Swedes, else it wouldn’t have been on radio here.) What they did was to present volunteers with a number of pictures of faces and then let them choose their “favorite” face. After choosing a face, they were handed the photograph and asked to motivate why they had picked that particular face. The twist is that half the volunteers were given the “wrong” face, that is, one they didn’t choose. Now, it turns out that these volunteers were just as good as the ones that did get their own chosen photos, in motivating their choices. For instance, a person choses a brunette, but gets a blonde. That person then motivated the choice by “I’m partial to blondes, since I’m blonde myself”, even though he actually had chosen a brunette. Extensive analysis of responses could detect no difference in the quality of responses between the people who motivated their own actual choice and the people that got a photo different from their actual choice. None (or almost none?) of the “deceived” volunteers seem to have noticed the deception at all.

Ok, I have to admit I have a hard time believing I would fall for this, but a lot of people did, so who knows? But that is beside the point.

Let’s talk about DNS poisoning. What happens is that when one DNS server asks another DNS server to resolve a domain name into an IP address, it does so asynchronously, i.e. it doesn’t wait for an answer. Once the upstream DNS server has an answer, it sends it as a new communication to the requesting server. DNS poisoning, as an attack, is based on that you send such a response to a DNS server, and it will accept the response even though it never actually sent the corresponding request. Why? The answer is scalability and performance. If the querying server needs to wait for the response during the same connection, it will severely hamper it, since replies can take a long time. If, on the other hand, it would need to match received replies against a list of sent requests, it will also need extra resources, and it will inhibit scale-out architectures, like setting up a number of parallel machines (each machine would need to communicate its outstanding requests to all the others in a group). In other words, having a disconnect between requests and replies is good architecture. Except, of course, it makes for certain vulnerabilities.

Isn’t the similarity striking? I mean, the human brain is very slow, but compensates for that by being massively parallel. Scalability is everything. It can only be massively parallel and economic in use if it can avoid having to keep a common state for all activities. That is, if it can initiate actions against the external world, and then forget about them, it saves a lot of resources and processing power. Once the response arrives, the question that caused the response can be deduced and you won’t even notice that you didn’t actually remember ever having initiated the entire thing.

Put in other words, getting that photo handed to them, caused the test persons to deduce that they chose that photo, and saddled them with the task of, post hoc, constructing the reasons for it. Good information processing design. But not ideal for a number of other reasons, mainly security.

Could we call this psychological phenomenon a “choice poisoning attack”?

Leave a Reply

Your email address will not be published. Required fields are marked *