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
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 has announced
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
- 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.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
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
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
Comments (24 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: U.S. cybersecurity plan; new vulnerabilities in mailman, nethack, OpenSSL, PHP, ...
- Kernel: Synchronous signals; <tt>SLAB_KERNEL</tt>, IDE changes, more driver porting articles
- Distributions: A Knoppix for the masses FAQ, Debian Project Leader Elections, Lycoris Linux at Walmart
- Development: The Plone Information Management System, OMNI 0.7.3, PyKota 0.95,
Nemein.Net 1.8.4, Zope 2.6.1, Twisted 1.0.3, ecasound 2.2.1,
JACK Rack 1.4.0, Galeon 1.2.8 and 1.3.2, Netscape 7.02,
Gimp 1.3.12, Bluefish 0.9, Blackdown J2SE 1.4.1-01, Maxima 5.9.0.
- Press: Asian Open Source Centre, Xbox Linux group seeks Microsoft seal,
CodeCon 2.0, FOSDEM wrap-up, IBM licenses Qtopia for PDAs, BASIC
- Announcements: Linux Summit 2003, PyCon 2003, First OpenOffice.org Conf,
GUADEC 2003, New Security Paradigms Workshop 2003 CFP,