LWN.net Logo

LWN.net Weekly Edition for February 5, 2004

Of Copyright Transfers, Slander of Title, and SCO

February 4, 2004

By Pamela Jones, Editor of Groklaw

A lot of people are curious about SCO's lawsuit against Novell for "slander of title." First, most people have never heard of such a claim before and don't know what it is. Second, since the dispute surrounds a question of transfer of copyrights, how exactly are copyrights validly transfered and did there occur such a transfer between Novell and SCO? And third, why sue for slander of title instead of bringing a breach of contract claim or both together?

Taking those questions in order, first, what is "slander of title"? Normally a claim you find in real estate matters, it's defined as "false, unjustified statements regarding another person's title to property". There are elements you must prove to win:

A cause of action for slander of title occurs when there is a false and malicious statement made to disparage a person's title to real estate. The elements of slander of title are: (1) falsity of the statement made; and (2) malice.

If you own a house, and I know I don't but I claim to be the owner anyway, you can sue me for slander of title, because I have cast a cloud over your ownership claim in that house. There is such a thing as libel not only to your personal reputation but also to the reputation of property. You can read a bit more on that here if you are interested.

But if it's instead a good-faith conflict, in which each side thinks it really does own the house, well, that's a different kettle of fish. It still needs to get worked out in the courts, but it isn't slander of title, because it's not malicious to assert what you believe are your legal rights. Otherwise there could never be a contract dispute.

Malice is also a necessary element in a slander claim. The malicious claim must be intentional and without reasonable cause:

To recover in an action for slander of title, a party must allege and prove: (i) the utterings and publishing of disparaging words; (ii) that they were false; (iii) that they were malicious; (iv) that special damages were sustained thereby; (v) that the plaintiff possessed an estate or interest in the property disparaged; and (vi) the loss of a specific sale. Malice as a basis for recovery of actual damages in a slander of title case means merely that the acts must have been deliberate conduct without reasonable cause....

As compared to other 'injurious falsehood' causes of action, slander of title or property differs in that there is no presumption of damages. The plaintiff must show that he or she sustains special damage proximately, naturally and reasonably resulting from the alleged slander.... The plaintiff must prove the loss of a specific sale, i.e., that a pending sale was defeated by the slander.

That has a bearing, obviously, on SCO's case against Novell. And it's why some are questioning their choice to use that claim. If you read Novell's letters, do you get the impression that they feel they actually do own the copyrights? Note particularly the letters dated May 28, June 6 and 26, August 4, and October 9 to follow the copyright argument. If Novell honestly believes that it owns the copyrights, there is no slander of title. The necessary element of malice would be missing. It's not slander if the party has a valid claim. Novell claims it did not transfer the copyrights to SCO. This raises the possibility that Novell could win on that basis alone.

Can SCO succeed is establishing its claims to copyright on Unix code? Some have expressed doubt. And even if SCO were to succeed in establishing that Novell has no copyrights, there is a deeper question, namely: what can and what can't you copyright when it comes to software?

Who owns the copyrights here anyway? To delve into it deeply, you would need to read the contracts involved, and after you do, I'm guessing you still won't be 100% sure, though you may well find yourself leaning toward Novell. SCO highlights, in particular, Amendment 2 to the Asset Purchase Agreement, but Novell points out that there were other documents, including Amendment 1, the Schedules, and a Technology License Agreement, although the latter does not pertain to the copyright issue. Novell isn't saying SCO has no rights. Novell is saying it retained certain rights, that SCO needed to assert a need for copyrights and that it never did that, that there were, in other words, conditions that SCO has not satisfied. Because they did not satisfy the conditions, the copyrights never transfered.

Why didn't SCO sue for breach of contract, then, if their position is correct and copyrights were supposed to transfer and Amendment 2 is the contract that was to make that happen? No one I have talked to can figure that out. At least one attorney I asked about this thinks that failure to assert a breach of contract claim will prove fatal to SCO's chances of prevailing in the slander of title claim. While SCO alleges that the copyrights were to have transferred under the Asset Purchase Agreement, clearly it didn't happen, or there would be no dispute heading to court. So why not sue for breach of contract and ask the judge to enforce the contract?

SCO has been claiming that its rights to Unix were absolute, but all the while it turns out it was in hot and heavy correspondence with Novell, so its rights were contested all along. That fact alone, the fact that Novell firmly asserted what it claims to be its rights, indicates that SCO may have great difficulty persuading a judge that malice was involved. If you have read the contract documents, you already know it is far from obvious that Novell has no legitimate claim.

SCO registered for copyrights, but so did Novell. SCO would need to show that Novell transfered those rights to SCO. And it had to have been in writing, because copyright law requires copyright transfers to be in writing and "signed by the owner of the rights conveyed or such owner's duly authorized agent." For example, a friend of mine, who just registered a copyright in some music he wrote, got a letter from the US Copyright Office that included this sentence:

Copyright belongs initially to the author. It may be transferred to another person or organization by a written agreement or by operation of law. For registration purposes, the copyright claimant is either (1) the author or (2) the person or organization that has obtained ownership of all rights under the copyright.

Here, that would mean Novell, who would have to transfer by writing to SCO. There is no official US Copyright Office form for a copyright transfer, so normally they are effectuated by contract. Here are some examples of copyright transfer forms some have used, to give you an idea, here and here and here (PDF format) and here (also PDF).

So is the Asset Purchase Agreement plus amendments and schedules a contract? Yes. Is a contract enough to transfer a copyright? Yes. Is it clear on its face that this contract did mean to effectuate such a transfer? That is not clear to many readers, and obviously Novell doesn't think so. And intriguingly, if SCO ultimately fails to establish copyright ownership, after publicly asserting Linux is infringing its copyrights for nearly a year, and particularly if it sues end users for copyright infringement, and it turns out their claim to copyright had no reasonable basis and they knew it, is SCO opening itself up to a possible claim of slander to title itself?

Comments (7 posted)

Needed: code auditors

Free software is said to be more secure than the proprietary alternatives for a number of reasons. Near the top of most peoples' lists is the openness of the code: with all those eyeballs on the code, security problems are found and fixed quickly. Over the years, however, we have seen numerous signs that fewer people are actually looking at code than many of us would like to believe. Too many vulnerabilities remain in our programs for years for us to have any real confidence that comprehensive auditing is going on.

