LWN.net Logo

LWN.net Weekly Edition for August 11, 2005

Interview: Eben Moglen

August 10, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

Attending Linux trade shows is a lot of hassle, particularly when you have to drive a couple of states to make it to the location. However, this is greatly mitigated by the fact that one has the opportunity to speak face to face with some of the more interesting people in the Linux community. This week at Linux World Conference & Expo, I had the chance to speak with Eben Moglen, President and Executive Director of the Software Freedom Law Center. The interview touched on the Software Freedom Law Center, the revision process for the GPL version 3 and several other topics.

LWN: What's the status of the Software Freedom Law Center, what kind of activities are going on, and its funding?

The status is making a law firm is an interesting activity, particularly if you're building a small business on Manhattan island. I've spent more time on real estate and physical details of making it work than I thought we would, but we're successfully housed and we're hiring lawyers and we've been recruiting clients and releasing some press about the clients we've recruited and that process is scaling up, we expect Dan Ravicher my junior partner and I to have at least two more lawyers, maybe three more hired during the next few months and we will be looking to hire some young people, freshly graduating from law school this coming spring and entertaining our first international fellows starting this year.

As for funding, we've received now two rounds of funding from OSDL, which has been acting as our agent for collecting from a number of vendors, they have been gratifyingly reliable in the funding of our firm, and I have no reason to believe that there will be any difficulty. I think the principle that better support for developers is good for business is now firmly in everybody's mind and we have been very graciously entrusted with the task of making that happen.

LWN: A while back, you said something about getting an answer from Linus on the Linux kernel license. Since there is a COPYING file that makes it clear that the kernel is governed under the GPL, where's the uncertainty?

If the kernel is pure GPL, then I think we would all agree that non-GPL, non-free loadable kernel modules represent GPL violations. Nonetheless, we all know that there are a large number of such modules and their existence is tolerated or even to some degree encouraged by the kernel maintainers, and I take that to mean that as an indication that there is some exception for those modules.

The kernel also maintains a technical mechanism, namely the GPL-only symbols and tainting structure, which seems to suggest an API for the connection of non-GPL'ed code to the kernel, which also seems to me a strong indication of the presence of an exception. The difficulty as a lawyer, even a lawyer that is reasonably knowledgeable about these matters, is that I don't understand what the terms of that exception are.

So, say I want to audit a system, say an embedded product, in which I find non-GPL loadable kernel modules present, how do I know whether that fits within an exception which is legitimately available to third parties and when it is not?

Linus has said over the years a number of things about how he would not object to anything that was not in obvious bad taste, or ugly, or awkward or unacceptable and I understood, I think, what he meant at each of those particular times. But it would be helpful in applying an analysis from a lawyer's point of view, and think about the problem.

One very important area is the problem faced by people who make software-controlled radios, which they want to run in systems which make use of the Linux kernel and other GNU and free software. Those parties may feel they're under regulatory orders not to release source code modules, because regulators in Japan and Europe and the United States have all, to differing degrees, made clear to manufacturers of radio transmission hardware that if they allow after-market modification that violates spectrum control regulations they may be in trouble. The Japanese in particular have been very strong in their wording.

So then there are parties in the world who think they are in legal trouble on one side with the regulators if they do release source code for loadable kernel modules that drive their software-controlled radios, and they don't know if they're in legal trouble on the other side if they don't release source code. For those parties, in particular, it would be very helpful if the kernel developers had decided to formalize the nature of their exceptions, and the Free Software Foundation and I have made a few attempts to discuss that matter with kernel developers. I had conversations with Ted Ts'o, I talked to Linus about it and I understood there were some reluctances to clarify, in a full and complete way, what was going on. There may have even been disagreements among kernel developers about that, I wouldn't know. But I continue to think that it would be useful, for a whole variety of people who are trying in good faith to do the very best they can, and who may be navigating some dodgy legal territory, for them to be able to refer to something beyond the COPYING file which -- with all due respect -- I think probably doesn't contain all the terms that are relevant to the use of the kernel.

LWN: So, if the kernel is covered solely by the GPL, you would see proprietary modules as an infringement?

Yes. I think we would all accept that. I think that the degree of interpenetration between kernel modules and the remainder of the kernel is very great, I think it's clear that a kernel with some modules loaded is a "a work" and because any module that is dynamically loaded could be statically linked into the kernel, and because I'm sure that the mere method of linkage is not what determines what violates the GPL, I think it would be very clear analytically that non-GPL loadable kernel modules would violate the license if it's pure GPL.

LWN: Should distributors of proprietary modules then be worried about infringement?

As a matter of fact, I think they are worried about it, and that's why I think that clarifying the license terms would be helpful. If there are no exceptions and that were stated very clearly then they would know that's not the way to do what they're doing. If there are some exceptions available, for example for people who have no legal choice, they'd like to know what those rules are and I'm sure lots of other lawyers around the community would too.

LWN: The Free Software Foundation put out a press release about a year ago saying that the reason that SCO was attacking the Linux kernel and not attacking GNU was because of the FSF copyright assignment policies of the FSF, do you still see it that way, and why is the kernel vulnerable when GNU is not, in that case?

I think what I said then was not that the reason was, because I truly didn't know what the reason was why Mr. McBride did anything at all. I think what I said was, I took from the fact that they were fulminating a great deal about the illegality of the GPL and the badness of the Free Software Foundation, and yet weren't objecting to our code was because they knew it would be particularly easy to show that they were wrong.

I think that what I said was, that a process of taking a copyright assignment process from each contributor, accompanied by a legal indemnity, promising that the code was the code of the contributor and that there was nobody else with a dominating interest in it and doing so at the point of an indemnification promise to the Free Software Foundation produced a very strong chain link fence between us and claims of the kind that SCO was throwing around and I thought that constituted an indication of a cautious and prudent model of how to put free software together which Stallman had been following since long before I worked with him in the construction of the GNU Project. That didn't mean I think, that it was the only way to put together code that is strong, but where it works, it's a highly desirable model to pursue.

Linus eventually found another formula, which suited his view of the way the kernel development process works for introducing some accountability in the contributions process, and I thought that was a very good idea, and I said so. I think that if all the free software in the world were assembled in the most prudent and conservative fashion, that Mr. McBride and his colleagues would have found no place to even begin with the FUD with which they began. I think it's also important to point out that we all thought those accusations were baseless to start with and had good reasons to think they were baseless to start with. There wasn't anything wrong with how the kernel is put together. If there was a statement to make, it was simply the way the kernel is put together doesn't prove on its face the cleanliness of how it was put together with the degree of strength that otherwise could have been mustered.

I would advise clients of the Software Freedom Law Center, in light of SCO and many other things to begin their projects in ways that document and protect more carefully that structure of how free software is put together. But I understand completely how Linus Torvalds, living in Finland as a University of Helsinki undergraduate, unadvised by counsel, would not have chosen what I would now recommend to my clients to choose.

LWN: You made a comment about patent holders shaking down users of free software for royalties. I haven't heard of any situations where this is happening, can you tell us how bad the problem is, why it's not being made public when it happens?

