[LWN Logo]

 Main page
 Linux in the news
 Linux History
All in one big page

See also: last week's Security page.


News and Editorials

SSH Communications opens SSH trademark issue. This week, Tatu Ylonen opened up a trademark issue involving terms "ssh" and "secure shell". He sent notes out to two public mailing lists, including this note, posted to the openssh-unix-dev@mindrot.org development list, and this note to BugTraq. In them, he requests that the OpenSSH and ScanSSH projects cease to use the string "SSH" as part of their product names.

[Editor note: We have confirmed that the second posting was sent to BugTraq, but rejected by the moderator due to lack of relevance. ScanSSH author Niels Provos reports he never received a copy of the note before it was posted publicly to NewsForge. He also stated that ScanSSH was created in September of 2000 in order to allow an assessment of the adoption rate of the SSH 2 protocol and he was never made aware of any IP issue at the time.]

You'll find additional coverage and reader postings on this issue on both Slashdot and LinuxToday. In addition, you'll find letters to the editor on the topic already in this week's Letters to the Editor section.

Two opposed viewpoints are represented in these community exchanges. On one hand, many people consider Tatu's notes to have been politely worded and are sympathetic with confusion caused by multiple products containing the word "SSH". They feel his request for name changes is reasonable and have already moved forward to suggesting alternatives (SHH, FRESH, ESH, Secure Telnet, ...)

On the other hand, many people don't consider the name change request reasonable, regardless of the wording (and the politeness of the wording can be argued if you look at statements like, "OpenSSH is doing a disservice to the whole Internet security community by lengthing the life cycle of the fundamentally broken SSH1 protocols", which is not particularly polite, nor necessarily accurate). The arguments on their side include:

  1. The word SSH is used both to refer to the protocol SSH as well as to products from SSH Communications. Trademarking the name of a standard is a tricky business; it can be viewed as an attempt to monopolize a standard, a bit of a contradiction in terms.

  2. SSH Communications has waited a long time before coming forward to enforce their trademark. Their registration of "SSH" dates back to 1996, yet products such as TGssh, authored in 1997, were never asked not to use the name.

  3. The license for ssh 1.2.12, upon which OpenSSH is based, states, "Any derived versions of this software must be clearly marked as such, and if the derived work is incompatible with the protocol description in the RFC file, it must be called by a name other than 'ssh' or 'Secure Shell'". OpenSSH is compatible with the protocol descriptions, therefore this license can be read to have granted them the right to use the terms 'ssh' and 'Secure Shell'.

So which is it? A reasonable request that ought to be granted to prevent legal wrangles? Or an unreasonable attempt to punish well-founded competing projects by restricting them from using the name of the protocol that they implement in their products?

For the good of the community, we, of course, would rather see some compromise between these two positions that would result in all of us ceasing to wrangle about it and getting a chance to move on with developing better software and improving security. The search for such a compromise is difficult, though, given the strong emotional reactions that are cropping up on both sides, at least initially.

