LWN.net Weekly Edition for December 24, 2003 [LWN.net]

Looking back at 2003

This is the last LWN.net Weekly Edition for 2003, so this is an appropriate time to look back at the last year and ponder what has happened. As a way of maximizing our own embarrassment, we'll start with the predictions we posted at the beginning of the year and see how we did.

We predicted:

Governmental use of Linux would increase. Nobody can say that we missed on that one. Legislation requiring (at a minimum) proper consideration of free software in public purchasing has been introduced, and often passed, in many countries. Nations like Brazil and South Korea have committed to increasing their use of free software. Cities like Munich and Key Largo have made big jumps into free software. All this goes to show: it's easier to make correct predictions if you stick to obvious developments.
There would be high-profile desktop deployments. Opinions remain mixed on whether Linux is ready for serious desktop use now, but few dispute that it is getting there. Desktop Linux provides all the functionality that many users need, and it gets better every day. Big deployments have happened in many places, perhaps topped by Sun's large Linux sale in China, which could eventually add up to millions of desktop systems.
We predicted a major patent challenge for Linux. A big legal challenge did come in the form of the SCO suit, but patents were not involved. The stage remains set for serious patent problems in the future, perhaps coming from Microsoft's increasing interest in its patent portfolio. But 2003 wasn't the year for that.
We also predicted "a watershed year" in intellectual property law driven by a number of high-profile cases. Certainly a lot has happened; the Grokster and Skylink rulings went against oppressive copyright enforcement, UCITA died a well-deserved death, and, perhaps most significantly, an attempt to impose software patents on Europe was defeated - for now. On the other hand, the U.S. Supreme Court refused to limit copyright terms in the Eldred case. All told, it was not a watershed year, however; one year later, the situation is almost the same as it was before. All of the problems we had a year ago are still there.
The 2.6 kernel would be released. That happened, of course, though it wasn't that far from slipping into 2004. We did say it would happen late in the year.
We predicted a "SourceForge crisis." Some projects have moved away from SourceForge, and the site now has a donation box out to help cover its running expenses. But certainly there has been no "crisis."
UnitedLinux would not save all four participants; at least one of them would exit the distribution business by the end of the year. Well, that happened, but not quite as we had envisioned. But UnitedLinux member SCO is certainly out of the distribution business, and UnitedLinux has passed into irrelevance. We also said that MandrakeSoft would find a way to pull through and become a viable company. That appears to be happening, albeit via a period in bankruptcy proceedings.

We also missed a few things. The small resurgence in acquisitions of Linux companies (Scyld, Ximian, SUSE, Sistina) was a pleasant surprise, for the people involved if nobody else. The importance and commercial success of "enterprise Linux" distributions, along with the resulting backlash, was and is an important story for 2003. The increasing level of attacks on the community's infrastructure was an ominous development. And the SCO Group's rampage took us by surprise, along with just about everybody else.

What we didn't even bother to predict was that development would continue, the code would get better, and that Linux would continue to grow. That was too obvious even for LWN. But it happened, and will continue to happen. It is still true that the free software story is just beginning.

(Tune in during next week's break, when we will publish our predictions for 2004. We're still trying to get the crystal ball booted up properly as of this writing; contrary to some rumors, the crystal ball has not been taken down by a security compromise. Trust us).

Comments (1 posted)

Johansen wins round two

December 23, 2003

This article was contributed by Joe 'Zonker' Brockmeier.

Jon Johansen received an early Christmas present from the Norwegian appeals court in Oslo. Judge Wenche Skjeggestad handed down the unanimous decision of the seven-judge panel Monday, which upheld the lower court's ruling. According to the appeals court, Johansen had done nothing wrong in the creation and distribution of the DeCSS DVD descrambling code, and Norwegian citizens are free to access content and make personal copies of legally-purchased DVDs. While many have been watching the case with interest, it still came as a surprise that the verdict, which was not expected until January, was rendered so quickly.

