Leading items

The trojaning of mICQ

The story, it seems, is this: Rüdiger Kuhlmann, the maintainer of mICQ, had a disagreement with Martin Loschwitz, the maintainer of the Debian mICQ package, on how that package should be built. Mr. Kuhlmann complained that an old version of mICQ was shipped, that it contained bugs which had been fixed upstream, and that his name had been removed from the copyright file. The disagreement had apparently been going on for a while.

Mr. Kuhlmann decided that enough was enough, and he was going to take some action. As of mICQ 0.4.10.1, the code will, when built for the Debian distribution, print out a message which says some unflattering things about Mr. Loschwitz and encourages use of a different version; the program then exits. In other words, when built for Debian, mICQ thumbs its nose at the user and refuses to run. To help ensure that this code got into the official Debian version, it was written in an obfuscated manner, set to trigger only after February 11, and only if it was not being run by Mr. Loschwitz. For the curious, here is a posting containing the code in question.

In response, Mr. Loschwitz called for the removal of mICQ from the Debian distribution and started a generally impressive flamewar. After some time, the two parties actually started talking to each other; summaries from Mr. Kuhlmann and Mr. Loschwitz have been posted. The resolution involves fixing the packaging issues and the removal of the anti-Debian code. The mICQ package will also be removed from Debian until a security audit is performed and a new maintainer is found. The situation would appear to have been resolved.

The whole thing has, however, left a bad taste in the mouths of many Debian developers. According to some, Debian was subjected to a trojan horse/denial of service attack, and they are not happy about it. Mr. Kuhlmann denies this, of course ("In fact, I only added dead code. It was you who #ifdef'd it in - not knowingly, but anyway."), but this code, even described in more friendly terms ("easter egg," say), is the sort of thing that does not often happen in the free software world. Free software users like to think they have a bit more control over their systems than that. (It's not completely unheard of, though - GNU emacs used to greet Symbolics users with the message "In doing business with Symbolics, you are rewarding a wrong.")

Much of the discussion was concerned with what Mr. Kuhlmann could have done with this piece of stealth code. Such speculation is a bit off-topic, given that, as far as anybody can tell, there are no evil or destructive trojans coded into mICQ. In the context of a wider discussion, however, this episode does raise a scary issue. The mICQ code was slipped into a major distribution, seemingly with great ease. The code was relatively harmless, but, next time, it might not be. Access to source code decreases our vulnerability to this sort of attack; proprietary software, after all, can have anything in it. It is hard to imagine anybody being able to hide a flight simulator inside a free spreadsheet application. But anybody who believes that having the source makes us invulnerable to this kind of trojan is clearly mistaken. With suitably clever coding, great nastiness can be hidden in seemingly innocuous code. The resources to audit all of our code at the level of detail required to find small trojans simply don't exist.

Perhaps, in the future, tools like the Stanford Checker can be turned to the task of finding suspicious code in source distributions. For now, though, we have to remain on our guard. This kind of thing will happen again, and, next time, the results may not be so benign.

Comments (14 posted)

The Embedded Linux Consortium Platform Specification

The Embedded Linux Consortium has announced the launch of the ELC Platform Specification (ELCPS). The ELCPS was developed with input from numerous companies including IBM, LynuxWorks, Panasonic, Samsung, MontaVista, K Computing, Red Hat, WiPro, Hacom, and FSM Labs; its purpose is to encourage interoperability across embedded Linux systems. Those wanting the details can grab a copy of the specification in PDF format; for everybody else, here is a quick summary of what the ELCPS is trying to do.

The ELCPS is heavily influenced by the Linux Standard Base, POSIX, and the Single Unix Specification. However, it restricts itself to the programming environment (and, in particular, to which functions should be available) and is not concerned with the user experience side of things. It is assumed that the user of an embedded system will not be worried about which shells are available.

Of course, not all embedded systems are the same; the capabilities needed by a web-enabled phone handset or point of sale system will be different from, say, an elevator controller. So the ELCPS defines three levels of environment, each of which has different requirements.

• The minimal system environment is the bottom end; systems running in this mode may not deal directly with users, and may not even need a filesystem. ELCPS-compliant systems at this level should provide the basic C environment, signals, basic locking, and threads - but they do not necessarily have to be able to run more than one process.

• The intermediate system environment adds several things, including filesystem support, asynchronous I/O, dynamic libraries, multiple processes, inter-process communication, wide character support, and more.

• The full system environment is "essentially equivalent to a LSB 1.2 system," except that there is still no specification of which programs should be available. At this level, the environment should provide full floating-point math support, job control, networking, basic shell functions, system logging, password functions, and so on.

There are a couple of interesting omissions from the first version of the ELCPS. One is in the area of real-time programming. According to the specification, there is no clear standard for real-time programming in the Linux world. The LSB does not specify real-time functionality, and the POSIX real-time standards are still in flux. The specification makes no mention of the fact that serious real-time Linux programming tends to be done by way of RTLinux or RTAI, neither of which is standard in any way, but that situation has to have discouraged attempts to standardize real-time Linux functionality as well.

The specification also had to punt on thread support, since real POSIX threads implementations for Linux are still hard to come by. That situation should be rectified when the 2.6 kernel, with its greatly improved threading support, becomes available.

The Embedded Linux Consortium will eventually set up a certification program for ELCPS compliance.

The ELCPS is another sign that the embedded Linux community (and Linux in general) is growing up. Embedded Linux, in particular, has been subject to the sort of fragmentation that creates worry among technology pundits and corporate managers; the ELCPS should help those people to worry a bit less. By using embedded Linux, manufacturers are already able to free themselves from proprietary platforms and royalty payments. The ELCPS should make these manufacturers more confident that they will not find themselves locked into a single vendor. And that, of course, should be good for the Embedded Linux market as a whole.

Comments (3 posted)

Lindows sells virus protection

Lindows.com has announced a new offering for its distribution: for $29/year, Lindows users can run the new "VirusSafe" utility which protects the system from viruses. It seems like a reasonable product: other desktop systems have had anti-virus applications for years. And, apparently, virus protection is at the top of the list of features requested by Lindows users.

There's only one problem: Linux viruses are rather hard to find. In fact, the list of "in the wild" Linux viruses that have actually infected systems is short - there are none. The case of SirCam infection via Wine is, if anything, the exception that proves the rule. It demonstrates how far one has to go to infect a Linux system - and, even then, the virus was not able to propagate.

A Linux-based virus is not impossible; one could imagine, say, a hostile email message which, taking advantage of a fetchmail buffer overflow, managed to spread itself over the net. But the fact is that this sort of thing simply does not happen. Linux systems are harder to break into, and they are better at containing the effects of breaches that do occur. When a program is found to allow unpleasant things like arbitrary command execution (as in the recent vim modeline vulnerability), it gets fixed in a hurry rather than being presented as a feature.

So we thought it might be worthwhile to ask Lindows exactly what it is defending its users against. What virus (or other) infections would have been presented by running VirusSafe on a target system? Unfortunately, Lindows did not respond to repeated inquiries, so we are left having to guess.

Lindows, perhaps, is defending its users against the fear of running systems without virus scanners installed. It is difficult to explain to users why they probably do not need explicit virus protection; and, besides, it seems they are willing to pay for that protection whether they need it or not. As a business plan, it may make some sense - as long as you don't mind selling your customers something they almost certainly do not need.

Comments (24 posted)