Well, I think I can say why it isn't being made public, when a manufacturer of products with embedded free software, or user on a large scale of free software is the subject of claims such as this, from a company such as Microsoft, if they take a license and pay it's because they want peace and quiet. If what they want is peace and quiet, they'll be quiet about how they procured peace. The result of which, we won't hear except in an indirect way. That's why it's not public.

Why it's not a good idea is that each one of those parties that procures peace and quiet for itself is doing harm to the others in the ecology. Each one that takes a license strengthens the apparent patent claim that they are paying tribute on. The result of which is to strengthen the hand by which the troll tends to pick somebody else up later on. From an ecological point of view, we're concerned about the health of the entire community. You'd like to say to such people, before you pay that license fee, can you talk to about why that patent FUD may be just FUD? Could we discuss what we know about the patents held by the parties shaking you down? Could we present to you why maybe those patents aren't very strong and maybe not an appropriate basis for the payment of tribute. In other words, could we maintain a united, consolidated front.

The problem with the private license deals, they affect our solidarity and our ability to act defensively as a community together. And whether they're done publicly or not by the party who took the license, there's always a risk they'll be trumpeted by the patent holder as a sign of the strength of its patent and the degree to which other people should be afraid. So, when I have some reason to believe that some such situation is in progress, I often make an attempt to communicate with the party taking out a license, and often they won't talk and they prefer peace and quiet. I think that more respect for the needs of the community would be an appropriate leaven in their decision-making process?

LWN: How bad is the problem? Is this happening a great deal?

Well, I'm not in a position to say how often it's happened of course, since I'm sure I only know about a fraction of when it's going on. It's pure chance when we discover it, sometimes. I think it's bad for the reason I have suggested, that everybody knows... the patent problem is a real problem, and it needs a real solution. And you see people like the Open Source Development Labs stepping up and trying to create collaborative means to address the problem. Everything that subtracts energy from that attempt to collaborate to solve the problem, is in itself making the problem worse.

Without unduly criticizing businesses that are making business decisions, they're paying money to have peace, which is perfectly understandable to do and may be culturally particularly appropriate in certain national settings, I think that overall it creates difficulty for us, it aggravates the problem of patents overall.

LWN: There's a draft bill in the House right now, that would restructure the patent system, would it be good for free software?

It would not be bad for free software if it passes. That is to say there's nothing in that bill that aggravates the problem. Many things that were originally proposed in that bill that would have been good have been removed in the process of discussion.

My particular analysis is that, at the moment, the legislative process is stalled. I do not expect any movement in that legislative process. I think that, for the moment, that initiative is in the deep freeze. My analysis is that the power of pharma to control what happens to patents in the United States Congress is nearly absolute. The Princeton health economist, Uva Rinehart, who was a major advisor to the Clinton task force and is one of the most knowledgeable health care economists in the United States referred recently in a National Public Radio report I was listening to, to the pharmaceutical companies' "substantial equity stake in the United States Congress," and I thought that was a very elegant way of putting it.

My belief is that until such time as there is a deal which includes the pharmaceutical companies, there is very little enthusiasm in the United States Congress for meaningful patent reform.

I must say, as a person who represent parties who are very afraid of what patents can do to them, I think that this operation is very largely a sideshow. I think it was intended to give the impression that things were being done, and I think that people, in good faith, who want good outcomes, nobly put their shoulders to the wheel and tried to turn it. But I do not believe it will turn this time. I don't think it's going to turn until we make some serious attempt either to disengage the interests of pharma from IT and pursue sector-based relief from the patent problem or until we step up to the problem that the patent system doesn't work very well under 21st century conditions and no matter what the pharmaceutical companies think it needs serious reform.

LWN: You've encouraged free software developers to get patents on unique ideas. Is that happening much, and what resources are there for developers who want to obtain patents?

The grave difficulty in operating in this direction, which Mr. Stallman and I have been thinking about for years now, in order to be efficient in obtaining patents, you need to associate patent lawyers with patent agents with engineers in the very early stages of design and development of inventions.

You need to have people there right along, it's very inefficient to try after a project is over to develop the patent applications. Moreover, in the United States patent law, once you have gone on sale, which includes public distribution of free software, you have a year to file a patent application and after that you may not file at all.

The consequence of which is that there are both resource constraints and deadlines, which are very serious given the way that the free software development process works. Having patent agents and lawyers working along side developers is not a possibility. It's not efficient and it's not the way our community operates.

The result is that the process of getting patents for free software, to build a pool, is almost impracticable while the developer community is spread very thin and very little of it works for large technology businesses with established processes for the getting of patents.

On the other hand, resources may flow towards that in the same way that they have flowed towards the Software Freedom Law Center. I think that one of the most important things said in the OSDL announcement yesterday is that there would be resources for patent prosecution, that is for getting patents, available to developers who came forward and wanted their patents to go into the patent commons. That represents the first significant movement behind patent prosecution, behind getting patents. It's one of the things I hope people will notice about what OSDL has said, because I think it's an important strategic advance.

Will it work in that sense across the enormous range of free software projects? No, I don't think so, we're just at the beginning, we'd have to scale that in many different directions. But, in some crucial projects, important to our commercial partners in this process, and large numbers of users, and tightly coordinated development teams that have worked in large technology companies and know how the patent-getting processes work, in a range of conditions that are satisfied only in some parts of our community, I think there will be some real progress. I think you will see our inventions patented and there will be some cross-licensing negotiations that will be effective for us in gaining some use of other people's patent claims free of legal difficulty.

LWN: In the framework you talked about, these patents would be assigned to the commons, so that they couldn't decide to abuse them.

One of the things we need to do is arrange all of the legal infrastructure so that it works well for everybody. Yes, I think that's a reasonable thing to expect, there will be safeguards to prevent that kind of change of heart...

LWN: Let's talk about DRM. If the GPL requires distribution of scripts that control compilation and installation of an executable, does that extend to the binary keys for DRM?

I think the answer to that question is no. Under the existing GPL 2, the better argument would be that those are not covered by the definition of complete and corresponding source code under section 3 of the license. One could change that definition in a future version of the GPL, and say, for example, it's a straightforward idea, you could say the encryption keys that make it possible to run this software on the hardware on which you are receiving the software.

It is a possible approach. I think there are very significant difficulties with it, including the possibility we would pinch off a whole system of hardware in the world and say "free software doesn't run there." I think that might be a strategic mistake for the free software world, to say "we are going to write off a whole generation and form of hardware and not even attempt to bring freedom there..." I think we would risk leaving a whole lot of people in a condition of unfreedom for a long time.

I think unless we are prepared to be more sophisticated in our approach to this -- this is a very ham-fisted approach, the idea that you buy a computer and are not allowed to be in charge of it. It's a very anti-consumer thing to do. Instead of building an electric fence around it, as though it were some kind of bad place we don't want to go. I think we have a duty to bring freedom there if we can, and we need to empower consumers to reject such hardware and my hope is that in a future version of the GPL, we will devise something elegant and effective at using the gravitational force of freedom to unlock that place over there, and not just seal it off.