So let's look at a couple of possible scenarios and their long-term impact.

  1. First, imagine that the community reaction against trademarking the name of a standard protocol is strong enough that SSH Communications decides to drop their request and not to pursue legal action. In this case, the status quo continues. SSH Communications continues to, in their belief, potentially lose customers due to the confusion between the OpenSSH and SSH Communications products.

    Unfortunately, we don't actually believe that SSH Communications is losing customers due to the confusions between the two products but instead due to the well-understood differences between the products. From what we have seen, the people who choose to use OpenSSH instead of SSH Communications SSH do so because it is Free Software. The license for SSH Communications SSH makes it free to use and distribute on BSD and Linux platforms, and for non-commercial use on other platforms, but restricts commercial usage on other platforms. That makes it "not-free" and people have a right to vote against such a license by using an alternative.

    In addition, the history of licensing changes to SSH Communications SSH should be enough to give pause to any company that is considering using it. The license has been opened, closed, and opened again over the years. Do you want to bet your company on a product whose license might change again next year? With the release of SSH Communications SSH 3.X?

  2. Second, imagine, instead, that OpenSSH and ScanSSH and all the other existing programs decide to accede to this request and change their names. How will you find these programs under their new names? Can they use the term "SSH" as a keyword? Can they describe their products as compatible with the "SSH" protocol?

    What, indeed, will the impact be on the standardization process for the SSH protocol? It must be considered important for SSH Communications for the SSH protocol to be adopted as a standard. Providing products based on an acknowledged standard is an important part of their company's worth and reputation. Right now, the SSH Protocol is currently under review by the Internet Engineering Task Force. We spoke with Bill Sommerfeld, currently the working group chair. In this note, he provides links to information about the IETF standards process and touches carefully on the impact of the SSH trademark issue. "In practice, IETF working groups tend to "engineer around" troublesome IPR [Intellectual Property] issues; for instance, the SSH version 2 protocol was changed to use DSS instead of RSA to avoid the (now expired) RSA patent. I can't predict how the working group will react to this -- I only know that it will slow things down. Needless to say, added delay in the standards process does not help the end user."

    The trademark dispute is potentially impairing the standards process which should be of critical important to SSH Communications.

  3. If neither side backs down, this situation is likely to end up in the hands of lawyers. That is actually the worst situation of all. OpenSSH is an open source product that brings in no revenue for OpenBSD. Embroiling them in an expensive legal wrangle will not reflect well on SSH Communications' public image, whether they win or lose. They may well lose, due to the length of time they've taken to start enforcing their trademark.

    Most important, all of us lose, due to the wasted time and energy.

Looking at all the options above, we would most like to see a fourth option created, that would recognize the concerns voiced by Tatu Ylönen, without trade-marking the name of an Internet standard, particularly one as important to all of us as the SSH protocol standard is.

Standards are developed in order to produce interoperability and foster competition. Trade-marking the name of the standard is simply incompatible with those goals.

Fixes for XFree86 vulnerabilities show up from Debian. XFree86 security issues were a common theme throughout the year 2000. Unfortunately, distribution updates fixing such problems had a tendency to show up late, if ever. For example, in October, 2000, we discussed a list of XFree86 security issues, many of them reported by Chris Evans. Between then and now, we've only reported one distribution update in response to that extensive report. It was from Conectiva and only addressed one of the security problems.

This week, Debian has come out with their XFree86 security update. It addresses twelve XFree86 security issues in XFree86 3.3.6 reported by "Chris Evans, Joseph S. Myers, Michal Zalewski, Alan Cox, and others". The fixes are also authored by a numerous and well-known group, "including Aaron Campbell, Paulo Cesar Pereira de Andrade, Keith Packard, David Dawes, Matthieu Herrb, Trevor Johnson, Colin Phipps, and Branden Robinson".

The massive size of this set of fixes gives some glimpse into the question as to why distributions have been so slow in getting updates out. Nonethless, with the release of the Debian updates, it is to be hoped that updates from other distributions will follow much more quickly.

This week's updates:

Security Reports

ssh daemon remotely-exploitable integer overflow. A remotely-exploitable integer overflow was reported this week in ssh daemons that include deattack.c. This includes SSH Communications' ssh 1.2.24 and later (but not their ssh 2.X products) and versions of OpenSSH prior to 2.3.0. This vulnerability can lead to a remote attacker executing arbitrary code locally under the uid of the ssh daemon (usually root). OpenSSH users are encouraged to upgrade immediately to 2.3.0. Users of SSH Communications' ssh daemon are encouraged to upgrade to SSH Comunications SSH 2.4 (with ssh1 support disabled).

This week's updates:

Multiple Linux kernel 2.2 and 2.4 vulnerabilities. Caldera Systems issued an advisory this week reporting two security problems affecting both the Linux 2.2 and 2.4 kernel trees. The first vulnerability allows large parts of Linux kernel memory to be read by passing a negative offset to sysctl. The second vulnerability is a race condition where ptrace is attached to a setuid program and used to modify that program.

