Geoff Chappell - Software Analyst
Although in principle any given software can be reviewed in its entirety for coding defects, in practice something prompts the analysis. Usually, the prompt is an observation of unwelcome behaviour in the software. The search for defects is then confined to just the one (or more) that will explain that particular observation. For the case at hand, the observation of unwelcome behaviour was made by someone else to someone else before being brought to my attention through yet another someone else.
Someone purporting to be named Phil Bucking, with an address at Yahoo, sent e-mail to Richard M. Smith, president of Phar Lap Software and a well-regarded expert on Internet security. The e-mail is primarily concerned with America Online (AOL) and its AOL Instant Messenger (AIM) software, but in connection with Microsoft (MS) and its MS Instant Messenger software.
In this first e-mail from Phil Bucking, the key allegations seem to be that:
Support for the allegations was offered in a second e-mail from Phil Bucking. This e-mail deconstructs as:
The presentations, taken at face value, may serve as keys to focus an analysis of the AIM client software on just those parts that are relevant to the observed behaviour. No analysis can be considered to be near to success until it explains all the reliable observations.
By contrast, the interpretations are not to be relied upon at all, but are to be tested by the analysis.
Especially suspect is the assertion that the AIM client software does actually execute at least some of the observed data packet. As his experimental method, the writer changed some of the packet and saw that “the execution of AIM changed in a corresponding fashion.” Without details of the changes made to the packet and of the effect this had on the AIM client’s execution, there is no inference at all that the AIM client actually executed anything from the packet. When bytes are changed in data given as input to any code, a change in behaviour is only to be expected. Why else give any input? A change in behaviour from a change of input data certainly doesn’t mean that the data got executed.
Indeed, nowhere in either e-mail from Phil Bucking is there any clear expression of why the writer believes that there is a buffer overflow bug, let alone that the given data packet shows this bug being exploited by AOL to execute downloaded code.
Controversy followed Richard Smith’s observation that the e-mail from Phil Bucking, though it purported to come from a Yahoo address, had come through a proxy at Microsoft and had presumably originated inside Microsoft. The e-mail was clearly much more closely related to reports of a dispute between AOL and Microsoft concerning Instant Messaging (IM) than Phil Bucking had suggested.
The story of this correspondence’s apparent connection with Microsoft was taken up in the New York Times. On 13th August, an on-line article Accusations fly in latest twist to Microsoft/AOL saga by Christa Degnan quotes Rob Bennett, director of marketing at Microsoft Network (MSN), as saying “it is not clear if the e-mail was generated from Microsoft” but that “if it was, it was the action of an individual and not anything sanctioned or in line with our policies.” (The given link is where the article was published at the time, but it seems to be invalid now.)
On the subject matter of the e-mail, the article provides some quotes that invite a return after the facts, such as existence of the alleged bug, are established. Bennett, at MSN, seems to be at ease repeating the allegations in the e-mail, and offers the opinion that the dubiousness of the story’s source “really doesn’t excuse AOL’s actions of putting its users at risk.” From Tricia Primrose for AOL: “It is important to recognize this is a fake story about a fake e-mail about a fake issue.”
Neither Bennett nor Primrose come out of this with any credit. Say what you will about Microsoft, especially about its record of honest disclosure, but this story provides yet more support for anyone’s suspicion that Microsoft’s competitors would be as bad, if not worse, if given half a chance.
A particular point to understand in this controversy is that Microsoft has developed its own Instant Messaging (IM) software, named MSN Messenger Service. In the IM market, Microsoft is the latecomer. Users who seek IM facilities will most naturally register with AOL, which appears to have developed the concept and certainly offers the largest and best-established community of IM users. To compete, Microsoft’s IM client software must give Microsoft’s IM users full access to the many IM users who have already registered with AOL.
Those AOL users run the AIM client software, which talks across the network with AIM server software. Here, talk means an exchange of data packets that the client and server software each interpret according to some protocol. Given that the software at both ends is written by AOL, the protocol can be whatever AOL has cared to design.
The job of giving Microsoft’s IM users access to AOL’s IM users is therefore the job of writing the MSN client so that it can talk with an AIM server according to the same protocol that the AIM server understands when talking with an AIM client. Microsoft’s MSN client must mimic AOL’s AIM client, almost as if the AIM server should not know the difference.
Such mimicry is complicated by AOL’s having apparently not published any description of the AIM protocol, at least not to Microsoft or not in sufficient detail for practicable development of a substitute for the AIM client. In terms that some at Microsoft will surely recognise, though perhaps only with a sense of irony, Microsoft has given itself the work of cloning the AIM client from AOL but has the problem that AOL has not documented all the AIM client’s interfaces.
To discover some usable approximation to the AIM protocol as actually designed and implemented by AOL, Microsoft may have conducted experiments. The idea would be to watch the exchange of data across the network during a variety of AIM sessions, hoping to discern patterns and eventually to infer what interpretation AOL’s software at each end places on all the data packets seen to have been sent and received. Some, and Microsoft may be among them, have been known to call such examinations reverse engineering, often dismissively.
Was Phil Bucking, if that be a real name, a Microsoft programmer engaged in reverse engineering the AIM protocol for use by Microsoft’s own Instant Messaging software?
There are certainly many points of interest in the allegations and also in the reported reactions by both AOL and Microsoft. If software analysis is to provide any clues—and better yet, authority—then a good way to start must be to look for the buffer overflow bug that Phil Bucking starts his allegations with.