LWN: You talked a bit at the beginning about software-controlled radios and why they're important, do you want to add to that?

I've published pieces about that. If we are interested in freedom, generally, one of the things that we have to recognize about the 20th century is that there was a great degree of unfreedom that was generated by control over spectrum. Governments around the world either controlled spectrum themselves or delegated control to a small number of powerful people, and that affected 20th century politics very, very deeply.

It was also a technical response to a problem that doesn't exist with intelligent devices that exist in the 21st century... the technical rationale for the concentration of spectrum in a few hands is gone, and there never was a social rationale for that concentration of spectrum. It was never the case that the public trust that held the common property of the airwaves needed to be dealt with in a concentrated fashion for social or political reasons, the only justification ever given was a technical one.

So from my point of view, the world of devices that know about the spectrum and deal with it intelligently can promise more democracy in media than we ever had before, just as the web did for publication of text and is now doing for video. We need to be alert to the fact that the way we deal with software-controlled radios and the ability for people to use the spectrum themselves the way they want to, is a very important political and social issue in the 21st century. That's why I pay very close attention to how the free software world interacts with the world of spectrum control and regulation. 15 years from now, that's where the action is and I want to get the early stuff right if it's at all possible to do so.

LWN: Can we talk a little about the GPL revision process? When you did the GFDL process, some people thought they weren't listened to. What did you learn from the process?

I don't disagree with you that the process that was applied to the publication and modification of the GNU Free Documentation License would not work very well for the GPL version 3. And I think you've given reason, there's a very small group of people who need to be satisfied by and to use the license and in the other case, there's everybody on Earth... The GPL involves affecting a much broader community of stakeholders, much more various and much more complicated, we need to be in touch with that community as much as we can, and I think the process on that scale is a much different process.

I also should say that although it is true the number of people using the GNU FDL isn't that large, the number of people objecting to the FDL wasn't all that large either. There were a small number of people who wanted to say something and have their views heard. Whether they were heard or whether they thought they were heard is two different questions... I don't think there was a word written on that subject that I didn't read. Many words written on that subject I had no desire to respond to because I thought that response would only increase the intensity of the discussion... my goal in helping the Free Software Foundation construct a new GPL is to increase the lucidity without increasing the intensity. I hope there is a lot less shouting and a lot more thinking next time around by all parties.

LWN: Do you think that's likely?

I do. If you want to know what I think we've learned, I think we've learned some things about increasing the lucidity without increasing the intensity.

We'd like to thank Eben Moglen for taking the time to talk with LWN.

Comments (22 posted)

The launch of openSUSE

The SUSE Linux distribution has had a large and dedicated following for many years. SUSE users appreciate the combination of the distribution's administration tools, large selection of packages, and "German engineering." This distribution has always been relatively closed in its openSUSE development process, however. There is no development version available, and even beta tests have been closed affairs. SUSE has not, as a rule, invited its users to be a part of the development process.

The opening up of the SUSE distribution was bound to happen, sooner or later. Maintaining a major distribution is a major bit of work. But major distributions have user communities which can help with that work, and which can be the source of no end of good ideas as well. Bringing in the user community can improve the distribution, ensure wider testing, and, as a bonus, further bind those users with the distribution. People tend to be more enthusiastic about software which they have helped to shape and polish. Red Hat figured this out some years ago, and most other major distributions are created with a great deal of outside involvement.

SUSE Linux is now attempting to follow a similar path through the openSUSE project, which was officially announced on August 9. OpenSUSE will play a role similar to Red Hat's Fedora; it is a free distribution, developed with community input, which will help to drive the development of SUSE's high-end commercial offerings. Unlike Fedora, however, openSUSE will continue to be available as a retail, boxed product. In this way, Novell hopes to make the distribution as accessible as possible.