Johansen was charged with criminal violation of Norwegian law in 2000 for writing and publishing DeCSS. The case was set in motion after the DVD Copy Control Association (DVD CCA) and Motion Picture Association of America (MPAA) complained to the Norwegian Economic Crime Unit (Økokrim) about the distribution of DeCSS. According to the letter sent to Økokrim by the DVD CCA's lawyer, Simonsen Musæus:

DeCSS makes it possible with simple means to decrypt the encrypted audio/video-vob files on the DVD discs, and stores them on the PC's hard disk unencrypted. DeCSS also makes it possible to transmit audio/video-files over the Internet in unencrypted and unprotected form. This facilitates duplication of an unlimited number of unauthorized copes. Consequently, Jon Johansen has contributed to illegal distribution of movie files stored on DVD discs, or attempted to contribute to such illegal distribution.

However, the court noted that prosecutors had failed to prove that DeCSS had been used for copyright infringement, and that it was reasonable to make copies of DVDs for personal use. As the Electronic Frontier Foundation's Cindy Cohn noted when Johansen was first acquitted by the lower court, "It really feels like there is some sanity creeping in."

Sanity has, apparently, failed to make a stop at the MPAA. The association has rushed to condemn the Norwegian court's decision and released a statement that dubbed Johansen a "serial hacker" and calling on the Norwegian parliament to "move quickly" to "correct this apparent weakness in Norwegian law." It is, unfortunately, also possible that Johansen's legal travails are not quite over yet. Norwegian prosecutors have two weeks to appeal the appellate court decision to Norway's supreme court.

If found guilty, Johansen could have been sentenced to two years in prison. Prosecutors, however, had asked the court for a lesser suspended sentence in the Johansen case, apparently aiming to set precedent rather than seeking to jail Johansen.

The Johansen case makes it quite clear that the entertainment industry is seeking more than a way to curtail illegal copying. While the prosecutors and the MPAA have claimed that DeCSS opens the door to copyright infringement, there is no need to decrypt DVD content to make copies of DVDs -- and no evidence that DeCSS is being used to "pirate" movies.

It is, however, necessary to use DeCSS or a similar tool to decrypt content to make use of the content legitimately on Linux or other systems that lack DVD playback software. The choices available to movie enthusiasts on Linux are somewhat unpalatable: Risk legal prosecution for creating or using tools such as DeCSS, use other operating systems to play movies on laptops and home PCs, or remain unable to watch legitimately-purchased movies on a computer at all.

The Johansen verdict is a welcome victory, but it is hardly a major one. While those in Norway may breathe easier (at least for the moment), those of us in other countries with more repressive laws still lack the legal ability to make copies of legitimately-purchased media.

Comments (3 posted)

Holiday cheer from the SCO Group

The SCO Group has kicked off the holiday season with a couple of new press releases, some interesting disclosures of which code it is claiming, its fourth quarter results, and, of course, the inevitable conference call. This article will look at all of the above, with an emphasis on the company's new copyright claims. Those claims look to be on shaky ground, to say the least.

We'll start with the quarterly results, as described in this press release. The company lost $1.6 million on revenue of $24.3 million. Of that, $10.3 million came from licensing agreements - all from Microsoft and Sun. It would appear that there are still no other paying licensees. In the conference call, SCO management stated that license revenue in the next quarter would be "minimal." Some direct questions were asked about just what sort of revenue was being received by other licensees, but the answers were, to put it charitably, evasive.

The more interesting part of today's activity is a view into the claims SCO plans to make in the coming months. To that end, there has been another press release, and a new letter being sent to Linux users. What the letter makes clear is that SCO now considers part of the Unix application binary interface (ABI) to be its property. Linux implements the Unix ABI, so SCO has picked out several dozen files which, it claims, violate its copyright. The full list is in the letter, but what it comes down to is each architecture's version of errno.h, signal.h, ioctl.h, plus a few others.

These include files all have the same form: they are really just long lists of #define statements assigning values to symbols. They define the various error codes returned by the kernel, the numbers associated with signals, and the numbers for ioctl() commands. Many of these numbers have nothing in common with any version of Unix, but many others do. So, if you compare the first part of the definitions in the 32V version of user.h with a 2.4 errno.h, you see:

32V version

2.4.x version