There have been attempts to encourage developers to audit code. Almost exactly two years ago, the announcement went out for the Sardonix project. Sardonix was started after Crispin Cowan noted that the Linux Security Audit Project appeared to have stalled. Since auditing was not happening by itself, Sardonix sought to provide some motivation in the form of infrastructure and credit for auditors. With these incentives, it was hoped, some large-scale code auditing would start to happen.

Thus, with a little help from a DARPA grant, the Sardonix portal was launched. The portal would track the audit state of various free software programs and would give credit to those who did the auditing work. Sufficiently skilled and productive auditors would be able to accumulate a large "audit karma" to show their friends - and help improve the security of free software at the same time.

Two years later, the only auditing work which has been done on Sardonix was a small set of projects assigned by a university professor to his students. The last posting to the Sardonix mailing list was sent in November, 2003. The DARPA money has run out. Sardonix, it seems, is a project which has failed.

One can attribute this failure to a number of reasons. Certainly Sardonix was never promoted very well; almost nothing was heard from the project after the initial announcement. With an effort to jump-start the process and a set of vulnerabilities found by Sardonix auditors posted on Bugtraq, the project might just have achieved critical mass. As it is, Sardonix vanished into obscurity shortly after its launch, and few people ever heard of it again.

The sad fact remains, however, that, with or without Sardonix, very little auditing is getting done. The continuing stream of vulnerability reports, many for problems which have lurked undetected for years, make this clear. Auditing code is difficult, tedious, and error-prone work. It also tends to be thankless; strangely enough, many developers do not welcome news of vulnerabilities in their work (though most do respond and fix the problems). New vulnerability information requires careful handling; a sustained effort may be required to get the developer to take the problem seriously, but widespread disclosure of the problem must be avoided until developers and distributors have had a chance to react. To top it off, those who do seek out vulnerabilities in software are often seen as promoting their own agendas and making the problem worse. It is not surprising that few people are stepping up and taking on this work.

The free software community has a lot of work to do if it wants to live up to its promise of greater security. This battle must be fought on many fronts: safer programming techniques, containment strategies, detection and response, etc. But we also, somehow, have to find a way to get more critical eyeballs looking at our code. As recent events have shown, the black hats are already doing this work for their own purposes. If free software wants to live up to its pretensions of being a more secure alternative, it needs more developers reviewing the code.

Comments (17 posted)

UserLinux Moves Forward

February 4, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

A lot has been happening on the UserLinux front since Bruce Perens first publicly announced the project in October. The project has moved through the early discussion and design phases and is now moving into early install testing with its own package repository. There is also a fairly comprehensive Wiki for UserLinux with everything from project policies and package framework to the marketing concept and mission statement:

Provide businesses with freely available, high quality Debian based GNU/Linux operating systems accompanied by certifications, service, and support options designed to encourage productivity and security while reducing overall costs.

Users and developers who are eager to try out UserLinux will find instructions on creating a UserLinux system by converting a Debian unstable system using the UserLinux package repository. At the moment, the UserLinux package repository only has three meta-packages, one for each UserLinux configuration: Desktop, server and server-gui. By adding the UserLinux repository to a system's /etc/apt/sources.list, users can use apt to retrieve the packages necessary to run under one of the UserLinux profiles.

KDE, however, is not in the package lists. A recent email from Bruce Perens to the UserLinux discussion list provoked Slashdot and a few other news sites to declare that UserLinux would support KDE after all. We touched base with Perens on Tuesday, and he said that this comment has been misinterpreted:

The project policy remains the same -- the official GUI will remain GNOME. The option was always there for commercial service providers to support KDE, or any other add-on software that they would like. That little one line and they got excited. The fact is that a customer asked me to support KDE, and I said 'sure, I'll take your money to support any open source software.'

In the past, Perens has mentioned that some companies have approached him about the UserLinux concept. We asked Perens if he was now able to name any of the companies that had expressed interest in backing UserLinux. Perens declined to give the name of any companies he'd spoken with, saying that he was in contract negotiations and he could not give any names at this time. He also said that he asks people not to speculate on the companies he may be in talks with, as it might give potential backers cold feet.

We also asked if there was a lot of work needed to make Debian "enterprise-ready." Perens said that Debian is a "solid base" and that there are only a few areas where Debian really needs improvement.

It's important to concentrate on Debian's strengths... I can't beat the quality of Debian. A lot of what I'm doing on the UserLinux project is making sure that Debian's good points are not compromised and that we take advantage of all the good decisions that they've made...I want to be able to take Debian into the enterprise without doing anything to dissuade the Debian developers.

He did acknowledge that there are some areas which need improvement. For example, Perens noted that some Debian packages are installed in a non-functional state by default. Perens said that all packages should be installed in a "working state" even if it's just a demo configuration for testing. He also noted that UserLinux will need to support batch or cluster installs, and that the new Debian installer will make Debian much more business-friendly.

For developers who want to contribute to the project, Perens says that he'd like to see them go through the Debian Developer process and check any packages into the Debian repository first. "I would not like to see a large repository of free software that does not live in Debian for some reason." He said that he expects that UserLinux will begin to draw new people into the project now that the project has entered the testing and development phase.

When can we expect to see an official release of UserLinux? Perens said that there is no firm date, but that the rough date for a release of UserLinux will correspond with the Debian Sarge release. He also noted that UserLinux will be providing pre-releases and CD releases before then.

Comments (18 posted)

New site feature: comment response notifications

Occasionally we get a request from readers to receive copies of responses to their posted comments via email. We have recently freed up a bit of hacking time and added that capability as a subscriber-only feature, with a bit of a twist. That twist is this: response notifications are only available to subscribers at the "professional hacker" level or above.

When we switched over to the subscription model, we implemented the "starving hacker" level as a way for people who couldn't afford the full LWN rate to subscribe anyway. The intended audience was students, people who were looking for work, and those in parts of the world where $5 was a lot of money. Over time, we have noticed a few trends:

  • $5 is no longer very much money in much of the world.

  • People should be having an easier time finding jobs. Our President says so, so It Must Be True.

  • The percentage of our subscriber base taking the "starving hacker" option has grown significantly.

The conclusion we have come to is that, as LWN (hopefully) grows, we need a way to motivate people to select the full-rate option that goes beyond "you'll feel better because you're supporting LWN." Given a cheaper choice with the same benefits, many people will, rationally, take that route.

So limiting response emails to the higher subscription levels is a bit of an experiment. Hopefully, it is a small inducement to select a higher subscription level which does not actually deny anything truly important to the "starving hacker" subscribers. We may take a similar approach with other new features in the future, depending on how this one works out.