Since openSUSE is new, it lags Fedora in a number of ways. At the top of the list would be the lack of an ongoing development version of the distribution. The announcement of openSUSE included a beta release for openSUSE 10.0, which is a step in the right direction (see our review on this week's Distributions Page). The occasional beta release, however, is not the same as a bleeding-edge development repository along the lines of Rawhide, Debian unstable, or Ubuntu's "breezy." Your editor, who has not had a successful Rawhide update in some time, currently finds his enthusiasm for development repositories to be at a relatively low point. But the fact remains that making the current development version of a distribution available facilitates early testing and feedback. It also provides an experience some users want: riding the leading edge of a fast-moving distribution is a great way to taste - and participate in - the vitality of the free software community as a whole.

The openSUSE "how to participate" page shows some parallels with the early Fedora days. The first and foremost way for people to participate at this time is to test packages and report bugs. Interested people are also encouraged to submit patches, write documentation, or apply for a job. There is currently no way for outside developers to apply changes or provide packages themselves; the roadmap page states that "a first version" of a build server will be made available in early 2006. Given the frustration experienced by would-be Fedora developers, the openSUSE folks would be well advised to get that infrastructure in place in short order.

Some things are missing from the openSUSE site altogether. There is, for example, no discussion of how openSUSE will be governed. Who will make decisions on distribution policy, which packages will be included, etc.? Fedora, instead, launched with detailed plans for various sorts of advisory boards - and promptly ignored them all. More recently, Red Hat has been talking about loosening its firm grip on Fedora; very little has been said, instead, about just how independent openSUSE will be from Novell's management.

Also missing is any discussion of the security update policy for openSUSE releases. SUSE's security response tends to be rapid and thorough. The same has traditionally been true of Red Hat, but Fedora brought with it a new policy on security patches. Updates tend to come quickly from Fedora, but the short period for security support makes Fedora a relatively difficult platform for any sort of production use. That suits Red Hat's goals nicely, of course - Red Hat is wanting to sell its enterprise support offerings. It would not be entirely surprising to see openSUSE take a similar path; hopefully the project will post a security update policy in the near future so that its users will know what to expect.

If the openSUSE project is to be successful, it must find a way to attract developers and users, and to keep them happy. There is quite a variety of community distribution projects out there, and many of them do not have any apparent conflicts of interest with corporate goals. OpenSUSE will have to distinguish itself from those other distributions somehow. The openSUSE FAQ gives a hint as to how the project's leaders are hoping to proceed:

The openSUSE project explicitly looks beyond the technical community to the broader non-technical community of computer users interested in Linux... Only the openSUSE project refines its Linux distribution to the point where non-technical users can have a successful Linux experience.

The "only" claim is certainly debatable, but, with SUSE Linux as a base, the openSUSE project has a solid base upon which to build in that direction. There will always be room for a well-designed, robustly-built, user-oriented Linux distribution.

Comments (3 posted)

Some SCO notes

It has been some time since the SCO Group has graced the LWN front page. That situation is just fine with us; there is no end of more interesting stuff happening out there. A couple of events this week merit a bit of attention, though. Even as it heads toward total irrelevance, the SCO Group is worth watching.

SCO launched its annual SCO Forum (evidently a rather smaller event this year) with a delightful open letter from Darl McBride. The letter, in some ways, is classic Darl; full of bluster and easy to refute. It's almost like the good old days, before SCO's lawyers finally got him to keep his mouth closed. Others have taken on the task of writing detailed rebuttals of this letter; there is no real point in doing it here.

What is truly worth noting in the latest open letter, however, is that it contains no threats to sue anybody. Darl, instead, seems to have concluded that he should maybe think about trying to sell some software. As a result, his letter is all about showing why OpenServer is better than Linux. It is FUD from one end to the other, but it is boilerplate commercial FUD of the type we have seen before. Darl seems to be working from the playbook that Microsoft discarded (as ineffective) some years ago. The "Linux has no support" line is a holdover from the 1990's. It didn't work then; there is no real reason for us to worry about it now.

The SCO Group seems to have concluded that the litigation lottery ticket is not going to pay off, and so is putting its effort into plan B. Had the company done that a few years ago, it might have gotten somewhere. At this point, however, SCO seems unlikely to survive the countercharges being leveled against it. Novell's attempt to force SCO's remaining cash into an escrow account could, on its own, suffice to end the show - before companies like IBM and Red Hat even begin to get their licks in.

Some additional amusement can be found in IBM's deposition of Erik Hughes, a SCO employee. One widely-reported outcome from this deposition (which was just recently unsealed) is that it seems likely that UnixWare's "Linux Kernel Personality" product included Linux kernel code for a couple of releases. If that is indeed the way of things, SCO may have been in violation of the GPL - at the same time it was charging copyright infringements by others.

Remember the "Chris and Darl show" teleconferences from the early days of the IBM suit? One could almost get nostalgic about those bizarre exercises. Your editor would always try to get a question in, but, somehow, tragically, time always ran out before the question could be asked. In August, 2003, a message was sent to SCO's Blake Stowell and Chris Sontag asking a question which was not heard during the teleconference: noting that the 2.4 kernel was still available from SCO's FTP server, your editor asked just how SCO was able to reconcile its claims over the kernel with the GPL and its distribution of vast amounts of code over which it could have no possible claim. An interesting, private conversation resulted, in which a SCO employee stated that he did not think the GPL was valid. Nothing publishable ever came from the exchange, however, and your editor had long since forgotten about it.

It can be a surprising experience to run across one's name unexpectedly in a legal document. IBM's lawyers, it seems, found that old message and brought it up in the Hughes deposition. Your editor, it seems, was one of a group of "long-haired smelly's" asking about the contradictions inherent in SCO's continued distribution of Linux while claiming that it contained SCO's proprietary code. The continued availability of the kernel on SCO's site has been well documented; the "smelly's" helped to document that SCO knew it was a violation of the GPL at the time.

In retrospect, it seems clear that IBM's lawyers could have disposed of the SCO threat on their own. That notwithstanding, the community's "distributed defense" response to this attack is notable. As a group, we dug up vast amounts of information, poked holes in SCO's claims, and singlehandedly won the PR battle (which IBM could not engage in). Anybody contemplating an attack on the free software community will need to think long and hard about how to handle the community's response. On the other hand, the sheer buffoonery of SCO's attack presents a risk of its own: somebody may well decide that SCO's failure resulted from poor execution, rather than an inherently bad idea. Should that happen, we may have to go through all of this again.

[Coming soon: the Grumpy and Malodorous Editor's Guide to All-Natural Deodorants.]

Comments (11 posted)

Page editor: Jonathan Corbet

Security

mod_spambot

It has been known for years that spammers harvest web sites for email addresses to add to their lists. Various sites have responded by hiding or obfuscating email addresses found on their pages; some people go to extreme measures to keep their address from ever appearing on a page. One wonders what they are worried about; your editor only receives a mere 3-4000 spams per day to his highly-public email address, after all.

Suffice to say that without SpamAssassin LWN would likely have collapsed under the flood years ago.

Some folks have decided that it is time to take a more active stance against the harvesting of email addresses from web pages. The result is an Apache module called mod_spambot; version 0.47 was recently released. The idea behind this module is to detect accesses by address harvesters and shut them down. Unfortunately, the approach this module takes is too simplistic to work in many situations.

mod_spambot is essentially a traffic throttling module. If a given site pulls down too many pages in a given time period (default is 100 pages in one hour), its access is cut off. There is also a "honeypot" option which will, instead, feed the (presumed) harvester a set of pseudo-random pages with bogus email addresses in them. This approach may well cut off some spammers, but anybody who has maintained a busy web site can see a few problems fairly quickly:

  • This approach will also cut off others who may be grabbing large numbers of pages from the site. Search engines come to mind, as do archive sites or anybody wanting to mirror a portion of a site. Cutting off people who thoughtlessly run a recursive wget to grab an entire site has some appeal; "download the site" operations account for a substantial part of LWN's bandwidth usage. But most site operators do not want to pull the plug on search engines and the like. mod_spambot allows the administrator to construct a whitelist, but who wants to figure out how to whitelist every possible search engine of interest?

  • There are some very large networks out there hiding behind a massive router and a single IP address. Traffic which looks like it originates from a single host may, in fact, be generated by hundreds of individual readers.

  • Increasingly large amounts of traffic are generated by robots whose sole purpose is to get a referrer URL onto a "top referrers" page somewhere on the site. Purveyors of Internet gambling experiences and particular types of imagery appear to like this approach to marketing. The interesting thing is that these accesses come simultaneously from a large number of IP addresses. These people, clearly, are using a network of zombie machines for their attacks. Spammers already use zombies to deliver their mail; it is hard to believe that they would not use those machines for address harvesting as well.

So throttling robots based on IP address will miss some attackers while blocking legitimate users of the site. It would be nice to prevent one's web site from being used as a resource by spammers, but this approach is not, yet, the way to that end.

Comments (16 posted)

Security news

Update on RFID passports

Bruce Schneier looks at current plans for RFID-enabled U.S. passports; it seems that things are headed in the right direction. "The most important feature they've included is an access-control system for the RFID chip. The data on the chip is encrypted, and the key is printed on the passport. The officer swipes the passport through an optical reader to get the key, and then the RFID reader uses the key to communicate with the RFID chip. This means that the passport-holder can control who has access to the information on the chip; someone cannot skim information from the passport without first opening it up and reading the information inside. Good security."

Comments (1 posted)

Greasing the wheel with Greasemonkey (SecurityFocus)

Here's a SecurityFocus column on how the recent GreaseMonkey vulnerability was handled. "If we must continue the discussion to encompass the model of open source, then I have to say that the approach Greasemonkey took shows what makes open source great: openness. Throughout the whole painful process, information was available to those who needed it: developers, IT folks, users, and security pros. No one was kept in the dark, and all the details -- code, communications, thought processes, and so on -- were always available so that interested parties could make decisions based on facts instead of promises and conjecture."

Comments (none posted)

New vulnerabilities

gaim: buffer overflow

Package(s):gaim CVE #(s):CAN-2005-2103
Created:August 10, 2005 Updated:February 27, 2006
Description: Gaim suffers from a heap-based buffer overflow which can be exploited via a hostile "away message" to execute arbitrary code.
Alerts:
Fedora-Legacy FLSA:158543 2006-02-25
Slackware SSA:2005-242-03 2005-08-31
Fedora FEDORA-2005-751 2005-08-17
Fedora FEDORA-2005-750 2005-08-17
Mandriva MDKSA-2005:139 2005-08-15
Gentoo 200508-06 2005-08-15
Ubuntu USN-168-1 2005-08-12
Red Hat RHSA-2005:589-01 2005-08-09

Comments (none posted)

sysreport: insecure temporary file

Package(s):sysreport CVE #(s):CAN-2005-2104
Created:August 9, 2005 Updated:November 10, 2005
Description: Bill Stearns discovered a bug in the way sysreport creates temporary files. It is possible that a local attacker could obtain sensitive information about the system when sysreport is run.
Alerts:
Fedora FEDORA-2005-1072 2005-11-10
Fedora FEDORA-2005-1071 2005-11-10
Red Hat RHSA-2005:598-01 2005-08-09

Comments (none posted)

ucd-snmp: denial of service

Package(s):ucd-snmp CVE #(s):CAN-2005-2177
Created:August 9, 2005 Updated:January 27, 2006
Description: A denial of service bug was found in the way ucd-snmp uses network stream protocols. A remote attacker could send a ucd-snmp agent a specially crafted packet which will cause the agent to crash.
Alerts:
Mandriva MDKSA-2006:025 2006-01-26
Ubuntu USN-190-2 2005-11-21
Debian DSA-873-1 2005-10-26
Red Hat RHSA-2005:395-01 2005-10-05
Ubuntu USN-190-1 2005-09-29
Red Hat RHSA-2005:373-01 2005-09-28
Mandriva MDKSA-2005:137 2005-08-11
Red Hat RHSA-2005:720-01 2005-08-09

Comments (none posted)

xpdf: denial of service

Package(s):xpdf kpdf CVE #(s):CAN-2005-2097
Created:August 9, 2005 Updated:August 2, 2006
Description: A flaw was discovered in Xpdf in that could allow an attacker to construct a carefully crafted PDF file that would cause Xpdf to consume all available disk space in /tmp when opened.
Alerts:
Debian DSA-1136-1 2006-08-02
Mandriva MDKSA-2005:138-1 2005-09-19
Debian DSA-780-1 2005-08-22
SuSE SUSE-SR:2005:019 2005-08-19
Fedora FEDORA-2005-732 2005-08-17
Fedora FEDORA-2005-733 2005-08-17
Gentoo 200508-08 2005-08-16
Fedora FEDORA-2005-730 2005-08-15
Fedora FEDORA-2005-729 2005-08-15
Mandriva MDKSA-2005:136 2005-08-11
Mandriva MDKSA-2005:135 2005-08-11
Mandriva MDKSA-2005:134 2005-08-11
Mandriva MDKSA-2005:138 2005-08-11
Red Hat RHSA-2005:708-01 2005-08-10
Red Hat RHSA-2005:706-01 2005-08-09
Red Hat RHSA-2005:671-01 2005-08-09
Red Hat RHSA-2005:670-01 2005-08-09
Ubuntu USN-163-1 2005-08-09

Comments (none posted)

Updated vulnerabilities

a2ps: input validation error

Package(s):a2ps CVE #(s):CAN-2004-1170 CAN-2004-1377
Created:November 26, 2004 Updated:December 19, 2005
Description: The GNU a2ps utility fails to properly sanitize filenames, which can be abused by a malicious user to execute arbitrary commands with the privileges of the user running the vulnerable application. More information at Security Focus.
Alerts:
Fedora-Legacy FLSA:152870 2005-12-17
Mandriva MDKSA-2005:097 2005-06-07
OpenPKG OpenPKG-SA-2005.003 2005-01-17
Gentoo 200501-02 2005-01-04
Debian DSA-612-1 2004-12-20
Mandrake MDKSA-2004:140 2004-11-25

Comments (none posted)

affix: two remote vulnerabilities

Package(s):affix CVE #(s):CAN-2005-2250 CAN-2005-2277
Created:July 19, 2005 Updated:September 2, 2005
Description: A buffer overflow in the Bluetooth FTP client (BTFTP) in Nokia Affix 2.1.2 and 3.2.0 allows remote attackers to execute arbitrary code via a long filename in an OBEX file share. Also remote attackers may execute arbitrary commands via shell metacharacters in the filename argument of a PUT command.
Alerts:
Debian DSA-762-1 2005-07-19

Comments (none posted)

httpd: off-by-one overflow and cross-site scripting

Package(s):apache httpd CVE #(s):CAN-2005-1268 CAN-2005-2088
Created:July 25, 2005 Updated:November 7, 2005
Description: Watchfire reported a flaw that occurred when using the Apache server as an HTTP proxy. A remote attacker could send an HTTP request with both a "Transfer-Encoding: chunked" header and a "Content-Length" header. This caused Apache to incorrectly handle and forward the body of the request in a way that the receiving server processes it as a separate HTTP request. This could allow the bypass of Web application firewall protection or lead to cross-site scripting (XSS) attacks.

Marc Stern reported an off-by-one overflow in the mod_ssl CRL verification callback. In order to exploit this issue the Apache server would need to be configured to use a malicious certificate revocation list (CRL).

Alerts:
Slackware SSA:2005-310-04 2005-11-07
Debian DSA-803-1 2005-09-08
Ubuntu USN-160-2 2005-09-07
SuSE SUSE-SA:2005:046 2005-08-16
Fedora-Legacy FLSA:157701 2005-08-10
Ubuntu USN-160-1 2005-08-04
Mandriva MDKSA-2005:130 2005-08-03
Mandriva MDKSA-2005:129 2005-08-03
Fedora FEDORA-2005-638 2005-08-02
Fedora FEDORA-2005-639 2005-08-02
Trustix TSLSA-2005-0038 2005-07-29
SuSE SUSE-SR:2005:018 2005-07-28
Red Hat RHSA-2005:582-01 2005-07-25

Comments (none posted)

apt-cacher: remote command execution

Package(s):apt-cacher CVE #(s):CAN-2005-1854
Created:August 3, 2005 Updated:August 3, 2005
Description: The Debian apt-cacher utility has a vulnerability which can allow a remote attacker to run arbitrary code on the host system.
Alerts:
Debian DSA-772-1 2005-08-03

Comments (none posted)

bzip2: race condition and infinite loop

Package(s):bzip2 CVE #(s):CAN-2005-0953 CAN-2005-1260
Created:May 17, 2005 Updated:January 10, 2007
Description: A race condition in bzip2 1.0.2 and earlier allows local users to modify permissions of arbitrary files via a hard link attack on a file while it is being decompressed, whose permissions are changed by bzip2 after the decompression is complete. Also specially crafted bzip2 archives may cause an infinite loop in the decompressor.
Alerts:
rPath rPSA-2007-0004-1 2007-01-09
Debian DSA-741-1 2005-07-07
Red Hat RHSA-2005:474-01 2005-06-16
OpenPKG OpenPKG-SA-2005.008 2005-06-10
SuSE SUSE-SR:2005:015 2005-06-07
Debian DSA-730-1 2005-05-27
Mandriva MDKSA-2005:091 2005-05-18
Ubuntu USN-127-1 2005-05-17

Comments (2 posted)

ClamAntiVirus: integer overflows

Package(s):clamav CVE #(s):CAN-2005-2450
Created:July 26, 2005 Updated:August 16, 2005
Description: Clam AntiVirus versions < 0.86.2 is vulnerable to integer overflows when handling the TNEF, CHM and FSG file formats. By sending a specially-crafted file an attacker could execute arbitrary code with the permissions of the user running Clam AntiVirus.
Alerts:
Debian DSA-776-1 2005-08-16
Mandriva MDKSA-2005:125 2005-07-27
Gentoo 200507-25 2005-07-26

Comments (none posted)

cpio: directory traversal

Package(s):cpio CVE #(s):CAN-2005-1111
Created:June 20, 2005 Updated:December 26, 2005
Description: There is a vulnerability in cpio (2.6 and previous) that allows a malicious cpio file to extract to an arbitrary directory of the attackers choice. cpio will extract to the path specified in the cpio file, this path can be absolute.
Alerts:
Mandriva MDKSA-2005:237 2005-12-23
Red Hat RHSA-2005:806-01 2005-11-10
Debian DSA-846-1 2005-10-07
Ubuntu USN-189-1 2005-09-29
Red Hat RHSA-2005:378-01 2005-07-21
Mandriva MDKSA-2005:116-1 2005-07-19
Mandriva MDKSA-2005:116 2005-07-11
Trustix TSLSA-2005-0030 2005-06-24
Gentoo 200506-16 2005-06-20

Comments (1 posted)

CUPS: multiple vulnerabilities

Package(s):CUPS CVE #(s):CAN-2004-2154
Created:July 14, 2005 Updated:September 20, 2005
Description: The CUPS printing system has a problem with queue name case-sensitivity matching that can cause a security policy override. An unauthorized user can use this to gain print to a protected queue.
Alerts:
Mandriva MDKSA-2005:165 2005-09-15
Ubuntu USN-185-1 2005-09-20
Fedora-Legacy FLSA:163274 2005-09-14
Red Hat RHSA-2005:571-01 2005-07-14

Comments (none posted)

cyrus-imapd: buffer overflows

Package(s):cyrus-imapd CVE #(s):CAN-2005-0546
Created:February 23, 2005 Updated:April 9, 2006
Description: Cyrus-imapd, prior to version 2.2.12, contains several buffer overflows which could be exploited by an (authenticated) attacker to run code on the server system.
Alerts:
Fedora-Legacy FLSA:156290 2006-04-04
Red Hat RHSA-2005:408-01 2005-05-17
Fedora FEDORA-2005-339 2005-04-27
OpenPKG OpenPKG-SA-2005.005 2005-04-05
Conectiva CLA-2005:937 2005-03-17
Mandrake MDKSA-2005:051 2005-03-04
Ubuntu USN-87-1 2005-02-28
SuSE SUSE-SA:2005:009 2005-02-24
Gentoo 200502-29 2005-02-23

Comments (none posted)

dbus: information disclosure

Package(s):dbus CVE #(s):CAN-2005-0201
Created:June 8, 2005 Updated:August 30, 2005
Description: From the Red Hat alert: "Dan Reed discovered that a user can send and listen to messages on another user's per-user session bus if they know the address of the socket." At current usage levels, this vulnerability is not particularly threatening.
Alerts:
Fedora FEDORA-2005-822 2005-08-29
Ubuntu USN-144-1 2005-06-27
Mandriva MDKSA-2005:105 2005-06-24
Red Hat RHSA-2005:102-01 2005-06-08

Comments (none posted)

dhcpcd: denial of service

Package(s):dhcpcd CVE #(s):CAN-2005-1848
Created:July 13, 2005 Updated:September 13, 2005
Description: The dhcpcd DHCP client can be tricked into reading past the end of a buffer, causing it to crash.
Alerts:
Slackware SSA:2005-255-01 2005-09-13
Red Hat RHSA-2005:603-01 2005-07-27
Gentoo 200507-16 2005-07-15
Mandriva MDKSA-2005:117 2005-07-12
Debian DSA-750-1 2005-07-11

Comments (none posted)

ekg: multiple vulnerabilities

Package(s):ekg CVE #(s):CAN-2005-1850 CAN-2005-1851 CAN-2005-1916
Created:July 18, 2005 Updated:August 8, 2005
Description: Several vulnerabilities have been discovered in the ekg contributed scripts. These include an insecure temporary file creation problem, a potential shell command injection problem, and an arbitrary command execution problem.
Alerts:
Ubuntu USN-162-1 2005-08-08
Debian DSA-760-1 2005-07-18

Comments (none posted)

emacs21: format string vulnerability in "movemail"

Package(s):emacs21 CVE #(s):CAN-2005-0100
Created:February 7, 2005 Updated:May 15, 2006
Description: Max Vozeler discovered a format string vulnerability in the "movemail" utility of Emacs. By sending specially crafted packets, a malicious POP3 server could cause a buffer overflow, which could be exploited to execute arbitrary code with the privileges of the user and the "mail" group.
Alerts:
Fedora-Legacy FLSA:152898 2006-05-12
Debian DSA-685-1 2005-02-17
Mandrake MDKSA-2005:038 2005-02-15
Gentoo 200502-20 2005-02-15
Fedora FEDORA-2005-146 2005-02-14
Fedora FEDORA-2005-145 2005-02-14
Red Hat RHSA-2005:133-01 2005-02-15
Red Hat RHSA-2005:110-01 2005-02-15
Red Hat RHSA-2005:134-01 2005-02-10
Red Hat RHSA-2005:112-01 2005-02-10
Fedora FEDORA-2005-116 2005-02-08
Fedora FEDORA-2005-115 2005-02-08
Debian DSA-671-1 2005-02-08
Debian DSA-670-1 2005-02-08
Ubuntu USN-76-1 2005-02-07

Comments (none posted)

enscript: arbitrary code execution

Package(s):enscript CVE #(s):CAN-2004-1184 CAN-2004-1185 CAN-2004-1186
Created:January 21, 2005 Updated:May 27, 2006
Description: Erik Sjölund has discovered several security relevant problems in enscript, a program to convert ASCII text into Postscript and other formats. Unsanitized input can cause the execution of arbitrary commands via EPSF pipe support. Due to missing sanitizing of filenames it is possible that a specially crafted filename can cause arbitrary commands to be executed. Multiple buffer overflows can cause the program to crash.
Alerts:
rPath rPSA-2006-0083-1 2006-05-26
Fedora-Legacy FLSA:152892 2005-12-17
Red Hat RHSA-2005:040-01 2005-02-15
Mandrake MDKSA-2005:033 2005-02-10
Gentoo 200502-03 2005-02-02
Red Hat RHSA-2005:039-01 2005-02-01
Fedora FEDORA-2005-096 2005-01-31
Fedora FEDORA-2005-092 2005-01-28
Fedora FEDORA-2005-091 2005-01-28
Fedora FEDORA-2005-016 2005-01-26
Fedora FEDORA-2005-015 2005-01-26
Ubuntu USN-68-1 2005-01-24
Debian DSA-654-1 2005-01-21

Comments (none posted)

epiphany: Mozilla regression vulnerability

Package(s):epiphany CVE #(s):
Created:July 28, 2005 Updated:August 29, 2005
Description: The epiphany web browser had a vulnerability regression that was caused by fixes to the Mozilla suite. This is specific to Ubuntu Linux, the Mozilla fix was: USN-155-1.
Alerts:
Ubuntu USN-155-2 2005-07-28

Comments (none posted)

ethereal: dissector vulnerabilities

Package(s):ethereal CVE #(s):CAN-2005-2365 CAN-2005-2367 CAN-2005-2360 CAN-2005-2361 CAN-2005-2362 CAN-2005-2363 CAN-2005-2364 CAN-2005-2366
Created:July 28, 2005 Updated:October 10, 2005
Description: The ethereal network traffic analyzer has several vulnerabilities, involving traffic dissectors. Dissectors have buffer overflows, format string overflows, and crashing/denial of service issues.
Alerts:
Debian DSA-853-1 2005-10-09
Red Hat RHSA-2005:687-01 2005-08-10
Mandriva MDKSA-2005:131 2005-08-04
Fedora FEDORA-2005-655 2005-07-29
Fedora FEDORA-2005-651 2005-07-28
Gentoo 200507-27 2005-07-28

Comments (none posted)

evolution: message crash vulnerability

Package(s):evolution CVE #(s):CAN-2005-0806
Created:March 17, 2005 Updated:August 11, 2005
Description: The Evolution mail client can be crashed when reading certain types of messages.
Alerts:
Ubuntu USN-166-1 2005-08-11
Red Hat RHSA-2005:397-01 2005-05-04
Conectiva CLA-2005:950 2005-04-27
Fedora FEDORA-2005-338 2005-04-22
Mandrake MDKSA-2005:059 2005-03-16

Comments (none posted)

fetchmail: buffer overflow

Package(s):fetchmail CVE #(s):CAN-2005-2335
Created:July 21, 2005 Updated:August 12, 2005
Description: The fetchmail POP3 client has an arbitrary code execution vulnerability that may be triggered by a malicious POP server. See this advisory for more information.
Alerts:
Debian DSA-774-1 2005-08-12
Mandriva MDKSA-2005:126 2005-07-28
OpenPKG OpenPKG-SA-2005.016 2005-07-28
Ubuntu USN-153-1 2005-07-26
Gentoo 200507-21 2005-07-25
Red Hat RHSA-2005:640-01 2005-07-25
Slackware SSA:2005-203-05 2005-07-23
Fedora FEDORA-2005-614 2005-07-21
Fedora FEDORA-2005-613 2005-07-21

Comments (none posted)

Foomatic: Arbitrary command execution in foomatic-rip

Package(s):foomatic CVE #(s):CAN-2004-0801
Created:September 20, 2004 Updated:May 31, 2006
Description: There is a vulnerability in the foomatic-filters package. This vulnerability is due to insufficient checking of command-line parameters and environment variables in the foomatic-rip filter. This vulnerability may allow both local and remote attackers to execute arbitrary commands on the print server with the permissions of the spooler.
Alerts:
SuSE SUSE-SA:2006:026 2006-05-30
Fedora-Legacy FLSA:2076 2004-11-05
Conectiva CLA-2004:880 2004-10-27
Fedora FEDORA-2004-303 2004-09-21
Gentoo 200409-24 2004-09-20

Comments (none posted)

gdb: multiple vulnerabilities

Package(s):gdb CVE #(s):CAN-2005-1704 CAN-2005-1705
Created:May 20, 2005 Updated:August 11, 2006
Description: Tavis Ormandy of the Gentoo Linux Security Audit Team discovered an integer overflow in the BFD library, resulting in a heap overflow. A review also showed that by default, gdb insecurely sources initialization files from the working directory. Successful exploitation would result in the execution of arbitrary code on loading a specially crafted object file or the execution of arbitrary commands.
Alerts:
Red Hat RHSA-2006:0354-01 2006-08-10
Red Hat RHSA-2006:0368-01 2006-07-20
Mandriva MDKSA-2005:215 2005-11-23
Fedora FEDORA-2005-1033 2005-10-27
Fedora FEDORA-2005-1032 2005-10-27
Red Hat RHSA-2005:801-01 2005-10-18
Red Hat RHSA-2005:763-01 2005-10-11
Red Hat RHSA-2005:709-01 2005-10-05
Red Hat RHSA-2005:673-01 2005-10-05
Red Hat RHSA-2005:659-01 2005-09-28
Fedora FEDORA-2005-498 2005-06-29
Fedora FEDORA-2005-497 2005-06-29
Gentoo 200506-01 2005-06-01
Trustix TSLSA-2005-0025 2005-05-31
Mandriva MDKSA-2005:095 2005-05-30
Ubuntu USN-136-2 2005-05-27
Ubuntu USN-136-1 2005-05-27
Ubuntu USN-135-1 2005-05-27
Gentoo 200505-15 2005-05-20

Comments (5 posted)

gtk-pixbuf, gtk2: denial of service

Package(s):gdk-pixbuf gtk2 CVE #(s):CAN-2005-0891
Created:March 30, 2005 Updated:December 19, 2005
Description: The BMP image processing code in gdk-pixbuf and gtk2 contains a denial of service vulnerability exploitable via a specially crafted image file.
Alerts:
Fedora-Legacy FLSA:155510 2005-12-17
Fedora-Legacy FLSA:154272 2005-07-15
SuSE SUSE-SR:2005:010 2005-04-08
Mandrake MDKSA-2005:069 2005-04-07
Mandrake MDKSA-2005:068 2005-04-07
Ubuntu USN-108-1 2005-04-05
Red Hat RHSA-2005:343-01 2005-04-05
Red Hat RHSA-2005:344-01 2005-04-01
Fedora FEDORA-2005-268 2005-03-30
Fedora FEDORA-2005-267 2005-03-30
Fedora FEDORA-2005-266 2005-03-30
Fedora FEDORA-2005-265 2005-03-30

Comments (none posted)

gettext: Insecure temporary file handling

Package(s):gettext CVE #(s):CAN-2004-0966
Created:October 11, 2004 Updated:March 1, 2006
Description: gettext insecurely creates temporary files in world-writeable directories with predictable names. A local attacker could create symbolic links in the temporary files directory, pointing to a valid file somewhere on the filesystem. When gettext is called, this would result in file access with the rights of the user running the utility, which could be the root user.
Alerts:
Mandriva MDKSA-2006:051 2006-02-28
Fedora-Legacy FLSA:136323 2006-01-09
Gentoo 200410-10:02 2004-10-10
OpenPKG OpenPKG-SA-2004.055 2004-12-23
Ubuntu USN-5-1 2004-10-27
Gentoo 200410-10 2004-10-10

Comments (1 posted)

ghostscript: symlink vulnerabilities

Package(s):ghostscript CVE #(s):CAN-2004-0967
Created:October 20, 2004 Updated:September 28, 2005
Description: The ghostscript package (prior to version 7.07.1-r7) contains several scripts which are vulnerable to symlink attacks.
Alerts:
Red Hat RHSA-2005:081-01 2005-09-28
Ubuntu USN-3-1 2004-10-27
Gentoo 200410-18 2004-10-20

Comments (none posted)

glibc: tempfile vulnerability in catchsegv script

Package(s):glibc CVE #(s):CAN-2004-0968
Created:October 21, 2004 Updated:November 14, 2005
Description: The catchsegv script in the glibc package has a symlink vulnerability that may allow a local user to overwrite arbitrary files with the permissions of the user that is running the script.
Alerts:
Fedora-Legacy FLSA:152848 2005-11-13
Red Hat RHSA-2005:261-01 2005-04-28
Debian DSA-636-1 2005-01-12
Mandrake MDKSA-2004:159 2004-12-29
Red Hat RHSA-2004:586-01 2004-12-20
Fedora FEDORA-2004-356 2004-11-11
Ubuntu USN-4-1 2004-10-27
Gentoo 200410-19 2004-10-21

Comments (none posted)

gnupg: information leak

Package(s):gnupg CVE #(s):CAN-2005-0366
Created:March 16, 2005 Updated:August 19, 2005
Description: GnuPG (and other PGP-like systems) suffers from an information leak which could, in some situations, be used by an attacker to obtain plain text from an encrypted message. See this message for a detailed explanation of the problem. "We know of no real-world application that is affected by this type of attack. It is an attack that requires the active participation of someone who holds the actual key required to decrypt a message. Thus, it is not something you are likely to see."
Alerts:
Ubuntu USN-170-1 2005-08-19
Gentoo 200503-29 2005-03-24
Mandrake MDKSA-2005:057 2005-03-15

Comments (none posted)

gopher: insecure tmpfile creation

Package(s):gopher CVE #(s):CAN-2005-1853
Created:July 29, 2005 Updated:August 3, 2005
Description: John Goerzen discovered that gopher, a client for the Gopher Distributed Hypertext protocol, creates temporary files in an insecure fashion.
Alerts:
Debian DSA-770-1 2005-07-29

Comments (none posted)

grip: buffer overflow

Package(s):grip CVE #(s):CAN-2005-0706
Created:March 10, 2005 Updated:September 16, 2005
Description: Grip, a CD ripper, has a buffer overflow vulnerability that can occur when the CDDB server returns more than 16 matches.
Alerts:
Fedora-Legacy FLSA:152919 2005-09-15
Mandriva MDKSA-2005:074 2005-04-20
Mandriva MDKSA-2005:075 2005-04-20
Gentoo 200504-07 2005-04-08
Mandrake MDKSA-2005:066 2005-04-01
Red Hat RHSA-2005:304-01 2005-03-28
Gentoo 200503-21 2005-03-17
Fedora FEDORA-2005-203 2005-03-09
Fedora FEDORA-2005-202 2005-03-09

Comments (none posted)

groff: insecure temporary directory

Package(s):groff CVE #(s):CAN-2004-0969
Created:November 1, 2004 Updated:February 9, 2006
Description: Recently, Trustix Secure Linux discovered a vulnerability in the groff package. The utility "groffer" created a temporary directory in an insecure way, which allowed exploitation of a race condition to create or overwrite files with the privileges of the user invoking the program.
Alerts:
Mandriva MDKSA-2006:038 2006-02-08
Gentoo 200411-15 2004-11-08
Ubuntu USN-13-1 2004-11-01

Comments (none posted)

gzip: arbitrary command execution

Package(s):gzip CVE #(s):CAN-2005-0758
Created:August 1, 2005 Updated:January 9, 2007
Description: zgrep in gzip before 1.3.5 does not handle shell metacharacters like '|' and '&' properly when they occurred in input file names. This could be exploited to execute arbitrary commands with user privileges if zgrep is run in an untrusted directory with specially crafted file names.
Alerts:
OpenPKG OpenPKG-SA-2007.002 2007-01-08
Mandriva MDKSA-2006:027 2006-01-30
Mandriva MDKSA-2006:026 2006-01-30
Fedora-Legacy FLSA:158801 2005-11-14
Fedora-Legacy FLSA:157696 2005-08-10
Ubuntu USN-161-1 2005-08-04
Ubuntu USN-158-1 2005-08-01

Comments (2 posted)

heartbeat: insecure temporary files

Package(s):heartbeat CVE #(s):CAN-2005-2231
Created:July 19, 2005 Updated:August 15, 2005
Description: Eric Romang discovered several insecure temporary file creations in the High Availability Linux Project Heartbeat 1.2.3.
Alerts:
Debian DSA-761-2 2005-08-15
Ubuntu USN-165-1 2005-08-11
Mandriva MDKSA-2005:132 2005-08-09
Gentoo 200508-05 2005-08-07
Debian DSA-761-1 2005-07-19

Comments (none posted)

htdig: cross site scripting

Package(s):htdig CVE #(s):CAN-2005-0085
Created:February 14, 2005 Updated:January 10, 2006
Description: Michael Krax discovered that ht://Dig fails to validate the 'config' parameter before displaying an error message containing the parameter. This flaw could allow an attacker to conduct cross-site scripting attacks.
Alerts:
Fedora-Legacy FLSA:152907 2006-01-09
Mandrake MDKSA-2005:063 2005-03-31
Red Hat RHSA-2005:090-01 2005-02-15
Debian DSA-680-1 2005-02-14
Gentoo 200502-16 2005-02-13

Comments (none posted)

imap: buffer overflow in c-client

Package(s):imap CVE #(s):CAN-2003-0297
Created:February 18, 2005 Updated:April 9, 2006
Description: A buffer overflow flaw was found in the c-client IMAP client. An attacker could create a malicious IMAP server that if connected to by a victim could execute arbitrary code on the client machine.
Alerts:
Fedora-Legacy FLSA:184074 2006-04-04
Fedora-Legacy FLSA:152912 2005-05-12
Red Hat RHSA-2005:114-01 2005-02-18

Comments (none posted)

imlib2: buffer overflows

Package(s):imlib2 CVE #(s):CAN-2004-0802 CAN-2004-0817
Created:September 8, 2004 Updated:October 26, 2005
Description: The imlib2 library contains buffer overflows in the BMP handling code.
Alerts: </
Debian DSA-548-2 2005-10-26
Conectiva CLA-2004:870 2004-09-28
Debian DSA-552-1 2004-09-22
Debian DSA-548-1 2004-09-16
Red Hat RHSA-2004:465-01 2004-09-15
Gentoo 200409-12 2004-09-08