#define EPERM   1
#define ENOENT  2
#define ESRCH   3
#define EINTR   4
#define EIO     5
#define ENXIO   6
#define E2BIG   7
#define ENOEXEC 8
#define EBADF   9
#define ECHILD  10
#define EAGAIN  11
#define ENOMEM  12
#define EACCES  13
#define EFAULT  14
#define ENOTBLK 15
#define EBUSY   16
#define EEXIST  17
#define EXDEV   18
#define ENODEV  19
#define ENOTDIR 20
...

#define EPERM            1
#define ENOENT           2
#define ESRCH            3
#define EINTR            4
#define EIO              5
#define ENXIO            6
#define E2BIG            7
#define ENOEXEC          8
#define EBADF            9
#define ECHILD          10
#define EAGAIN          11
#define ENOMEM          12
#define EACCES          13
#define EFAULT          14
#define ENOTBLK         15
#define EBUSY           16
#define EEXIST          17
#define EXDEV           18
#define ENODEV          19
#define ENOTDIR         20
...

The 2.4 version has comments on each line which have been removed in the above listing, but, even taking those into account, there is clearly a high degree of similarity between the two. The definitions in Linux are obviously taken from older Unix systems. That is not surprising; Linux was intended to implement the same interface. Linux is not alone in having reproduced the Unix error numbers; if you look at the Minix version of errno.h, you see the same interface used. Microsoft uses the same numbers. Modern BSD systems also use the same definitions, of course. The basic Unix numbers for errors and signals have been widely reproduced, to say the least.

If the files in question were, indeed, copied from an ancient Unix distribution, then the Linux developers have arguably violated the associated BSD license by leaving out the copyright headers. This is a copyright violation, but it is also easy to fix by simply restoring those headers. There are enough other sources for these numbers, however, that proving that they came into Linux via any particular path could be hard.

There are a couple of things that one should keep in mind, however, when evaluating SCO's new claims. One is that the copyright status of ancient Unix is uncertain at best, as has been reported many times. The judge in the BSDI case came to the conclusion that USL's chances of enforcing its copyrights were poor. SCO will not have improved those chances. Novell's recent reassertion of its claim to still own the Unix copyrights could also complicate matters for SCO.

The truly important issue, however, is that the old Unix ABI is exactly that: a well established ABI. Copyright law allows for the protection of expressions of an idea, but not the idea itself. Concepts used in an ABI, like "the number 12 means no memory is available," can be very difficult to copyright. If there is only one way to express an idea, you cannot get copyright protection for that expression. In this case, there are truly few alternatives to:

    #define ENOMEM 12

SCO will have a hard time convincing a judge anywhere that copyrights can protect this sort of code - especially given that the error names (but not the associated numbers) are part of the POSIX standard.

SCO seemingly intends to try, however - at least for as long as it takes to shake down some nervous users. To that end, the company is taking two approaches. One is to threaten anybody who distributes Linux with the offending files; that is what the letter was sent out for. From statements made in the conference call, one could conclude that SCO thinks it has users in a bind; constants like error and signal numbers cannot be changed without breaking binary applications. By claiming something that cannot be easily removed, SCO apparently hopes to inspire companies to pay up instead.

The other approach is described in the second press release: SCO is sending notices to its Unix licensees requiring them to "certify" that they are in compliance with the Unix agreement. The letter requires a long list of promises from Unix licensees, including:

The company is not running Linux binary code that was compiled from any version of Linux that contains SCO's copyrighted application binary interface code ("ABI Code") specifically identified in the attached notification letter.

It has long been clear that signing a contract with the SCO Group is a Bad Idea. The SCO Group is using its contracts to go after its customers - something which does not generally inspire those customers to buy anything else. The Unix contract is being used as a lever to force those customers to "certify" that they are not running Linux. Needless to say, at this point, few of these customers will be in a position to do that. They are now in a bit of a difficult situation; they can refuse to certify, pay SCO, or claim that Linux does not actually contain any copyrighted ABI code.

As a short-term strategy for SCO, this move must look pretty good. The use of the existing contracts in this way may well succeed in applying enough pressure to make some customers give in. None of those customers are going to appreciate this behavior, however; one would assume that many of them will decide (if they have not already) that entering into any other agreements with the SCO Group is not in their best interests. SCO is destroying whatever future business it may have still had to expedite a short-term shakedown.

A couple of other notes from the conference call are in order. It began with a statement that the call is copyrighted by SCO, and any reproduction ("in whole or in part") is prohibited. Transcripts will certainly be posted; it will be interesting to see if SCO tries to get them taken down. Analyst Dion Cornett (Decatur Jones Equity) appears to be getting a clue: he asked SCO whether it really believed it had a valid license to distribute Samba. Strangely enough, SCO's answer did not address that question at all. Finally, Darl McBride presented the SCO litigation scheme as "a model many companies will adopt" in the near future. If SCO succeeds in its attempts, that statement could well come true. The foundation of SCO's new claims appears weak at best, however. SCO is more likely to become a very different sort of example.

Comments (15 posted)

More SCO cheer

Since the above article was published, a few more things have happened on the SCO front...

Linus has posted a response to SCO's claims of ownership of various include files in the Linux kernel. In particular, he examines the "ctype" macros, which he wrote personally, tracing their development from very early kernels. Needless to say, he does not concur with SCO's claims in this regard.