Getting response notifications is easy: there is a new dialog that shows up when a comment is published that enables the email feature. There is an expiration date, and the option to get notifications for responses all the way down the tree. There are a couple of things worthy of note:

  • We need to have your email address to be able to send responses to you. If you have not given us a working address, the feature won't work. The My Account page can be used to set your address if need be. Also, please don't expect us to navigate through challenge-response systems to send you email.

  • If you get tired of seeing notifications, the My Account page will let you turn them off.

You can also set your default response preferences in the account customization area. While adding that capability, we also, finally, added an option for the default setting of the "plain text/HTML" flag for comments.

Comments (38 posted)

Page editor: Jonathan Corbet

Security

Security news

Fixing spam with postage

Bill Gates has recently come up with an idea for the spam problem: charge postage for email. This idea is far from new, of course, but, when Bill says it, more people listen. On its face, the idea has a certain amount of appeal. Spammers exist because the economics of the email system favor them: large amounts of mail can be sent for no money, meaning that even very small response rates can be profitable. Adding even a small per-message cost would change the situation considerably. Some variations of the scheme have email recipients pocketing the postage themselves, perhaps only if they decide the associated message was unwanted. Others have ISPs collecting that money; for some strange reason, most ISPs tend to be more interested in the latter approach.

There are, of course, a few practical problems with this idea. Large mailing lists, for example. If people sending to a list have to pay postage for every recipient, list traffic is likely to drop considerably. If, instead, a message to a list is paid as a single message, large lists will remain attractive targets for at least some spammers.

The real problem, however, is that the postage approach, in most implementations, takes a classic end-to-end Internet service and turns it into something centralized. Certainly, one can envision a nice system based on micro-payments where individual users have mail clients which deal with postage issues directly and no central authority is involved. Envisioning MSN or Yahoo choosing such a system is rather harder, however. They will, instead, create a central "post office" which enforces the postage policy and which collects some or all of the money involved. The result is unlikely to resemble the email system we have known for the past couple decades or so.

A central post office will require enforcement mechanisms, or people will quickly learn to bypass it. It is hard to imagine unstamped email being easier to stop than, say, music downloads. A postage-for-email scheme looks like a sure way to set off another Internet arms race.

Things would be worse if the imposition of a central post office were actually made to work. The temptation to start filtering mail, initially for viruses or some such, would likely prove irresistible. Beyond doubt, the types of mail requiring filtering would grow over time. A central post office would also be an ideal place for governments to apply taxes to electronic mail as their contribution to ending the spam problem. There are also obvious privacy issues to worry about in this scenario.

The "postage stamp" approach to spam thus looks problematic on many fronts. Before assuming that these problems would block the acceptance of a central post office, however, one should keep this in mind: the spam problem is getting worse quickly. A great many users will be willing to give up a fair amount of their freedom to somebody who can come up with something that looks like a working solution. This is a scary idea, but it is also a great opportunity. If the free software community can come up with a solution to the bulk of the spam problem while preserving our decentralized net and our freedom, World Domination will be that much closer.

Comments (26 posted)

Security posters from Microsoft

[Worm crossing!] Microsoft has had some high-profile security problems recently. A big company like that knows what to do in this sort of situation, however: release a set of motivational posters for the work place. The three posters are downloadable in PDF format; surely our community has no end of gimp artists who can improve on them. Remember: "Protect your stuff: use up-to-date antivirus software."

Comments (5 posted)

New vulnerabilities

crawl: buffer overflow

Package(s):crawl CVE #(s):CAN-2004-0103
Created:February 3, 2004 Updated:February 4, 2004
Description: Steve Kemp from the GNU/Linux audit project discovered a problem in crawl, another console based dungeon exploration game, in the vein of nethack and rogue. The program uses several environment variables as inputs but doesn't apply a size check before copying one of them into a fixed size buffer.
Alerts:
Debian DSA-432-1 2004-02-03

Comments (none posted)

perl information leak

Package(s):perl CVE #(s):CAN-2003-0618
Created:February 2, 2004 Updated:April 21, 2004
Description: Paul Szabo discovered a number of bugs in suidperl, a helper program to run perl scripts with setuid privileges. By exploiting these bugs, an attacker could abuse suidperl to discover information about files (such as testing for their existence and some of their permissions) that should not be accessible to unprivileged users.
Alerts:
Debian DSA-431-2 2004-04-16
Debian DSA-431-1 2004-02-01

Comments (none posted)

util-linux: information leak in the login program

Package(s):util-linux CVE #(s):CAN-2004-0080
Created:February 3, 2004 Updated:April 8, 2004
Description: The util-linux package contains a large variety of low-level system utilities that are necessary for a Linux system to function.

In some situations, the login program could use a pointer that had been freed and reallocated. This could cause unintentional data leakage.

Alerts:
Netwosix NW-2004-0010 2004-04-08
Gentoo 200404-06 2004-04-07
Fedora-Legacy FLSA:1256 2004-03-04
Whitebox WBSA-2004:056-01 2004-02-12
Red Hat RHSA-2004:056-01 2004-02-02

Comments (1 posted)

Updated vulnerabilities

apache: buffer overflows in mod_alias, mod_rewrite

Package(s):apache CVE #(s):CAN-2003-0542 CAN-2003-0789
Created:October 28, 2003 Updated:February 13, 2004
Description: André Malo discovered buffer overflows in the mod_alias and mod_rewrite modules of the Apache webserver. These occurred if a regular expression with more than 9 capturing parenthesis was configured. To exploit this, an attacker would need to be able to locally create a carefully crafted configuration file (.htaccess or httpd.conf). CAN-2003-0542

Another buffer overflow in Apache 2.0.47 and earlier in mod_cgid's mishandling of CGI redirect paths could result in CGI output going to the wrong client when a threaded MPM is used. CAN-2003-0789.

Alerts:
Whitebox WBSA-2004:015-01 2004-02-12
Fedora FEDORA-2003-004 2004-01-08
Red Hat RHSA-2003:405-00 2003-12-18
Red Hat RHSA-2003:320-01 2003-12-16
Red Hat RHSA-2003:360-01 2003-12-10
Gentoo 200310-03 2003-10-28
Trustix 2003-0041 2003-11-15
Conectiva CLA-2003:775 2003-11-05
Slackware SSA:2003-308-01 2003-11-03
EnGarde ESA-20031105-030 2003-11-05
Mandrake MDKSA-2003:103 2003-11-03
Gentoo 200310-04 2003-10-31
Immunix IMNX-2003-7+-025-01 2003-10-28
OpenPKG OpenPKG-SA-2003.046 2003-10-28

Comments (none posted)

apache2: Denial of Service vulnerability

Package(s):apache2 CVE #(s):
Created:September 29, 2003 Updated:March 25, 2004
Description: A problem was discovered in Apache2 where CGI scripts that write more than 4k to the standard error stream will hang the script's execution. This problem can lead to a denial of service situation. See this bug report for additional details.
Alerts:
Gentoo 200403-04 2004-03-22
Netwosix NW-2004-0006 2004-03-25
Mandrake MDKSA-2003:096-1 2003-10-24
Mandrake MDKSA-2003:096 2003-09-26

Comments (none posted)

bind: cache poisoning

Package(s):bind CVE #(s):CAN-2003-0914
Created:November 26, 2003 Updated:February 19, 2004
Description: A cache poisoning vulnerability in BIND may be exploited causing a temporary denial of service until the bad record expires from the cache.
Alerts:
SCO Group CSSA-2004-003.0 2004-02-19
Debian DSA-409-1 2004-01-05
SuSE SuSE-SA:2003:047 2003-11-28
Trustix 2003-0044 2003-11-27
Immunix IMNX-2003-7+-024-01 2003-10-27
EnGarde ESA-20031126-031 2003-11-26

Comments (none posted)

CUPS: denial of service

Package(s):CUPS CVE #(s):CAN-2003-0788
Created:November 3, 2003 Updated:March 4, 2004
Description: Paul Mitcheson reported a situation where the CUPS Internet Printing Protocol (IPP) implementation in CUPS versions prior to 1.1.19 would get into a busy loop. This could result in a denial of service. In order to exploit this bug an attacker would need to have the ability to make a TCP connection to the IPP port (by default 631).
Alerts:
SCO Group CSSA-2004-012.0 2004-03-03
Conectiva CLA-2003:779 2003-11-07
Mandrake MDKSA-2003:104 2003-11-05
Red Hat RHSA-2003:275-01 2003-11-03

Comments (none posted)

cvs: possible root compromise

Package(s):cvs CVE #(s):CAN-2003-0977
Created:December 29, 2003 Updated:February 13, 2004
Description: Stable CVS 1.11.11 has been released, adding code to the CVS server to prevent it from continuing as root after a user login, as an extra failsafe against a compromise of the CVSROOT/passwd file.
Alerts:
Whitebox WBSA-2004:004-01 2004-02-12
Fedora-Legacy FLSA:1207 2004-01-28
Conectiva CLA-2004:808 2004-01-20
Debian DSA-422-1 2004-01-13
Red Hat RHSA-2004:003-01 2004-01-09
Gentoo 200312-08 2003-12-28

Comments (none posted)

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 18, 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

Comments (none posted)

Filename disclosure vulnerability in fam

Package(s):fam CVE #(s):CAN-2002-0875
Created:August 19, 2002 Updated:January 5, 2005
Description: "fam" (file alteration monitor) watches files and directories for changes and lets interested applications know when something happens. This package has a flaw in its group handling that blocks some legitimate operations while, at the same time, exposing the names of files that should otherwise be invisible.
Alerts:
Red Hat RHSA-2005:005-01 2005-01-05
Debian DSA-154-1 2002-08-15

Comments (none posted)

fetchmail may crash on specially crafted message

Package(s):fetchmail CVE #(s):CAN-2003-0792
Created:October 16, 2003 Updated:April 8, 2004
Description: A bug was discovered in fetchmail 6.2.4 where a specially crafted email message can cause fetchmail to crash.
Alerts:
OpenPKG OpenPKG-SA-2004.012 2004-04-08
Gentoo 200403-10 2004-03-30
Netwosix NW-2004-0002 2004-02-20
SCO Group CSSA-2004-004.0 2004-02-19
Slackware SSA:2003-300-02 2003-10-22
Mandrake MDKSA-2003:101 2003-10-16

Comments (none posted)

fileutils/wu-ftpd: denial of service

Package(s):fileutils CVE #(s):CAN-2003-0854
Created:October 22, 2003 Updated:March 2, 2004
Description: There is, it seems, an integer overflow vulnerability in "ls" which can be exploited via wu-ftpd to create a denial of service situation. See this advisory from Georgi Guninski for details.
Alerts:
SCO Group CSSA-2004-006.0 2004-03-01
Trustix 2003-0042 2003-11-15
Mandrake MDKSA-2003:106 2003-11-12
Red Hat RHSA-2003:309-01 2003-11-03
Immunix IMNX-2003-7+-026-01 2003-10-31
Conectiva CLA-2003:771 2003-10-24
Conectiva CLA-2003:768 2003-10-22

Comments (none posted)

gaim: remote overflows

Package(s):gaim CVE #(s):CAN-2004-0006 CAN-2004-0007 CAN-2004-0008
Created:January 26, 2004 Updated:February 16, 2004
Description: Stefan Esser has discovered several vulnerabilities in Gaim 0.75. This advisory has details of 12 separate vulnerabilities.
Alerts:
Fedora FEDORA-2004-070 2004-02-16
Whitebox WBSA-2004:033-01 2004-02-12
Conectiva CLA-2004:813 2004-02-10
Red Hat RHSA-2004:045-01 2004-02-09
Debian DSA-434-1 2004-02-05
Mandrake MDKSA-2004:006-1 2004-01-30
SuSE SuSE-SA:2004:004 2004-01-29
Gentoo 200401-04 2004-01-27
Mandrake MDKSA-2004:006 2004-01-26
Slackware SSA:2004-026-01 2004-01-26
Red Hat RHSA-2004:033-01 2004-01-23
Red Hat RHSA-2004:032-01 2004-01-23

Comments (none posted)

glibc: DNS stub resolvers contain buffer overflow vulnerability

