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 automatically propagate 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.covered 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:
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 legal.
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 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.
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:
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 and GNU 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 efforts.
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 J2SE 5.
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 diary:
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 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 bindings easy.
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 yet.
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.
Page editor: Jonathan Corbet
Next page: Security>>
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds