It has been quite some time since a serious Unix/Linux worm has made its
way through the Internet. Such worms seem difficult to write, but few
people would argue that they are impossible. To many, it is just a matter
of time until a Linux-based worm gets loose. This event will slightly
reduce the level of smugness in the community, and greatly reduce the
credibility of claims that Linux is a more secure system. It is not
something to look forward to.
Meanwhile, a crucial security-related component of many systems is SSH, usually in the
form of OpenSSH. Even the most severely
locked-down systems will often have an SSH port open. So any sort of
compromise which involves SSH is seriously frightening. Now, a paper [PDF]
written by four MIT researchers (and commented
on by Bruce Schneier) describes how SSH could be used as a vector for
worm attacks. This threat appears to be real, and deserves attention from
anybody responsible for the security of network-attached systems.
SSH maintains a per-user "known hosts" file, where it stores the public keys of
remote systems it knows about. This file enables SSH to issue that
obnoxious warning whenever a host key changes; its purpose is to help
prevent "man in the middle" attacks. It may be possible to redirect an SSH
connection via a DNS compromise, but it will not normally be possible to
keep SSH from noticing the switch. This is a good thing.
The known hosts file, however, is a handy little database listing all of
the systems a given user connects to. If that user's account is
compromised, the known hosts file becomes a list of logical systems to
attack next. If the user's password is known, chances are good that it will
work on at least some of the systems found in the known hosts file. If the
user has set up no-password, key-based logins to some of those remote systems,
knowledge of the password will not be necessary. The result is that a
purely local exploit could use the SSH databases and protocol to
itself across the net.
It's worth noting that a worm could be written today using this technique
combined with, say, the just-announced core dump vulnerability. Sooner
or later, somebody is going to go for it.
The paper's authors are trying to collect more data to generate more
metrics on how extensive the "web of known hosts" is; to that end, they are
asking people to contribute their known hosts files. See this page for more
information. Note that their data collection process involves running a
perl script (supplied by them) as root. One assumes that these researchers
are trustworthy, but one would be well advised to look over that script
carefully before running it anyway. Twice.
The authors also point out that OpenSSH 4.0 includes a defense mechanism in
the form of hashed known hosts files. By using a hash rather than the
remote system's name, OpenSSH is able to verify remote keys without
actually storing a list of remote system names. This behavior must be
explicitly turned on, however (by adding a "HashKnownHosts yes"
line to the SSH client configuration file) and existing known hosts files
must be converted to the new format. A couple of scripts have been
provided to help with the conversion process.
The community is lucky to have received advance warning of this issue.
Now, however, it is up to us to act on that warning. With some diligence,
it may be quite a few more years before we see a serious Linux-based worm.
Comments (24 posted)
the broadcast flag
rule in November, 2003. This rule, adopted by the U.S. Federal
Communications Commission, mandated that digital television systems
implement and honor a flag, embedded within the TV signal, which would
forbid copying or further redistribution of the content. This rule, in
effect, forbids the creation of free television demodulator systems. No
source-available system could implement the broadcast flag in a way which
meets the "robustness rules" set out by the regulation.
The DC Circuit Federal Court of Appeals made short work of this rule; the
full ruling is available in
PDF format. The decision is clear and narrow:
We can find nothing in the statute, its legislative history, the
applicable case law, or agency practice indicating that Congress
meant to provide the sweeping authority the FCC now claims over
Thus, the broadcast flag is dead, because the FCC has no authority to
make that particular regulation. The court offers no opinion on whether
the concept of a broadcast flag is defensible or not - it was not asked to
consider that issue. All that has been decided is that the FCC has no
authority to give the entertainment industry veto power over our gadgets.
For the time being, digital TV systems implemented with free software are
The next move in this game is obvious: the entertainment industry will go
to Congress seeking a law which either (1) gives the FCC the authority
to regulate devices which are not actually transmitting or receiving
signals, or (2) implements the broadcast flag requirement directly.
Cory Doctorow has claimed
that the industry will not succeed in this goal:
The next move here is that the studios will take this to Congress
and try to get a law passed to make this happen. No chance. They
got ZERO laws passed last year. This year the best they've been
able to accomplish is making it slightly more illegal to videotape
movies in the theatre.
The fact is, elected lawmakers are not suicidal enough to break
their constituents' televisions. Watch and see: over the next year,
we're all going to roast any lawmaker who so much as breathes the
words "Broadcast Flag" in a favorable tone.
This view is probably overly optimistic. Experience says that the
purveyors of ideas like the broadcast flag never give up; they bring their
proposals to Congress over and over until the opposition has, finally, been
worn down. The broadcast flag may well be defeated next year, but it will
be back the year after that. Until elected representatives (and the wider
world) understand why things like broadcast flags are such a bad
idea, we will have to keep fighting this battle.
Comments (7 posted)
Geir Magnusson Jr. sent out a
proposal for "Project Harmony" which would create an open source
implementation of the Java 2 Platform, Standard
Edition (J2SE) version 5 and a "community-developed modular runtime
(VM and class library) architecture for independent implementations
to share runtime components, all to be available under the Apache License, v2.
The proposal calls for "a broad, collaborative community of
contributors," and there is an impressive list of interested parties
in Magnusson's proposal. We talked with Magnusson about the project,
the interest which has been shown so far, and whether Sun had been
approached to cut out the
middleman and simply open source their implementation of J2SE to save
everyone the hassle of doing it again.
Magnusson said that the project "was a long time coming," but
there was not a specific catalyst that made the group decide that now was
the time to move forward. "Finally, we just decided that it's
time." He also emphasized that Harmony is about "building
communities that can collaborate...we're looking at inviting everybody who
wishes to participate."
With regard to Sun and open source Java, Magnusson said that "we
respect Sun's right to make their decision [regarding licensing]."
We also wondered whether Magnusson or someone from the Harmony project had
approached Sun to confirm that the company isn't planning on an open source
version of Java. Magnusson said that Sun had been made aware of the
project, but that he "won't say we've gotten an assurance that
they're not going to do this in the next two years."
Sun's Graham Hamilton has
also said that Sun will probably participate "at some level,
although most of our efforts will continue to be focused on building Sun's
reference implementation of J2SE." Although Hamilton puts a damper
on the endorsement by adding:
I am not entirely sure if the world
really needs a second J2SE implementation, but at the same time I am also
glad to see that all the effort we put into getting the rules and the
licensing issues straightened out is actually proving useful!
Bruno F. Souza, "the number
one Java Evangelist in Brazil," and another individual listed in the
Harmony proposal, also comments on Harmony in his blog and on the need
for a second implementation:
In this, Hamilton is wrong. How important would be J2EE if we had a single
application server? For a long time now the Java Community needs another
J2SE implementation. At this point we don't even have a proof that the JCP
specs are valid! In a recent talk with James Gosling at Café Brasil, while
we discussed Kaffe and Classpath, James commented on how important a clean
room implementation was for this very reason. The work of the FSF on the
Classpath and GCJ projects, and the teams of Kaffe, JamVM and others, are
all validating parts of the spec, what only strengthen our whole
community. The fact that these projects exists should be seen as positive
and should be supported and cherished by all developers, and not ignored
like they have been for so long.
Not only that, but another implementation promotes competition and foster
innovation. An open source implementation helps in research, discussions
and even in the evolution of the Compatibility Kit. Sun recognizes the
value of that, that's why Mustang source code is now available on an
ongoing basis, and why Sun proposed recent licensing changes to its
implementation, to promote this very things. But this is not enough. Sun's
licensing changes get to the edge of the water, but although noticing that
the water is cold can be relaxing and beneficial, it don't really give you
any of the benefits of swimming. I have already discussed elsewhere other
reasons why I think an open source implementation of Java is needed.
There is certainly plenty of need for an open source Java in the open
source community. It's already been commented on, several times, that OpenOffice.org
2.0 has Java requirements that may pose problems for distributions that
don't ship Sun's Java due to license problems. There is also the question
of Java on operating systems and/or hardware architectures not supported by
Sun. Magnusson agreed this was a "personal driver" for his
interest in the Harmony project.
Of course, there are already efforts underway to create open source
implementations of Java, such as Kaffe
Classpath. Kaffe is an implementation of the Java virtual machine and
class libraries to provide a Java Runtime Environment (JRE), while GNU
Classpath is a project to create the core class libraries for use with
virtual machines and compilers. There is also the GNU Compiler for Java (GCJ) and many other open source
However, there are a few areas where Harmony may be more desirable in the
long run. Firstly, Magnusson stressed the importance of certification for
the Harmony project, to ensure compatibility with Sun's J2SE 5. Secondly,
as an Apache project, the group may be able to draw from a wider group of
contributors than Kaffe or other projects -- particularly from companies
that would like to see a fully-compatible open source implementation of
Harmony seems to be getting quite a bit of interest already. Dalibor Topic,
a contributor to both Kaffe and GNU Classpath, is one of the other
individuals who have signed on to the Harmony proposal. He explains his
interest in the project in his Advogato
What the hell am I doing there, then, not being an Apache? Well, two
things: a) trying to help bring ASF and FSF closer together, and ASF using
and contributing to FSF's class libraries would be a pretty good thing to
happen no matter which path towards a runtime they chose, and b) the ASF
can reach a wide audience among developers programming in the Java
programming language that so far has either not heard, or been skeptical
about Free Software runtimes based on GNU Classpath. For whatever reason
the ASF seems to evoke much less fear and terror in some circles than the
FSF, which may make working with those circles through the ASF easier.
Whether the Harmony, GNU Classpath, Kaffe and other projects will be able
to sort out licensing is another question. We asked Magnusson about the
licensing hurdles, and he said that they are "working to fix
licensing issues" and noted that the project was trying to solve
licensing problems "in parallel," since "licensing
discussions can bog down anything."
There are also those who might prefer to forget Java altogether and
concentrate on something like Mono instead. While Mono is an interesting
technology, it's not always a substitute for Java and may not meet
everyone's needs. It also seems unlikely we'll see broad support for Mono
from all quarters soon, judging by Havoc Pennington's comments on the Java and
Mono discussion with regards to Harmony:
I believe we have legitimate and non-evil reasons why we [Red Hat] can't
ship Mono. And I think open source Java looks plausible and a lot nicer
than C; Java and Classpath will even run on Mono, and if C# becomes more
viable later, experiments such as Graydon's or the Lucene port show that it
isn't hard to do a Java to C# conversion. And guess what, we need open
source Java in the desktop anyhow for OpenOffice.org and the browser plugin
I don't know what people expect Red Hat GNOME developers to do. We can't
roll over and say "OK, we'll start hacking in C#, even though we don't see
a path to shipping any of the stuff we're hacking on" - does anyone
seriously expect that?
...I'm not trying to exhaustively belabor the Java vs. C# technical
comparison but I am trying to point out that Java has a hell of a lot going
for it including open source developer tools and libraries and huge
momentum (largely open source) on the server side. Java 5 has some cute
language features, too, and Tromey has shown how to make native code
To get a general idea how long it might take for a group to implement J2SE,
one might look at the Apache
Geronimo project, which is an implementation of the Java 2 Platform, Enterprise Edition
(J2EE). The project started in August 2003, and became an official Apache
top-level project in
May 2004. According to Magnusson, the Geronimo project is now working
to pass Sun's TCK for J2EE 1.4, though it isn't clear how much more time
will be required for it to reach full compatibility.
For those interested in participating, Magnusson has sent out a FAQ about the project which
includes instructions on joining the development mailing list. The project
is not yet listed on the Apache Incubator site
If Harmony is successful, which looks quite likely given the interest it
has stirred already, it will be quite beneficial to the open source
community. While it would be much easier if Sun simply provided an open
source implementation, the community has the tools needed to do so.
Comments (45 posted)
Page editor: Jonathan Corbet
Next page: Security>>