Package(s):glibc CVE #(s):CAN-2002-1146
Created:November 7, 2002 Updated:February 5, 2004
Description: DNS stub resolvers from multiple vendors contain a buffer overflow vulnerability. The impact of this vulnerability appears to be limited to denial of service. (See CERT Vulnerability Note VU#738331)

The BIND 4 and BIND 8.2.x stub resolver libraries, and other libraries such as glibc 2.2.5 and earlier, libc, and libresolv, uses the maximum buffer size instead of the actual size when processing a DNS response, which causes the stub resolvers to read past the actual boundary ("read buffer overflow"), allowing remote attackers to cause a denial of service (crash).

Alerts:
Mandrake MDKSA-2004:009 2004-02-04
Red Hat RHSA-2002:197-09 2002-11-06
Red Hat RHSA-2002:197-06 2002-10-03

Comments (none posted)

GnuPG: ElGamal signing keys compromised

Package(s):gnupg CVE #(s):CAN-2003-0971
Created:November 28, 2003 Updated:March 3, 2004
Description: A severe vulnerability was discovered in GnuPG by Phong Nguyen relating to ElGamal sign+encrypt keys. This email message from Werner Koch contains more information. "Phong Nguyen identified a severe bug in the way GnuPG creates and uses ElGamal keys for signing. This is a significant security failure which can lead to a compromise of almost all ElGamal keys used for signing. Note that this is a real world vulnerability which will reveal your private key within a few seconds."
Alerts:
SCO Group CSSA-2004-009.0 2004-03-02
Debian DSA-429-2 2004-02-13
Debian DSA-429-1 2004-01-26
Gentoo 200312-05 2003-12-12
Fedora FEDORA-2003-025 2003-12-10
Red Hat RHSA-2003:395-01 2003-12-10
Red Hat RHSA-2003:390-01 2003-12-10
Conectiva CLA-2003:798 2003-12-09
SuSE SuSE-SA:2003:048 2003-12-03
Mandrake MDKSA-2003:109 2003-11-28

Comments (3 posted)

gtkhtml: malformed messages cause crash

Package(s):gtkhtml CVE #(s):CAN-2003-0133 CAN-2003-0541
Created:April 14, 2003 Updated:April 18, 2005
Description: GtkHTML is the HTML rendering widget used by the Evolution mail reader.

GtkHTML supplied with versions of Evolution prior to 1.2.4 contain a bug when handling HTML messages. Alan Cox discovered that certain malformed messages could cause the Evolution mail component to crash.

Alerts:
Debian DSA-710-1 2005-04-18
Mandrake MDKSA-2003:093 2003-09-18
Conectiva CLA-2003:737 2003-09-12
Red Hat RHSA-2003:264-01 2003-09-09
Mandrake MDKSA-2003:046 2003-04-15
Red Hat RHSA-2003:126-01 2003-04-14

Comments (none posted)

iproute: local denial of service

Package(s):iproute net-tools CVE #(s):CAN-2003-0856
Created:November 25, 2003 Updated:December 14, 2004
Description: The iproute utility is susceptible to spoofed netlink messages sent by local users, with the result that denial of service attacks are possible.
Alerts:
Mandrake MDKSA-2004:148 2004-12-13
Fedora FEDORA-2004-154 2004-06-03
Fedora FEDORA-2004-115 2004-05-11
Debian DSA-492-1 2004-04-18
Gentoo 200404-10 2004-04-09
Red Hat RHSA-2003:316-01 2003-11-24

Comments (none posted)

kdepim: VCF file information reader vulnerability

Package(s):kdepim CVE #(s):CAN-2003-0988
Created:January 15, 2004 Updated:May 26, 2004
Description: KDE has issued a security advisory for all versions of kdepim as distributed with KDE versions 3.1.0 through 3.1.4 inclusive. A carefully crafted .VCF file potentially enables local attackers to compromise the privacy of a victim's data or execute arbitrary commands with the victim's privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0988 to this issue.
Alerts:
Fedora FEDORA-2004-133 2004-05-19
Gentoo 200404-02 2004-04-06
Whitebox WBSA-2004:005-01 2004-02-12
Conectiva CLA-2004:810 2004-01-20
Slackware SSA:2004-014-01 2004-01-14
Mandrake MDKSA-2004:003 2004-01-14
Red Hat RHSA-2004:006-01 2004-01-07

Comments (none posted)

kernel: privilege vulnerability on AMD64

Package(s):kernel CVE #(s):CAN-2004-0001
Created:January 16, 2004 Updated:February 17, 2004
Description: On AMD64 systems, a fix was made to the eflags checking in 32-bit ptrace emulation that could have allowed local users to elevate their privileges. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0001 to this issue.
Alerts:
Gentoo 200402-06 2004-02-17
Red Hat RHSA-2004:017-01 2004-01-13

Comments (none posted)

kernel: local root exploit in 2.4.22

Package(s):kernel CVE #(s):CAN-2003-0961
Created:December 1, 2003 Updated:April 5, 2004
Description: A vulnerability was discovered in the Linux kernel versions 2.4.22 and previous. A flaw in bounds checking in the do_brk() function can allow a local attacker to gain root privileges. This vulnerability is known to be exploitable.

The 2.4.23 kernel contains the fix. For more details on how this vulnerability works, see this LWN article.

Alerts:
Debian DSA-475-1 2004-04-05
Debian DSA-470-1 2004-04-01
Debian DSA-442-1 2004-02-19
Debian DSA-433-1 2004-02-04
Debian DSA-423-1 2004-01-15
Red Hat RHSA-2003:368-01 2003-12-19
Conectiva CLA-2003:796 2003-12-05
Gentoo 200312-02 2003-12-04
SuSE SuSE-SA:2003:049 2003-12-04
Yellow Dog YDU-20031203-1 2003-12-03
Red Hat RHSA-2003:389-01 2003-12-01
Fedora FEDORA-2003-026 2003-12-02
Slackware SSA:2003-336-01 2003-12-01
Red Hat RHSA-2003:392-00 2003-12-01
Trustix 2003-0046 2003-12-01
Mandrake MDKSA-2003:110 2003-12-01
Debian DSA-403-1 2003-12-01

Comments (1 posted)

kernel-utils: setuid vulnerability

Package(s):kernel-utils CVE #(s):CAN-2003-0019
Created:February 7, 2003 Updated:January 21, 2005
Description: The kernel-utils package contains several utilities that can be used to control the kernel or machine hardware. In Red Hat Linux 8.0 this package contains user mode linux (UML) utilities.

The uml_net utility in kernel-utils packages with Red Hat Linux 8.0 was incorrectly shipped setuid root. This could allow local users to control certain network interfaces, add and remove arp entries and routes, and put interfaces in and out of promiscuous mode.

All users of the kernel-utils package should update to these packages that contain a version of uml_net that is not setuid root.

Alternatively, as a work-around to this vulnerability issue the following command as root:

chmod -s /usr/bin/uml_net

Alerts:
Red Hat RHSA-2003:056-08 2003-02-07

Comments (none posted)

lftp buffer overflows

Package(s):lftp CVE #(s):CAN-2003-0963
Created:December 15, 2003 Updated:February 13, 2004
Description: According to this advisory versions of lftp prior to 2.6.10 are vulnerable to two exploitable buffer overflow problems. Both occur when you connect to a web server with lftp using HTTP or HTTPS, and then use lftp's "ls" or "rels" commands on specially prepared directories on the web server.
Alerts:
Whitebox WBSA-2003:404-01 2003-12-17
Conectiva CLA-2004:800 2004-01-06
Debian DSA-406-1 2004-01-05
Gentoo 200312-07 2003-12-16
OpenPKG OpenPKG-SA-2003.053 2003-12-17
Red Hat RHSA-2003:404-01 2003-12-16
Red Hat RHSA-2003:403-01 2003-12-16
Mandrake MDKSA-2003:116 2003-12-15
Fedora FEDORA-2003-034 2003-12-15
SuSE SuSE-SA:2003:051 2003-12-15
Immunix IMNX-2003-73-002-01 2003-12-09
Slackware SSA:2003-346-01 2003-12-12

Comments (none posted)

libpng, libpng3: buffer overflow

Package(s):libpng, libpng3 CVE #(s):CAN-2002-1363
Created:December 19, 2002 Updated:July 14, 2004
Description: Glenn Randers-Pehrson discovered a problem in connection with 16-bit samples from libpng, an interface for reading and writing PNG (Portable Network Graphics) format files. The starting offsets for the loops are calculated incorrectly which causes a buffer overrun beyond the beginning of the row buffer.
Alerts:
Gentoo 200407-06 2004-07-08
OpenPKG OpenPKG-SA-2004.030 2004-07-06
Mandrake MDKSA-2004:063 2004-06-29
Whitebox WBSA-2004:249-01 2004-06-21
Fedora FEDORA-2004-176 2004-06-18
Fedora FEDORA-2004-174 2004-06-18
Fedora FEDORA-2004-175 2004-06-18
Fedora FEDORA-2004-173 2004-06-18
Red Hat RHSA-2004:249-01 2004-06-18
Conectiva CLA-2003:564 2003-01-23
Mandrake MDKSA-2003:008 2003-01-20
OpenPKG OpenPKG-SA-2003.001 2003-01-15
Yellow Dog YDU-20030114-2 2002-01-14
SuSE SuSE-SA:2003:0004 2003-01-14
Red Hat RHSA-2003:006-06 2003-01-09
Debian DSA-213-1 2002-12-19

Comments (none posted)

mc: arbitrary code execution

Package(s):mc CVE #(s):CAN-2003-1023
Created:January 16, 2004 Updated:April 5, 2004
Description: A vulnerability was discovered in Midnight Commander, a file manager, whereby a malicious archive (such as a .tar file) could cause arbitrary code to be executed if opened by Midnight Commander.
Alerts:
OpenPKG OpenPKG-SA-2004.009 2004-04-05
Gentoo 200403-09 2004-03-29
Conectiva CLA-2004:833 2004-03-31
SCO Group CSSA-2004-014.0 2004-03-25
Whitebox WBSA-2004:035-01 2004-02-12
Fedora FEDORA-2004-058 2004-02-09
Red Hat RHSA-2004:035-01 2004-01-19
Mandrake MDKSA-2004:007 2004-01-26
Red Hat RHSA-2004:034-01 2004-01-19
Debian DSA-424-1 2004-01-16

Comments (none posted)

mikmod: buffer overflow

Package(s):mikmod CVE #(s):CAN-2003-0427
Created:June 16, 2003 Updated:June 16, 2005
Description: Ingo Saitz discovered a bug in mikmod whereby a long filename inside an archive file can overflow a buffer when the archive is being read by mikmod.
Alerts:
Fedora FEDORA-2005-405 2005-06-16
Red Hat RHSA-2005:506-01 2005-06-13
Fedora FEDORA-2005-404 2005-06-09
Gentoo 200307-01 2003-07-02
Debian DSA-320-1 2003-06-13

Comments (none posted)

mod_python: denial of service vulnerability

Package(s):mod_python CVE #(s):CAN-2003-0973
Created:January 27, 2004 Updated:October 4, 2004
Description: Apache's mod_python module could crash the httpd process if a specific, malformed query string was sent.

The Apache Foundation has reported that mod_python may be prone to Denial of Service attacks when handling a malformed query. Mod_python 2.7.9 was released to fix the vulnerability, however, because the vulnerability has not been fully fixed, version 2.7.10 has been released.

Users of mod_python 3.0.4 are not affected by this vulnerability.

Alerts:
Fedora-Legacy FLSA:1325 2004-10-03
Conectiva CLA-2004:837 2004-04-12
Whitebox WBSA-2004:058-01 2004-03-01
Debian DSA-452-1 2004-02-29
Red Hat RHSA-2004:058-01 2004-02-26
Red Hat RHSA-2004:063-01 2004-02-26
Gentoo 200401-03 2004-01-27

Comments (none posted)

mpg123: heap overflow

Package(s):mpg123 CVE #(s):CAN-2003-0865
Created:November 12, 2003 Updated:February 19, 2004
Description: Versions of mpg123 through 0.59s contain a heap overflow which may be exploited remotely (by a hostile server). See this advisory for details.
Alerts:
SCO Group CSSA-2004-002.0 2004-02-19
Debian DSA-435-1 2004-02-06
Conectiva CLA-2003:781 2003-11-12

Comments (none posted)

mpg321: format string vulnerability

Package(s):mpg321 CVE #(s):CAN-2003-0969
Created:January 6, 2004 Updated:March 28, 2005
Description: A vulnerability was discovered in mpg321, a command-line mp3 player, whereby user-supplied strings were passed to printf(3) unsafely. This vulnerability could be exploited by a remote attacker to overwrite memory, and possibly execute arbitrary code. In order for this vulnerability to be exploited, mpg321 would need to play a malicious mp3 file (including via HTTP streaming).
Alerts:
Gentoo 200503-34 2005-03-28
Debian DSA-411-1 2004-01-05

Comments (none posted)

mplayer: remotely exploitable buffer overflow vulnerability

Package(s):mplayer CVE #(s):CAN-2003-0835
Created:September 29, 2003 Updated:April 6, 2004
Description: A remotely exploitable buffer overflow vulnerability was found in MPlayer. A malicious host can craft a harmful ASX header, and trick MPlayer into executing arbitrary code upon parsing that header. Read the full advisory for details.
Alerts:
Mandrake MDKSA-2004:026 2004-04-05
Gentoo 200403-13 2004-03-31
Conectiva CLA-2003:760 2003-10-06
Mandrake MDKSA-2003:097 2003-09-30
Gentoo 200309-15 2003-09-27

Comments (none posted)

Nessus NASL scripting engine security issues

Package(s):nessus CVE #(s):
Created:May 27, 2003 Updated:August 12, 2004
Description: Some some vulnerabilities exsist in the Nessus NASL scripting engine. To exploit these flaws, an attacker would need to have a valid Nessus account as well as the ability to upload arbitrary Nessus plugins in the Nessus server (this option is disabled by default) or he/she would need to trick a user somehow into running a specially crafted nasl script. Read the full advisory for additional information.
Alerts:
Gentoo 200305-10 2003-05-27

Comments (none posted)

netpbm: insecure temporary files

Package(s):netpbm CVE #(s):CAN-2003-0924
Created:January 19, 2004 Updated:December 29, 2004
Description: netpbm is graphics conversion toolkit made up of a large number of single-purpose programs. Many of these programs were found to create temporary files in an insecure manner, which could allow a local attacker to overwrite files with the privileges of the user invoking a vulnerable netpbm tool.
Alerts:
Conectiva CLA-2004:909 2004-12-29
Gentoo 200410-02 2004-10-04
Mandrake MDKSA-2004:011-1 2004-09-27
Whitebox WBSA-2004:031-01 2004-02-12
Mandrake MDKSA-2004:011 2004-02-11
Red Hat RHSA-2004:030-01 2004-02-05
Fedora FEDORA-2004-068 2004-02-06
Red Hat RHSA-2004:031-01 2004-01-22
Debian DSA-426-1 2004-01-18

Comments (1 posted)

Net-SNMP: security bugs in versions before 5.0.9

Package(s):Net-SNMP CVE #(s):CAN-2003-0935
Created:December 2, 2003 Updated:February 13, 2004
Description: The Net-SNMP project includes various Simple Network Management Protocol (SNMP) tools. A security issue in Net-SNMP versions before 5.0.9 could allow an existing user/community to gain access to data in MIB objects that were explicitly excluded from their view.

Version 5.0.9 of Net-SNMP is not vulnerable to this issue. In addition, Net-SNMP 5.0.9 fixes a number of other minor bugs.

Alerts:
Whitebox WBSA-2004:023-01 2004-02-12
Red Hat RHSA-2004:023-01 2004-01-15
Mandrake MDKSA-2003:115 2003-12-11
Red Hat RHSA-2003:335-01 2003-12-02

Comments (none posted)

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

Package(s):nfs-utils CVE #(s):CAN-2003-0252
Created:July 14, 2003 Updated:March 8, 2004
Description: Linux NFS utils package contains remotely exploitable off-by-one bug. A local or remote attacker could exploit this vulnerability by sending specially crafted request to rpc.mountd daemon. See this BugTraq post for more details.
Alerts:
Trustix TSLSA-2004-0009 2004-03-05
SCO Group CSSA-2003-037.0 2003-11-17
Conectiva CLA-2003:700 2003-07-22
Mandrake MDKSA-2003:076 2003-07-21
Gentoo 200307-07 2003-07-19
Yellow Dog YDU-20030718-1 2003-07-18
Slackware SSA:2003-195-01b 2003-07-15
Immunix IMNX-2003-7+-018-01 2003-07-14
SuSE SuSE-SA:2003:031 2003-07-15
Slackware SSA:2003-195-01 2003-07-14
Debian DSA-349-1 2003-07-14
Red Hat RHSA-2003:206-01 2003-07-14

Comments (none posted)

openssh: timing attack leads to information disclosure

Package(s):openssh CVE #(s):CAN-2003-0190
Created:May 2, 2003 Updated:November 30, 2004
Description: From the advisory: "During a pen-test we stumbled across a nasty bug in OpenSSH-portable with PAM support enabled (via the --with-pam configure script switch). This bug allows a remote attacker to identify valid users on vulnerable systems, through a simple timing attack. The vulnerability is easy to exploit and may have high severity, if combined with poor password policies and other security problems that allow local privilege escalation."
Alerts:
Ubuntu USN-34-1 2004-11-30
OpenPKG OpenPKG-SA-2003.035 2003-08-06
Red Hat RHSA-2003:222-01 2003-07-29
Gentoo 200305-02 2003-05-13
Gentoo 200305-01 2002-03-05

Comments (1 posted)

postfix: denial of service vulnerabilities

Package(s):postfix CVE #(s):CAN-2003-0468 CAN-2003-0540
Created:August 5, 2003 Updated:May 27, 2004
Description: The postfix MTA, versions through 1.1.12 (but not 2.0) is subject to two remotely exploitable denial of service vulnerabilities; see this advisory from Michal Zalewski for details.
Alerts:
Mandrake MDKA-2004:028 2004-05-26
Trustix 2003-0029 2003-08-04
Mandrake MDKSA-2003:081 2003-08-04
EnGarde ESA-20030804-019 2003-08-04
Conectiva CLA-2003:717 2003-08-04
SuSE SuSE-SA:2003:033 2003-08-04
Red Hat RHSA-2003:251-01 2003-08-04
Debian DSA-363-1 2003-08-03

Comments (none posted)

rsync - remotely exploitable heap overflow

Package(s):rsync CVE #(s):CAN-2003-0962
Created:December 4, 2003 Updated:March 3, 2004
Description: An advisory has gone out warning of a remotely exploitable heap overflow vulnerability in rsync versions 2.5.6 and prior. If you are running an rsync server, you will want to apply a distributor patch or upgrade to 2.5.7 in the near future.
Alerts:
SCO Group CSSA-2004-010.0 2004-03-02
Immunix IMNX-2003-73-001-01 2003-12-05
Mandrake MDKSA-2003:111 2003-12-04
Red Hat RHSA-2003:399-01 2003-12-04
Red Hat RHSA-2003:398-01 2003-12-04
Fedora FEDORA-2003-030 2003-12-04
Conectiva CLA-2003:794 2003-12-04
Gentoo 200312-03 2003-12-04
EnGarde ESA-20031204-032 2003-12-04
Debian DSA-404-1 2003-12-04
OpenPKG OpenPKG-SA-2003.051 2003-12-04
SuSE SuSE-SA:2003:050 2003-12-04
Trustix 2003-0048 2003-12-04
Slackware SSA:2003-337-01 2003-12-03

Comments (none posted)

Multiple-use vulnerability in Safe.pm

Package(s):Safe.pm CVE #(s):CAN-2002-1323
Created:October 9, 2002 Updated:February 20, 2004
Description: usePerl has a description of a vulnerability in the Safe.pm Perl module. It seems that if a Safe compartment is used more than once, it ceases to be safe. The problem is fixed in Safe 2.08.
Alerts:
SCO Group CSSA-2004-007.0 2004-02-20
Gentoo 200212-6 2002-12-20
Trustix 2002-0087 2002-12-19
OpenPKG OpenPKG-SA-2002.014 2002-12-16
Debian DSA-208-1 2002-12-12

Comments (none posted)

sane-backends: several vulnerabilities

Package(s):sane-backends CVE #(s):CAN-2003-0773 CAN-2003-0774 CAN-2003-0775 CAN-2003-0776 CAN-2003-0777 CAN-2003-0778
Created:September 11, 2003 Updated:February 20, 2004
Description: Alexander Hvostov, Julien Blache and Aurelien Jarno discovered several security-related problems in the sane-backends package, which contains an API library for scanners including a scanning daemon (in the package libsane) that can be remotely exploited. These problems allow a remote attacker to cause a segfault fault and/or consume arbitrary amounts of memory. The attack is successful, even if the attacker's computer isn't listed in saned.conf.

You are only vulnerable if you actually run saned e.g. in xinetd or inetd. If the entries in the configuration file of xinetd or inetd respectively are commented out or do not exist, you are safe.

Try "telnet localhost 6566" on the server that may run saned. If you get "connection refused" saned is not running and you are safe.

The Common Vulnerabilities and Exposures project identifies the following problems:

  • CAN-2003-0773: saned checks the identity (IP address) of the remote host only after the first communication took place (SANE_NET_INIT). So everyone can send that RPC, even if the remote host is not allowed to scan (not listed in saned.conf).
  • CAN-2003-0774: saned lacks error checking nearly everywhere in the code. So connection drops are detected very late. If the drop of the connection isn't detected, the access to the internal wire buffer leaves the limits of the allocated memory. So random memory "after" the wire buffer is read which will be followed by a segmentation fault.
  • CAN-2003-0775: If saned expects strings, it mallocs the memory necessary to store the complete string after it receives the size of the string. If the connection was dropped before transmitting the size, malloc will reserve an arbitrary size of memory. Depending on that size and the amount of memory available either malloc fails (->saned quits nicely) or a huge amount of memory is allocated. Swapping and OOM measures may occur depending on the kernel.
  • CAN-2003-0776: saned doesn't check the validity of the RPC numbers it gets before getting the parameters.
  • CAN-2003-0777: If debug messages are enabled and a connection is dropped, non-null-terminated strings may be printed and segmentation faults may occur.
  • CAN-2003-0778: It's possible to allocate an arbitrary amount of memory on the server running saned even if the connection isn't dropped. At the moment this can not easily be fixed according to the author. Better limit the total amount of memory saned may use (ulimit).
Alerts:
SCO Group CSSA-2004-005.0 2004-02-19
SuSE SuSE-SA:2003:046 2003-11-18
Conectiva CLA-2003:769 2003-10-22
Mandrake MDKSA-2003:099 2003-10-09
Red Hat RHSA-2003:278-01 2003-10-07
Debian DSA-379-1 2003-09-11

Comments (none posted)

screen: privilege escalation

Package(s):screen CVE #(s):CAN-2003-0972
Created:November 28, 2003 Updated:March 3, 2004
Description: According to this advisory a buffer overflow in GNU screen allows privilege escalation for local users. Usually screen is installed either setgid-utmp or setuid-root.

It also has some potential for remote attacks or getting control of another user's screen. The problem is that you have to transfer around 2-3 gigabytes of data to user's screen to exploit this vulnerability. 4.0.1, 3.9.15 and older versions are vulnerable.

Alerts:
SCO Group CSSA-2004-011.0 2004-03-02
Fedora-Legacy FLSA:1187 2004-01-26
Conectiva CLA-2004:809 2004-01-20
Debian DSA-408-1 2004-01-05
Mandrake MDKSA-2003:113 2003-12-08
OpenPKG OpenPKG-SA-2003.050 2003-11-28

Comments (none posted)

slocate: buffer overflow

Package(s):slocate CVE #(s):CAN-2003-0848
Created:January 20, 2004 Updated:February 16, 2004
Description: A vulnerability was discovered in slocate, a program to index and search for files, whereby a specially crafted database could overflow a heap-based buffer. This vulnerability could be exploited by a local attacker to gain the privileges of the "slocate" group, which can access the global database containing a list of pathnames of all files on the system, including those which should only be visible to privileged users. This problem, and a category of potential similar problems, can be fixed by modifying slocate to drop privileges before reading a user-supplied database.
Alerts:
Fedora-Legacy FLSA:1232 2004-02-11
Whitebox WBSA-2004:041-01 2004-02-12
SCO Group CSSA-2004-001.0 2004-02-10
Fedora FEDORA-2004-059 2004-01-26
Red Hat RHSA-2004:041-01 2004-01-22
Mandrake MDKSA-2004:004 2004-01-23
Trustix 2004-0005 2004-01-21
Debian DSA-428-1 2004-01-20

Comments (none posted)

File overwrite vulnerability in tar and unzip

Package(s):tar unzip CVE #(s):CAN-2001-1267 CAN-2001-1268 CAN-2001-1269 CAN-2002-0399
Created:October 1, 2002 Updated:April 9, 2006
Description: The tar utility does not properly filter file names containing "../", meaning that a hostile archive can, if unpacked by an unsuspecting user, overwrite any file that is writable by that user. GNU tar versions 1.13.19 and earlier are vulnerable; unzip through version 5.42 has the same vulnerability.
Alerts:
Fedora-Legacy FLSA:183571-1 2006-04-04
Red Hat RHSA-2006:0195-01 2006-02-21
Conectiva