Following this report, Red Hat issued their advisory, which included their fixes for the sysctl and ptrace problems, as well as a fix for an unspecified vulnerability specific to the Pentium III patch. Note that the Red Hat advisory credits Solar Designer for discovering the sysctl bug, but this in incorrect. Solar Designer posted a note stating that Chris Evans discovered and reported the sysctl bug.

The security fixes for sysctl and ptrace have been integrated into 2.2.19pre9; the Pentium III bug only affects the 2.2 kernel series if the Pentium III patches have been applied.

Linux 2.4 was not vulnerable to the ptrace issue. Fixes for the sysctl and Pentium III bugs have been integrated into the -ac development tree.

This week's updates:

ja-xklock local root compromise. FreeBSD reported a local root compromise in ja-xklock, a "localized" xlock clone which is part of the FreeBSD ports. ja-xklock does not appear to be popular under Linux, but may show up on other BSD systems.

mars_nwe potential remote root compromise. FreeBSD reported a potential remote root compromise in their mars_nwe port, due to a format string vulnerability. Mars_nwe is Novell Netware server emulator. This vulnerability is not specific to FreeBSD.

elvis-clone exploitable buffer overflow. A remote root compromise is possible due to an exploitable buffer overflow in two elvis-clones in FreeBSD, ja-elvis and ko-helvis. The buffer overflow was found in the elvrec utility, as a result of an internal audit. This vulnerability is not specific to FreeBSD.

dc20ctrl locally-exploitable buffer overflow. dc20ctrl, a program for controlling Kodak DC20 digital cameras, contains a buffer overflow that can be exploited locally, reports FreeBSD. The overflow can be exploited to gain access to the serial port devices on FreeBSD, however the program itself is not specific to FreeBSD.

FreeBSD-specific advisories. FreeBSD released the following advisories this week for vulnerabilities specific to FreeBSD:

m4 buffer overflow. A buffer overflow in m4 has been reported and confirmed on Slackware 7.1.0 and Red Hat 6.1. Oddly enough, there has been no follow-up to these reports and no update to m4 has been published.

LICQ/GnomeICU denial-of-service vulnerability. Sending an RTF (Rich Text Format) file to LICQ or GnomeICU on a target computer will crash the application, reports No Strezzz Cazzz. Both are applications that support ICQ-based communications. No updates to to LICQ have been published. GnomeICU 0.95.1 and 0.95.2 have been released, but the descriptions of these updates do not indicate whether or not this problem has been solved.

Note that a similar problem was reported in kicq and a patch for it has been released.

MySQL buffer overrun. MySql version 3.23.33 was released this week and contains a fix for two buffer overruns, one in the libmysqlclient library and the other in DROP DATABASE.

Web scripts. The following Web scripts were reported to contain vulnerabilities:

  • Phpnuke is reported to be exploitable remotely to read files, and, depending on the remote configuration, execute PHP code or other arbitrary code on the server. The author is aware of the problem and has released a patched version.
  • An additional problem with PHPNuke was reported by rain forest puppy. After a long, detailed exploration of the problem, amounting to almost a full security audit, he indicates that he communicated the problems to the author, PHP-Nuke 4.4 was released 40 days later and he does not yet know whether his suggested improvements/fixes have been incorporated.

Commercial products. The following commercial products were reported to contain vulnerabilities:

  • IBM's IBM Net.Commerce package, including IBM Net.Commerce and IBM WebSphere Commerce Suite, are reported to contain a remote arbitrary command execution vulnerability due to macros that do not validate user input properly. Net.Commerce Versions 3.2 and WebSphere Commerce Suite 4.1 contain corrected versions of the macros. Note that although IBM Websphere includes Apache, Apache itself is not impacted by this report.


SSH protocol 1.5 key session recovery vulnerability. Check last week's LWN Security Summary for the initial report.

Note that our original coverage contained errors due to our incorrect interpretation of the original advisory. We reported that OpenSSH 2.3.0 and earlier were vulnerable (in addition to ssh1.2.31 and earlier), because a patch to correct the problem had been introduced into the OpenSSH tree. We received feedback this week from Theo de Raadt, Iván Arce and Markus Friedl correcting that impression. In fact, OpenSSH 2.2.0 and later are not exploitable via this vulnerability. The maximum number of concurrent unauthenticated connections is automatically defaulted to 10 and random early drop can also be enabled.