Since then, a significant effort has been underway to find the true origins of the errno.h include file. This file, it turns out, was added in version 0.97 of the kernel; Linus has concluded that it was automatically generated from libc-2.2.2 (note that's "libc", not "glibc", which came much later). Tracking down the source for that version of the library was a challenge, but, once it turned up on an FTP site, Linus was able to verify that it was the source for errno.h. The next question would be how the error numbers and descriptions got into libc, but, as Linus says:

But it shouldn't much matter, since I don't think SCO really is going to try to claim copyright ownership of the result of standard C library interactions like using "sys_errlist[]". (I take that back - _of_course_ they are going to try to claim ownership. After all, they already claimed ownership of code I provably wrote).

In any case, errno.h was not copied from anything owned by SCO.

It is also worth looking into ancient history (October, 2003) to review a quote by SCO's spokesperson Blake Stowell:

End users have a choice. They can go back to using Linux based on the 2.2 kernel which includes no infringing code, or they can continue using SCO's UNIX code as it is being found in Linux and properly compensate the company for using it.

Files like errno.h have been in the kernel since well before 2.2, which, apparently, "includes no infringing code." Either SCO has changed its mind in the last couple of months, or they know that this code does not actually infringe upon any copyrights owned by the SCO group. We requested clarification from Mr. Stowell, but, predictably, got no response.

Meanwhile, SCO has announced the abrupt departure of Steve Cakebread from its board of directors, ostensibly due to "personal time constraints." We note (thanks to a pointer from Don Marti) that Mr. Cakebread's day job is Chief Financial Officer at Salesforce.com, which is a heavily Linux-based application service provider. Could it be that Salesforce.com got a shakedown letter from SCO, and has given its response?

SCO's offices are, apparently, shutting down for the holidays. Expect more interesting developments in January after they return to work and, according to the Monday conference call, set a significantly larger staff on the task of shaking money out of Linux users.

Comments (4 posted)

Interview: Public Patent Foundation's Dan Ravicher

December 23, 2003

By Pamela Jones, Editor of Groklaw

While the SCO saga is absorbing our attention in the short term, many are concerned about software patents and they worry that the real test for GNU/Linux will be in the future, from patent lawsuits. There have been numerous patents granted that to programmers seem to have been wrongly issued. The Amazon One Click patent springs to mind. Now Microsoft has announced it will be charging for use of the FAT filesystem, and that too makes some worry.

The Public Patent Foundation has recently been established for the purpose, as its web site puts it, of protecting "civil liberties and free markets from wrongly issued patents and unsound patent policy by providing those persons and businesses otherwise economically, politically, and socially deprived of access to the system governing patents with representation, advocacy and education."

Dan Ravicher is the patent attorney -- and programmer, incidentally -- who started PubPat, and he is its Executive Director. He was kind enough to answer some questions about patents and the work his organization is doing to educate the public and counter patent abuses. He says he is looking into the Microsoft FAT patents situation and has about a hundred pieces of prior art which were not reviewed by the examiner which they are currently reviewing. Dan was kind enough to answer the following questions.

What made you decide to start your foundation and can you tell us what it does?

The patent system is being abused by private actors to the detriment of the mostly unaware public. Our health, our freedom, and our economic prosperity are all under assault from bogus rights meted out to the few with the power and expertise to game a system originally established hundreds of years ago to promote progress within society as a whole. The government, through primarily a captured patent office utterly failing to achieve its mission and skewed policies implement into patent law by Congress and the courts, is not just failing to defend the public interest from abuse of the patent system, but is complicit in and supportive of such efforts.

In information technology industries, abuse of the patent system means illicit restraint of civil liberties and unjustified disproportionate burdening of small businesses. In life science industries, abuse of the patent system has even more devastating results, including the exacerbation of pain and suffering by those who cannot afford medical technologies covered by undeserved patents. This situation is abhorrent and the Public Patent Foundation is beginning a campaign against such abuses.

PubPat's four core activities are (1) challenging patents that threaten the public's health, freedom, or other interests, (2) helping small businesses defend themselves from patents being asserted against them, (3) establishing patent commons within markets crippled by patent thickets, and (4) educating the public regarding these issues and advocating for reform of the patent system.

If you plan on contesting any patents, can you tell us what patents you have in mind currently? And what would the process involve, from your standpoint?

At the moment we have under consideration several patents, including Microsoft's FAT patents, the Optima patent on CD burning, and a patent on co-transformation and protein production. Upon completing our review, there are many ways to neutralize the harmful effects of a patent, including asking the Patent Office to revoke it and publicizing ways to avoid infringing it.

To expand on one of the examples above, the Microsoft FAT patents are part of Microsoft's first attempt at building a licensing line of business akin to the one rolled out by IBM several decades ago. This causes concern for us because Microsoft is an admitted monopolist with a proven track record of driving competition from various markets through any mechanism available to it. They may now be focussing on patents as yet another avenue to foreclose competition, including specifically that from free software.

Beyond these atmospheric concerns, our analysis of the FAT patents has produced a substantial amount of prior art that was not before the patent office when it issued those patents to Microsoft. For a company with a nefarious past to be seeking revenue for patents that very likely did not deserve to be issued, is a malign scenario indeed. PubPat intends to ensure that the public's interest in being protected from such bahavior is properly represented.

Should there be software patents at all?

Many feel passionately about this issue. As a empiricist, I infrequently speak in categorical broad-brush terms unless presented with sound data and analysis to support a particular conclusion. With respect to software patents, everyone can agree that none which fail to meet the requirements of novelty and unobviousness should be granted or maintained. Beyond that, I have grave concerns about the lengthy term of patents being applied to technologies with short life cycles, especially those with life cycles shorter than the term of the patent. Such patented technologies never provide a public benefit, because by time the patent expires, the technology is no longer useful.

One thing the Public Patent Foundation is doing is compiling the data and performing the analysis I mentioned above, so that all reasonable persons can be presented with evidence supporting or condemning the policy decision made by the courts that "anything under the sun made by man" is patent eligible.

What is a "wrongly issued patent"? Should patents only be issued for a demonstrable, produced invention?

A patent can be "wrongly issued" for several reasons, including that the patent office was not aware of significant prior art during the examination process or that the patent office simply made the wrong conclusion regarding whether or not the patented technology was new and unobvious. I'm unsure what you mean by "demonstrable, produced invention", but the current standards of novelty, non-obviousness, and reduction to practice are good standards. The problem arises from either a lack of evidence on which to base a judgment as to whether something is new, unobvious, and reduced to practice, or a lack of competency in making those judgments.

Should the inventor state/swear that they intend to use the patent?

Many countries have patent laws that force a patentee to exploit her invention, else it becomes subject to a compulsory license at a minimum royalty rate. Such a rule is better than what we have in the United States, which does not require exploitation of patented technology. At the same time, however, such a shift may penalize small businesses who may not have access to the resources necessary to exploit a certain technology. Such small player patentees would have their leverage in negotiating a license with a larger competitor undercut by the statutory compulsory license.

It seems like many patents these days involve "good ideas" which are never implemented by the patent holder. Should "inventors" of software and/or business methods be required to provide evidence that they've made the system work before a patent is granted?

Patent law requires a patent applicant to reduce the patented technology to practice prior to applying for the patent; else any patent resulting from the application is invalid. To reduce a technology to practice, the patent applicant must either actually create the technology or describe it in such detail that one of ordinary skill in the art with the requisite resources could create the technology without undue experimentation. For instance, if you invent a time machine, but can't afford to make it, you can still get a patent so long as you tell others how to make it with sufficient detail such that they can successfully make the time machine at least 70-75% of the time. If, however, your instructions are insufficient for one of ordinary skill in the art with requisite resources to create the patented technology at least about 2/3rds of the time, then your patent is invalid for what is called "lack of enablement."

What about patents granted for obvious methods and technology? Should a patent be more than a unique design of a commonplace item such as a document or file?

The law requires a patented technology to be both new and unobvious. The crux of your question resides in defining the term "unique." If something is "unique" enough that ones of ordinary skill in the relevant art recognize it as being a new and unobvious technology, then current patent policy suggest rewarding the publication of that technology with a patent. Otherwise, the developer will keep the technology secret and other members of society will not be able to learn from and improve upon it.

What is the international impact of American patent law on world business?

First, half of the world's economy takes place in the U.S.. That fact alone means that U.S. patent law directly regulates half of all the world's business. Second, through international treaties, many of the policies of U.S. patent law have been adopted and implemented by other countries. This results in regulation of business wholly outside the U.S. closely mimicking the regulation of business within the U.S..

Computers are extensions of the human brain; computer storage is an extension of human reading and writing; electronic communication is an extension of the human voice. How do you feel about patents which use computers to do things that humans have been doing for millennia?

A patent cannot cover pure functionality; else it is invalid for indefiniteness. Rather, a patent can only cover specific structure used to accomplish a particular function. As such, it is only the structure that is patented, not the resulting function. Many people misunderstand this very important facet of patent law because sometimes, especially for the most publicized patents, the structure covered by the patent is the only known structure for accomplishing the particular function. This leads people to assume that the function itself is patented, which is not the case. Designing around patents is highly encouraged in patent law, and someone else is free to learn from the patent and come up with different structure for accomplishing the same, or a substitutable, function.

If a patented technology accomplishes a very old function, but with structure that is new and unobvious, then that satisfies the requirements for patentability. Further, one may need to recognize that functions are not necessarily the same simply because their result is the same. For instance, few humans who can do in a day (week, year) the complex calculations machines do today in mere nanoseconds. The function, in that case, is not getting the answer; it is getting the answer in virtual real time, which is something that humans have never done.

Do you feel that public discussion should be allowed before a patent is granted?

Public comment on patent applications prior to issue is an idea with some merit. Such is the law in many foreign countries, and recently the patent office abolished its prohibition on receiving third party correspondence regarding patent applications. However, if the process of pre-issuance public discussion includes a mechanism for third parties to delay the patent application from issuing, that mechanism might become unjustifiably abused and manipulated, particularly by larger corporations who can afford to "hold-up" a smaller companies "crown jewel patent."

Comments (1 posted)

Page editor: Jonathan Corbet

Security

Brief items

Linux security in 2003

Here in the free software world, we had no shortage of security problems in 2003. Vulnerabilities were announced in many packages, including (but not limited to) apache (several), balsa, bind, bugzilla, cdrecord, cfengine, cron, cups, cvs, ethereal (many), evolution, exim, fetchmail (many), fileutils, gdm, ghostscript, glibc, gnupg, gzip, hylafax, inetd, iproute, KDE, kerberos, kernel (several), lprng, lsh, lynx, mailman, man, mozilla, mpg123, mplayer, mutt, MySQL, openssh, openssl (several), perl, pine, PHP, postfix, PostgreSQL, proftpd, python, rsync, samba, screen, sendmail, snort, stunnel, sudo, tcpdump, vim, webmin, wget, wu-ftpd, xchat, XFree86, xinetd, xpdf, and zlib. All told, 304 entries were added to LWN's vulnerability database in 2003. Needless to say, that is far too many - and it does not count all of the problems which were silently fixed without going though a security alert process. As a community, we have to strive to do better in 2004. For all that we believe Linux and free software are more secure, there is no doubt that they are not, yet, secure enough.

The truly worrisome security trend in 2003, however, is the increasing level of attacks on the community's infrastructure. Servers were compromised at the GNU Project (twice) and the Debian Project (multiple servers in one incident). A mirror server for the Gentoo distribution was also broken into. There was also a compromise of the kernel's CVS server and an attempt to insert a trojan horse into the kernel itself. None of these attacks ended up with compromised code being made available to users, but most of them could have been exploited in that way.

Maybe these are all just random attacks (though an attempt to trojan the kernel can only be so random), or maybe somebody is making an attempt to mess with the server structure which holds this community together. Either way, chances are that, eventually, one of these attacks will succeed in causing serious damage, far beyond the service disruptions and lost time we have seen so far. The real lesson from 2003 is that there really are people out there with evil intent, and they are looking our way.

Comments (1 posted)

New vulnerabilities

ethereal: protocol dissector and other vulnerabilities

Package(s):

ethereal

CVE #(s):

CAN-2003-0925 CAN-2003-0926 CAN-2003-0927 CAN-2003-1012 CAN-2003-1013

Created:

December 19, 2003

Updated:

February 13, 2004

Description:

Serious issues have been discovered in two ethereal protocol dissectors. Both vulnerabilities will make the Ethereal application crash. The Q.931 vulnerability also affects Tethereal. It is not known if either vulnerability can be used to make Ethereal or Tethereal run arbitrary code. (CAN-2003-1012 and CAN-2003-1013)

Alerts:

Whitebox	WBSA-2004:002-01	2004-02-12
Fedora-Legacy	FLSA:1193	2004-01-31
Red Hat	RHSA-2004:002-01	2004-01-05
Mandrake	MDKSA-2004:002	2004-01-13
Conectiva	CLA-2004:801	2004-01-07
Red Hat	RHSA-2004:001-01	2004-01-07
Debian	DSA-407-1	2004-01-05
Fedora	FEDORA-2003-040	2003-12-18

LWN.net Weekly Edition for December 24, 2003

ethereal: protocol dissector and other vulnerabilities

irssi: remote denial of service

2.4 kernel - several vulnerabilities

apache: buffer overflows in mod_alias, mod_rewrite

apache2: Denial of Service vulnerability

bind: cache poisoning

CUPS: denial of service

cvs: unauthorized file creation

ethereal: multiple remote and local vulnerabilities

Filename disclosure vulnerability in fam

fetchmail may crash on specially crafted message

fileutils/wu-ftpd: denial of service

glibc: DNS stub resolvers contain buffer overflow vulnerability

GnuPG: ElGamal signing keys compromised

gtkhtml: malformed messages cause crash

iproute: local denial of service

KDE: Two issues in KDM

kernel: local root exploit in 2.4.22

kernel-utils: setuid vulnerability

lftp buffer overflows

libnids: remotely exploitable buffer overflow

libpng, libpng3: buffer overflow

mikmod: buffer overflow

mpg123: heap overflow

mplayer: remotely exploitable buffer overflow vulnerability

Nessus NASL scripting engine security issues

Net-SNMP: security bugs in versions before 5.0.9

nfs-utils xlog() off-by-one bug

openssh: timing attack leads to information disclosure

postfix: denial of service vulnerabilities

proftpd: remote root shell

rsync - remotely exploitable heap overflow

Multiple-use vulnerability in Safe.pm

sane-backends: several vulnerabilities

screen: privilege escalation

File overwrite vulnerability in tar and unzip

Multiple vendor telnetd vulnerability

vim - modeline vulnerability

xchat: remotely exploitable denial of service vulnerability

zebra: denial of service vulnerability