LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for May 12, 2005SSH as a worm vectorIt 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 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.
The broadcast flag is defeated - for nowLWN 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:
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
receiver apparatus.
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 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.
A new Harmony ProjectGeir 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 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:
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
at minimum.
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 Inside this week's LWN.net Weekly Edition
|
|||||||||||||