Multiple vulnerabilities in bind 8.2.2 and bind 4. Check the February 1st LWN Security Summary for the initial reports. Bind 8.2.3 contains fixes for the problems with 8.2.2. Bind 4 fixes are also available, but an upgrade to bind 8 or even bind 9 is generally considered a preferable approach.

This week's updates:

Previous updates:

Multiple vulnerabilities in ProFTPD. Check the February 8th, 2001 LWN Security Summary for details. ProFTPD 1.2.0rc3 contains fixes for all the above problems.

This week's updates:

Previous updates:
  • Cobalt, unofficial package updates (February 8th)

man -l format string vulnerability. Check the February 8th LWN Security Summary for details. Note that only distributions with a man command that supports the "-l" option are affected. This would include SuSE, Debian and distributions derived from them.

This week's updates:

Secure Locate buffer overflow. Check the November 30th, 2000 LWN Security Summary for the original report of this problem.

This week's updates:

Previous updates:

Netscape 4.75 buffer overflow. First spotted via this FreeBSD advisory and reported on November 9th, a buffer overflow in Netscape 4.75 enables a client-side exploit. Check the November 9th LWN Security Summary for our original report. Netscape 4.76, which was released on October 24th, fixes the problem.

This week's updates:

Previous updates:


ScanSSH. Niels Provos has released a protocol scanner, currently named ScanSSH, which can be used to help find vulnerable SSH daemons so they can be upgraded quickly.

Ramenfind 0.4. A new version of the Ramenfind script was released this week. It handles a new Ramen variant that showed up this past week. That should also be a reminder to everyone to apply your security updates, the best way to protect against the Ramen worm.


Call for Papers: New Security Paradigms Workshop (NSPW). Crispin Cowan sent out the Call-For-Papers for this year's New Security Paradigms Workshop, which is being held September 11th through the 14th, 2001, in Cloudcroft, New Mexico, USA. "In order to preserve the small, focused nature of the workshop, participation is limited to authors of accepted papers and conference organizers. Because we expect new paradigms we accept wide-ranging topics in information security. Any paper that presents a significant shift in thinking about difficult security issues or builds on a previous shift is welcomed."

Upcoming security events.
Date Event Location
February 19-22, 2001. Financial Cryptography 2001 Grand Cayman, BWI.
February 19-22, 2001. VPN Con San Jose, CA, USA.
February 24-March 1, 2001. InfoSec World 2001 Orlando, FL, USA.
March 3-6, 2001. EICAR and Anti-Malware Conference Munich, Germany.
March 27-28, 2001. eSecurity Boston, MA, USA.
March 30-April 1, 2001. @LANta.CON Doraville, GA, USA.
April 6-8, 2001. Rubi Con 2001 Detroit, MI, USA.

For additional security-related events, included training courses (which we don't list above) and events further in the future, check out Security Focus' calendar, one of the primary resources we use for building the above list. To submit an event directly to us, please send a plain-text message to lwn@lwn.net.

Section Editor: Liz Coolbaugh

February 15, 2001

LWN Resources

Secured Distributions:
Astaro Security
Engarde Secure Linux
Kaladix Linux
NSA Security Enhanced
Openwall GNU/Linux

Security Projects
Linux Security Audit Project
Linux Security Module

Security List Archives
Bugtraq Archive
Firewall Wizards Archive
ISN Archive

Distribution-specific links
Caldera Advisories
Conectiva Updates
Debian Alerts
Kondara Advisories
Esware Alerts
LinuxPPC Security Updates
Mandrake Updates
Red Hat Errata
SuSE Announcements
Yellow Dog Errata

BSD-specific links

Security mailing lists
Linux From Scratch
Red Hat
Yellow Dog

Security Software Archives
ZedZ.net (formerly replay.com)

Miscellaneous Resources
Comp Sec News Daily
Security Focus

Next: Kernel

Eklektix, Inc. Linux powered! Copyright © 2001 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds