LWN.net Logo

LWN.net Weekly Edition for May 27, 2004

Documenting kernel code provenance

Linus's request for discussion made his motivation clear:

Some of you may have heard of this crazy company called SCO (aka "Smoking Crack Organization") who seem to have a hard time believing that open source works better than their five engineers do. They've apparently made a couple of outlandish claims about where our source code comes from, including claiming to own code that was clearly written by me over a decade ago.

He notes that the process of debunking these claims, while highly effective, has not been entirely fun. As a way of making life easier when the next SCO comes along, Linus is proposing a lightweight mechanism which would document how each patch finds its way into the kernel. In essence, this scheme would require each patch to contain at least one line like:

    Signed-off-by: Some kernel hacker <skh@some.host>

One such line would be added by each person who handles the patch on its way to the mainline kernel. Together, these lines would document the originator of the patch and the path it took before it was merged. Each developer, by "signing off" on the patch in this way, would indicate that he or she has the right to submit it to the kernel under a free license - either by virtue of having written the code, or by having obtained it from a source which allows this form of redistribution. Companies which require review of code contributed to external projects can designate a person who must sign off on patches before they go out.

This procedure is a far cry from, for example, the full-blown copyright assignment required from contributors to GNU projects. Contributions to the kernel will still require no physical, signed papers, no assignment of copyright, no indemnification, and no documented permission from the contributor's employer. The Free Software Foundation, with its assignment policy, is trying to set itself up as the owner and custodian of the GNU system, with clear title to the code, the ability to specify the license under which that code will be released and to enforce the terms of that license. The kernel hackers, instead, seem to feel that they can get by without such a custodian, wish to retain ownership of their code, and, as the netfilter team has demonstrated, they feel entirely capable of enforcing their own licenses.

The kernel system is, instead, aimed entirely at documentation. The next time somebody questions the legitimacy of code in the kernel, it would be nice to be able to point out, quickly, exactly where the code came from. In this way, perhaps, people can spend less time digging through ancient mail archives and more time developing. For this reason, suggestions varying from GPG-signing of patches to the (poorly received) idea of adopting an ISO-9000 process will probably not be implemented. Some tweaking will probably happen, but whatever system finally gets adopted will remain a simple, lightweight documentation mechanism.

While the new kernel contribution scheme is aimed at documenting future contributions, the just-launched Grokline project is trying to document the past. From the site:

This is an open, community-based, collaborative research project, a living history, designed to carefully trace the ownership history of UNIX and UNIX-like code with the goal of reducing, or eliminating, the amount of software subject to superficially plausible but ultimately invalid copyright, patent and trade secret claims against Linux or other free and open source software.

The project has put together a basic Unix timeline, and is soliciting input from anybody who can help document where all this code came from.

Grokline will, without doubt, yield no end of interesting historical information. One can't help wondering, however, if the community isn't gearing up to fight last year's war. The SCO Group has done us a tremendous favor by showing that (1) finding copyright infringements in free software (and the Linux kernel in particular) really is hard, and (2) the community will unite with devastating effect against anybody who seeks to profit from baseless attacks on free software. It is hard to imagine another company wanting to be the next SCO. The next time a copyright claim is raised against free software, the claimants will be well advised to have their evidence in place from the beginning - and to be right.

If there is another SCO-scale war in our near future, it will probably not involve copyrights. It will be, instead, a patent fight. Unless it serves to establish prior art, documentation of the provenance of code will not be helpful in a patent case. It is also worth noting that the SCO case has forced a remarkable alignment of interests between many large, deep-pocketed companies and the broader free software community. That alignment of interests may well be absent in a patent battle. Next year's patent war may not be fought off as easily as this year's copyright and (formerly) trade secret suit. By all means, we should be documenting where our code comes from, and, in general, doing our best to ensure that it has been contributed legitimately. But it would be a mistake to believe that this documentation alone will be sufficient to defend us from all "intellectual property" charges.

Comments (10 posted)

Fedora: looking forward

May 21, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

With the final release of Fedora Core 2 out the door, and on schedule no less, now might be a good time to take stock of the project and where it's going. Unfortunately, that's not as clear as one might hope.

It's easy to see where the project is now, but the future is a bit more murky -- at least for those outside the project. For the most part, the Fedora Project seems to be meeting its goals. A quick glance at the objectives for Fedora Core shows that the project is meeting nearly all of its objectives. Fedora Core 2 contains a wide range of open source packages on the "leading edge" of development. The project has done well at sticking to release schedules, and at putting together a fine Linux distribution that more or less picks up where Red Hat Linux left off.

What Fedora has not yet achieved, however, is a significant level of community involvement beyond simple testing of releases. The situation has not been helped by the project's recent change in leadership; Cristian Gafton assumed the position of Technical Lead in January, but some have complained about a lack of communication from Gafton about the project. A quick search of the Fedora devel archives gives some credence to this complaint: Gafton has only posted twelve messages to the Fedora devel lists since he assumed the Technical Lead position -- six in January, and six in May.

We contacted Gafton to see if we could get a glimpse at the roadmap and find out whether the community will have an opportunity to become more involved in the development of Fedora Core 3 (FC3) and future releases. Here's what we learned.

LWN: How long will FC1 remain "supported" now that FC2 is being released?

Our current plans are calling for issuing security updates for FC1 for two-three months after Fedora Core 2 has been released. Realistically, once the Fedora Core 3 test1 is out (or shortly after) I would expect the development interest in the Fedora Core 1 to diminish and we will take a formal look at declaring the End of Life for Fedora Core 1.

LWN: It looks like the project managed to stick to the schedule set for FC2 pretty well. In retrospect, was the schedule too aggressive or just right? Will the schedule for FC3 be as aggressive as this one? Any breathing room between FC2 and starting FC3?

We're all very happy with the fact that we have not run into any major issues in our quest to incorporate the features we have planned for the Fedora Core 2. Of course, the desire for more development time will always be there, but I think that we have managed to put together a very good schedule and we have managed to stick successfully to it. This is one of those times where we come to appreciate the Red Hat developers' experience and leadership in planning and managing an OS release, as well as the resourcefullness demonstrated by Fedora development community.

LWN: Speaking of FC3, what can we expect to see in the next release? Do you have a clear picture of what the next release will include?

We will start having a public debate about what we will plan for FC3 pretty shortly. As far as I am concerned, I will pay attention to the deployment, testing and migration to the new GCC 3.4 SSE compiler base, further refining of the SELinux techonlogy, and - of course - the new versions of Gnome, Evolution, KDE that are planned for release in the next few months. As of right now we have encouraged every developer to build up the wish list for the next round, and through a public debate process we will get a clearer picture of a feature list in the next couple of weeks.

Planning the release will require us to figure out what will be reasonable to expect to include and what would be our stretch goals. We will start this process in very short order, because we want to get a tentative schedule out as soon as possible, so that developers around the world will know what to expect. For the Fedora Core 2 release I have been happy to notice that some projects have attempted to syncronize their release schedules so that we will have an easier time integrating their new code bases in the Fedora Core. It is my sincere hope that this trend will continue, and we are aware of the fact that we have to give people plenty of time to plan ahead.

LWN: According to the FC2 schedule, the SELinux functionality was considered "stop-ship" -- but it was disabled by default in the last test release. Is SELinux ready for mass consumption in the final FC2 release, or does it still require some polish before it's ready for prime time?

I think the SELinux functionality is pretty well cooked and I encourage the seasoned users and developers to play with it. Unfortunately at this stage, the implementation and management of the SELinux security policies are complex tasks that require an advanced degree of familiarity with the inner workings of the operating system.

The challenge we face in developing a default security policy is the balance one needs to strike between the level of security barriers deployed and the functionality people would reasonably expect out of this release. For example, can we subject third party applications, that are not aware of the security contexts, to a paranoid policy that most likely will prevent them from functioning correctly, or do we provide a more relaxed policy at which point the security advantages of SELinux are not so readily apparent? Also, the legacy of the discretionary access control setups will be a tough nut to crack - we found out that a lot of users still expected that the root account will be able to do and fix everything - an assumption no longer valid when running under SELinux.

So, for the Fedora Core 2 we have decided to court the experienced users and developers to help us figure out the lines of compromise between the challenges posed by the SELinux policy - a sort of a continued beta program for refining what would be an acceptable set of defaults. Of course, this does not preclude the development of very strict or more relaxed policies as alternatives to the balanced default set.

LWN: No doubt you've seen the parody published by Konstantin Ryabitsev about Fedora/Red Hat's interaction with the community. Though it's a bit over the top, it has raised quite a bit of discussion. Is it likely that RH will seek more involvement from the community in terms of setting the direction of Fedora? Will there be any changes in the way Fedora is managed in the near future?

This is and continues to be one of the challenges Red Hat faces - how do we build an effective way of engaging more of the external development community and how do we enable them to participate in this project. The parody you are referring to, while an entertaining read, assumes a political conflict out of the current state, when in fact the challenges we are facing are logistical. We are talking about deploying a parallel development process for the Red Hat developers, geared and built to support external parties contributing code on various sections of the operating system. This means planning and executing a huge change in everything infrastructure-related inside Red Hat engineering, which has the potential of causing big impacts in the other corners of our business, like support, professional services and even sales. We are working hard on opening up our infrastructure, but we have to do it responsibly and we have to be mindful of the business impact we are going to cause on the commitments Red Hat needs to fullfill as a publicly traded company. Oftentimes we internally compare this process to working on a jet engine while it is running...

Our short-term plans include the opening of a source code management repository where the interested developers can follow closely the development activity of the Red Hat engineering team. We will also be revamping the fedora.redhat.com website, adding dynamic content to it and allowing people to start participating in forums and start oganizing according to their common interests. These are steps that are going to happen in the very few next weeks, in time for the start of the Fedora Core 3 development process.

LWN: On the same topic, a lot of discussion has been comparing Fedora to Debian -- obviously, there are some serious differences in the way that both distros are put together. Would you say that the Fedora approach is better, or just different? Why?

Well, some things are better, some things are "different." The Red Hat engineering team is more experienced at putting together high-quality, commercial distributions. The planning, scheduling and focus we bring to the process are superior, and by transforming the Fedora Project into a community-focused release we now also have the flexibility of doing more of what is right when it comes to setting up a schedule.

In the software development process there are always three factors that are at play: features, quality and development speed. In commercial software development one can always have only two of those three. I believe that the community focus of the Fedora Project allows us to seek a more reasonable balance between those three objectives. Our background in commercial releases will allow us to keep focus on the fact that we need to have timely releases and we need to manage aggressively against the schedules we set. As far as Debian goes, they have been more successful at engaging the open source development community and there is a lot we can and will learn from their experiences. There is no question that as of now Fedora and Debian are very different in the way we put things together - but I think in the near future we will start to look more and more alike as far as the level of involvement with the development community.

That may yet happen, but the Fedora project is going to have to open up significantly before it can begin to shake off its image (in some quarters, at least) as a beta test program for Red Hat's enterprise products. With luck and work, perhaps Fedora can begin to approach Debian's level of community involvement. If this can be done while retaining Fedora's rather more predictable release schedule, so much the better.

Comments (5 posted)

Movable type and "almost free" software

Movable Type is a highly popular and capable content management system oriented toward the publication of weblogs. It is written in Perl, and is necessarily distributed in source form. It has never, however, been free software. Its license did not allow distribution of modified versions, though patches could be distributed. As a whole, the license was "free enough," and Movable Type developed a large, happy user base.

That user base is rather less pleased now. With the announcement of Movable Type 3.0 came the news that, for all but the smallest, personal sites, use of the new version would require a paid license. Six Apart Ltd., the company which owns Movable Type, has since learned what happens when you upset thousands of people, each of whom has a personal printing press. Many online commenters have expended countless electrons on criticism of Six Apart and its new license.

We'll not join them. Six Apart owns its code, and sets the terms for its use. The company is behaving no worse than any other proprietary software vendor, and better than many. One might argue it should have made its new licensing plans clear before inviting beta testers to help them finish 3.0, but that's about it.

What Six Apart has done is to provide an object lesson in the perils of "almost free" software. If you do not have the right to run, modify, and redistribute a program, you will, eventually, find yourself in a situation where that program loses its value to you. If its owner fails to maintain it, nobody else can. If its owner imposes an onerous license, your only options are to take it or leave it. Source-available proprietary software can be deceptive; it feels much like free software. But every such package is another MT 3.0 waiting to happen.

Consider, for example, the case of qmail. It is, beyond doubt, a powerful and secure mail transfer agent. It is distributed in source form. But it also comes with a non-free license which forbids distribution of modified versions, and which makes the distribution of binary packages difficult. There has not been a new qmail release since June, 1998. Patches are required to get it to build on a modern Linux distribution, and others are needed to bring it up to the level of functionality needed by many sites. But, due to the redistribution restrictions, nobody can take over qmail maintenance and release a new version.

That notwithstanding, many sites (LWN included, it should be said) have chosen to run qmail. But all such users should bear in mind that qmail's license terms are, at best, vague; the software itself comes with no explicit license. If qmail's author were ever to proclaim a new license, it would be hard for users to prove that any other terms had ever been in force. Even without that sort of problem, it seems pretty clear that qmail's author has long since lost interest in working on the code; the chances of there ever being another qmail release appear small.

The Movable Type episode has shown, once again, that licenses really do matter. A free software license represents a sort of gift from a developer to users: those users will never be deprived of the right to use, modify, and distribute the covered software. Developers are not (and should not be) required to offer such a gift. But if the author of software you use has not given you those rights, you should not be surprised when the terms change in the future.

Comments (34 posted)

Page editor: Jonathan Corbet

Security

Did they read it?

May 26, 2004

This article was contributed by Joe 'Zonker' Brockmeier.

Return receipts for email have been around for quite some time. They can be useful in some settings where a user is willing to verify that they've received an email without taking the time to compose a reply. However, the return receipt depends on the user's willingness to participate in the process. Often, for one reason or another, users do not wish to do that; these users can simply configure their email client to deny requests for return-mail receipts -- if, in fact, the user's email client supports that feature at all.

There are, however, those who aren't content to depend on voluntary responses. Rampell Software is peddling a subscription service for nosy correspondents who want to know whether or not their email has been read. Rampell is a company that pushes several spyware products for MacOS and Windows that are aimed at monitoring the use of other peoples' computers. The "DidTheyReadIt" service is aimed at people who are determined to know whether or not their mail has been read, and who are willing to pay for the privilege.

This, of course, has some not-so-pleasant implications for personal privacy. While the company assures its potential customers that it respects their privacy, nothing is said about the privacy of the recipient who may not wish to divulge whether or not they've read a particular email or where they've read it from. On the company's About Us page, they identify what kinds of people might want to find out whether an email has been read -- including some that make DidTheyReadIt sound like a must-have for potential stalkers:

Users of online dating services such as match.com who want to know if their potential dates are reading their messages...or ignoring them.

It isn't particularly cheap to violate others' privacy either, at least not when using DoTheyReadIt on a regular basis. A quarterly subscription for the service, with the ability to track 500 messages per month, is $24.99.

To use the service, the user has to send email through DidTheyReadIt's servers by tacking ".didtheyreadit.com" onto the recipient's email address. DidTheyReadIt's server then tags the email with a "web bug" and sends it on its way to the intended recipient. For the uninitiated, web bugs are a well-known spammer trick to verify working email addresses. The spammer includes a bit of HTML in the email that will request an unique image name (usually a small image that is invisible to the reader) from a remote server that tracks the hits. The image name and email address are paired so that the spammer can identify working email addresses with users gullible enough to open the spammer's email. When the image is requested from didtheyreadit.com, a hit is logged and the sender can then view the information on the DidTheyReadIt website and/or be notified via email.

DidTheyReadIt takes the web bug idea further than the spammers do, however. It responds to the request for the web bug image by sending a slow stream of data back to the mail client; that stream will continue until the receiving system resets the connection. The amount of time the connection was allowed to run will be roughly equivalent to how long the message was on the reader's screen, giving a sense of how seriously the message was read.

When the service works, the amount of information provided to the sender is quite intrusive. Not content to simply verify that a user opened an email, [DidTheyReadIt report] DidTheyReadIt reports the number of times an email is read, how long the recipient spent reading it, when it was opened, the location of the reader, the IP address of the recipient at the time the message is opened and their ISP. Not only is the recipient (including anybody the message may be forwarded to) being monitored in their reading habits, they are also being physically tracked when the service is able to pair up a geographic location with an IP address. While it's not possible for the service to report a street address, it can narrow down the location to a city. It's easy to imagine scenarios where this would be particularly undesirable.

Users who are even moderately knowledgeable about the way that the Web works will have no problem blocking DidTheyReadIt from divining whether or not they have opened an email sent through this service. Rampell's claims of success "the vast majority of the time, upwards of 98% in extensive testing" are a bit suspect. In fact, many users are already protected by sane defaults in their mail clients that prohibit the display of remote graphics in HTML email by default.

This writer had to deliberately disable the defaults in the Yahoo! and SpamCop (which uses Horde) webmail clients to allow DidTheyReadIt to track test emails. The tracking did not work with Thunderbird or Opera's mail client. It goes without saying that users of mutt and Pine will easily slip under the radar.

Furthermore, once word gets around about this service, many users may simply opt to filter out email that passes through the DidTheyReadIt servers altogether. Some folks might also decide to play havoc with this service by writing scripts to call random images from DidTheyReadIt's servers to generate false positives and render the service useless. Ed Felten predicts that DidTheyReadIt will not succeed in the long run:

Products like this sow the seeds of their own destruction, by triggering the adoption of technical measures that defeat them, and the creation of social norms that make their use unacceptable.

One would hope that the use of such a service would be considered "unacceptable" by most people already. Whether or not that is true, however, the use of free software for crucial tasks like email gives users the upper hand against this sort of service. There is, after all, nothing that forces us to tolerate a mail system which supports this kind of monitoring. If only all of our email problems were so easy to solve.

Comments (7 posted)

New vulnerabilities

firebird: Locally exploitable stack overflow

Package(s):firebird CVE #(s):
Created:May 24, 2004 Updated:May 26, 2004
Description: A buffer overflow exists in three Firebird database binaries (gds_inet_server, gds_lock_mgr, and gds_drop) that is exploitable by setting a large value to the INTERBASE environment variable. An attacker could control program execution, allowing privilege escalation to the UID of Firebird, full access to Firebird databases, and trojaning the Firebird binaries. An attacker could use this to compromise other user or root accounts. See also this bug report.
Alerts:
Gentoo 200405-18 2004-05-23

Comments (none posted)

kernel: exploitable bug in the cpufreq code

Package(s):kernel CVE #(s):CAN-2004-0228
Created:May 24, 2004 Updated:May 26, 2004
Description: Brad Spender discovered an exploitable bug in the cpufreq code in the Linux 2.6 kernel.
Alerts:
Mandrake MDKSA-2004:050 2004-05-21

Comments (none posted)

SquirrelMail cross site scripting vulnerabilities

Package(s):squirrelmail CVE #(s):CAN-2004-0519 CAN-2004-0520 CAN-2004-0521
Created:May 21, 2004 Updated:October 4, 2004
Description: Several unspecified cross-site scripting (XSS) vulnerabilities and a well hidden SQL injection vulnerability were found in SquirrelMail versions 1.4.2 and lower. An XSS attack allows an attacker to insert malicious code into a web-based application. SquirrelMail does not check for code when parsing variables received via the URL query string.
Alerts:
Fedora-Legacy FLSA:1733 2004-10-02
Conectiva CLA-2004:858 2004-08-12
Whitebox WBSA-2004:240-01 2004-06-21
Gentoo 200406-08 2004-06-15
Red Hat RHSA-2004:240-01 2004-06-14
Fedora FEDORA-2004-160 2004-06-09
Fedora FEDORA-2004-159 2004-06-09
Gentoo 200405-16:02 2004-05-25
Gentoo 200405-16 2004-05-21

Comments (none posted)

xpcd: buffer overflow

Package(s):xpcd CVE #(s):CAN-2004-0402
Created:May 24, 2004 Updated:June 1, 2004
Description: Jaguar discovered a vulnerability in one component of xpcd, a PhotoCD viewer. xpcd-svga, part of xpcd which uses svgalib to display graphics on the console, would copy user-supplied data of arbitrary length into a fixed-size buffer in the pcd_open function.
Alerts:
Mandrake MDKSA-2004:053 2004-06-01
Debian DSA-508-1 2004-05-22

Comments (none posted)

Updated vulnerabilities

apache - denial of service in mod_ssl

Package(s):apache CVE #(s):CAN-2004-0113
Created:April 13, 2004 Updated:May 25, 2004
Description: A memory leak has been discovered in mod_ssl that may be triggered by sending normal HTTP requests to the Apache HTTPS port. An attacker can exploit this vulnerability to consume all memory available in the server, thus causing a denial of service condition. This problem has been fixed in Apache 2.0.49.
Alerts:
Fedora FEDORA-2004-117 2004-05-25
Mandrake MDKSA-2004:043 2004-05-10
Red Hat RHSA-2004:182-01 2004-04-30
Conectiva CLA-2004:839 2004-04-13

Comments (none posted)

apache: multiple vulnerabilities

Package(s):apache CVE #(s):CAN-2003-0993 CAN-2003-0020 CAN-2003-0987 CAN-2004-0174
Created:May 12, 2004 Updated:May 26, 2004
Description: Versions of apache 1 through 1.3.30 include several minor vulnerabilities, including the writing of unescaped data to the error log file, a denial of service vulnerability, and a parsing failure in Allow/Deny rules on big-endian, 64-bit platforms. See the apache 1.3.31 announcement for details.
Alerts:
Gentoo 200405-22 2004-05-26
Mandrake MDKSA-2004:046-1 2004-05-20
Mandrake MDKSA-2004:046 2004-05-17
Trustix TSLSA-2004-0027 2004-05-13
Slackware SSA:2004-133-01 2004-05-12
OpenPKG OpenPKG-SA-2004.021 2004-05-12

Comments (none posted)

cvs: heap overflow

Package(s):cvs CVE #(s):CAN-2004-0396
Created:May 19, 2004 Updated:June 11, 2004
Description: CVS (through version 1.11.15 or 1.12.7) contains a remotely exploitable heap overflow vulnerability; see this advisory from Stefan Esser for details. If you are running cvs with the "pserver" protocol, a quick upgrade is recommended (dropping pserver is also a very good idea for security-conscious sites).
Alerts:
Whitebox WBSA-2004:190-01 2004-06-10
Fedora-Legacy FLSA:1620 2004-06-02
Slackware SSA:2004-140-01 2004-05-19
Gentoo 200405-12 2004-05-20
OpenPKG OpenPKG-SA-2004.022 2004-05-19
Mandrake MDKSA-2004:048 2004-05-19
Fedora FEDORA-2004-131 2004-05-19
Fedora FEDORA-2004-126 2004-05-19
SuSE SuSE-SA:2004:013 2004-05-19
Red Hat RHSA-2004:190-01 2004-05-19
Debian DSA-505-1 2004-05-19

Comments (none posted)

ethereal - multiple vulnerabilities

Package(s):ethereal CVE #(s):CAN-2004-0176 CAN-2004-0365 CAN-2004-0367
Created:March 29, 2004 Updated:June 2, 2004
Description: There are multiple vulnerabilities in versions of Ethereal earlier than 0.10.3. More information can be found in this advisory from ethereal.com and in this Eye on Security advisory.
Alerts:
Debian DSA-511-1 2004-05-30
OpenPKG OpenPKG-SA-2004.015 2004-04-16
Red Hat RHSA-2004:137-01 2004-03-31
Mandrake MDKSA-2004:024 2004-03-30
Conectiva CLA-2004:835 2004-03-31
Red Hat RHSA-2004:136-01 2004-03-30
Netwosix NW-2004-0007 2004-03-29
Gentoo 200403-07 2004-03-28

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)

flim: insecure file creation

Package(s):flim CVE #(s):CAN-2004-0422
Created:May 5, 2004 Updated:December 16, 2004
Description: The emacs "flim" mode creates temporary files in an insecure fashion, possibly allowing a local attacker to overwrite files.
Alerts:
Fedora FEDORA-2004-546 2004-12-15
Red Hat RHSA-2004:344-01 2004-08-18
Debian DSA-500-1 2004-05-01

Comments (none 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)

heimdal: missing input sanitizing

Package(s):heimdal CVE #(s):CAN-2004-0472
Created:May 18, 2004 Updated:May 27, 2004
Description: Evgeny Demidov discovered a potential buffer overflow in a Kerberos 4 component of heimdal, a free implementation of Kerberos 5. The problem is present in kadmind, a server for administrative access to the Kerberos database. This problem could perhaps be exploited to cause the daemon to read a negative amount of data which could lead to unexpected behavior.
Alerts:
Gentoo 200405-23 2004-05-27
Debian DSA-504-1 2004-05-18

Comments (none posted)

icecast: denial of service

Package(s):icecast CVE #(s):
Created:May 19, 2004 Updated:May 19, 2004
Description: The icecast server has a read error in its authorization code which can enable a denial of service attack; upgrading to version 2.0.1 fixes the problem.
Alerts:
Gentoo 200405-10 2004-05-19

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)

racoon: failure to verify signatures

Package(s):ipsec-tools racoon CVE #(s):CAN-2004-0155
Created:April 7, 2004 Updated:August 19, 2004
Description: Versions of ipsec-tools prior to 0.2.5 contain a vulnerability wherein the racoon utility fails to verify digital signatures on some packets. This hole can lead to unauthorized connections or man-in-the-middle attacks. See this advisory for details.
Alerts:
Whitebox WBSA-2004:308-01 2004-08-19
Mandrake MDKSA-2004:027 2004-04-08
Gentoo 200404-05 2004-04-07

Comments (none posted)

racoon: denial of service vulnerability

Package(s):ipsec-tools racoon iputils CVE #(s):CAN-2004-0403
Created:April 26, 2004 Updated:July 29, 2004
Description: racoon does not check the length of ISAKMP headers. Attackers may be able to craft an ISAKMP header of sufficient length to consume all available system resources, causing a Denial of Service. This advisory contains additional details.
Alerts:
Red Hat RHSA-2004:308-01 2004-07-29
Mandrake MDKSA-2004:069 2004-07-14
Fedora FEDORA-2004-197 2004-06-28
Whitebox WBSA-2004:165-01 2004-06-10
Fedora FEDORA-2004-132 2004-05-19
Red Hat RHSA-2004:165-01 2004-05-11
Gentoo 200404-17 2004-04-24

Comments (none posted)

kdelibs: cookie disclosure

Package(s):kdelibs CVE #(s):CAN-2003-0592
Created:March 10, 2004 Updated:August 24, 2004
Description: kdelibs (and, thus, Konqueror) has a vulnerability where a hostile server can force the disclosure of cookies that should not be presented to it. KDE versions 3.1.3 and later contain a fix.
Alerts:
Gentoo 200408-23 2004-08-24
Red Hat RHSA-2004:074-01 2004-03-10
Red Hat RHSA-2004:075-01 2004-03-10
Mandrake MDKSA-2004:022 2004-03-10
Debian DSA-459-1 2004-03-10

Comments (none posted)

kde: URI Handler Vulnerabilities

Package(s):kde Opera CVE #(s):CAN-2004-0411
Created:May 17, 2004 Updated:June 15, 2004
Description: iDEFENSE identified a vulnerability in the Opera Web Browser that could allow remote attackers to create or truncate arbitrary files. The KDE team has found that similar vulnerabilities exists in all version of KDE, up to KDE 3.2.2 inclusive. See this advisory for more information.
Alerts:
Debian DSA-518-1 2004-06-14
Conectiva CLA-2004:843 2004-05-26
SuSE SuSE-SA:2003:014 2004-05-26
Gentoo 200405-19 2004-05-25
Gentoo 200405-11 2004-05-19
Fedora FEDORA-2004-122 2004-05-19
Mandrake MDKSA-2004:047 2004-05-18
Fedora FEDORA-2004-121 2004-05-17
Slackware SSA:2004-238-01 2004-05-17
Red Hat RHSA-2004:222-01 2004-05-17

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: symlink overflow in the iso9660 filessytem

Package(s):kernel CVE #(s):CAN-2004-0109
Created:April 14, 2004 Updated:July 15, 2004
Description: The 2.4 and 2.6 kernels contain a vulnerability in the iso9660 (CDROM) filesystem which can be used by a local attacker to obtain root privileges. The exploit requires creating a specially-crafted filesystem and getting the kernel to mount it. Many systems are configured to automatically mount CDs on insertion, however, so the possibility of this vulnerability being exploited by users with physical access to the system is real. The 2.4.26 kernel contains the fix, which will also be merged into the upcoming 2.6.6 release.
Alerts:
Conectiva CLA-2004:846 2004-07-15
Red Hat RHSA-2004:106-01 2004-04-21
Red Hat RHSA-2004:105-01 2004-04-21
Debian DSA-489-1 2004-04-17
Debian DSA-491-1 2004-04-17
Debian DSA-479-2 2004-04-14
SuSE SuSE-SA:2004:009 2004-04-14
Mandrake MDKSA-2004:029 2004-04-14
Fedora FEDORA-2004-101 2004-04-14
Debian DSA-482-1 2004-04-14
Debian DSA-481-1 2004-04-14
Debian DSA-480-1 2004-04-14
Debian DSA-479-1 2004-04-14

Comments (none posted)

kernel - root exploit in MCAST_MSFILTER

Package(s):kernel CVE #(s):CAN-2004-0424
Created:April 22, 2004 Updated:June 11, 2004
Description: A locally exploitable integer overflow has been found the multicast code of the Linux kernel versions 2.4.22 to 2.4.25 and 2.6.1 - 2.6.3. A successful exploit could lead to full superuser privileges.
Alerts:
Whitebox WBSA-2004:183-01 2004-06-10
SuSE SuSE-SA:2004:010 2004-05-05
Slackware SSA:2004-119-01 2004-04-28
Mandrake MDKSA-2004:037 2004-04-27
Red Hat RHSA-2004:183-01 2004-04-22
Fedora FEDORA-2004-111 2004-04-22
Trustix TSLSA-2004-0022 2004-04-21

Comments (1 posted)

Linux kernel 2.2.10 failing function and TLB flush vulnerability

Package(s):kernel-source-2.2.10 CVE #(s):CAN-2004-0077
Created:March 18, 2004 Updated:June 4, 2004
Description: A local root exploit is possible due to early flushing of the TLB.
Alerts:
Debian DSA-514-1 2004-06-04
Debian DSA-466-1 2004-03-18

Comments (none 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)

kolab: password disclosure

Package(s):kolab CVE #(s):
Created:May 5, 2004 Updated:May 27, 2004
Description: Kolab stores passwords in plain text format, and these passwords can read from the underlying LDAP database. See this advisory for more information.
Alerts:
Mandrake MDKSA-2004:052 2004-05-26
OpenPKG OpenPKG-SA-2004.019 2004-05-05

Comments (3 posted)

LHA: stack buffer overflows and directory traversal flaws

Package(s):LHA CVE #(s):CAN-2004-0234 CAN-2004-0235
Created:April 30, 2004 Updated:June 11, 2004
Description: LHA is an archiving and compression utility for LHarc format archives. Ulf Harnhammar discovered two stack buffer overflows and two directory traversal flaws in LHA. See this advisory+patch for more details.

CAN-2004-0234: An attacker could exploit the buffer overflows by creating a carefully crafted LHA archive in such a way that arbitrary code would be executed when the archive is tested or extracted by a victim.

CAN-2004-0235: An attacker could exploit the directory traversal issues to create files as the victim outside of the expected directory.

Alerts:
Whitebox WBSA-2004:178-01 2004-06-10
Debian DSA-515-1 2004-06-05
Red Hat RHSA-2004:178-01 2004-05-26
Fedora FEDORA-2004-119 2004-05-11
Gentoo 200405-02 2004-05-09
Conectiva CLA-2004:840 2004-05-06
Slackware SSA:2004-125-01 2004-05-04
Red Hat RHSA-2004:179-01 2004-04-30

Comments (2 posted)

libpng: denial of service vulnerability.

Package(s):libpng CVE #(s):CAN-2004-0421
Created:April 29, 2004 Updated:June 11, 2004
Description: The PNG library can accesses memory that is out of bounds when creating an error message, this can be exploited by a malformed PNG image file.
Alerts:
Whitebox WBSA-2004:180-01 2004-06-10
Red Hat RHSA-2004:180-01 2004-05-19
Gentoo 200405-06 2004-05-14
Fedora FEDORA-2004-106 2004-05-05
Fedora FEDORA-2004-105 2004-05-05
Slackware SSA:2004-124-04 2004-05-02
Red Hat RHSA-2004:181-01 2004-04-30
Trustix TSLSA-2004-0025 2004-04-30
Debian DSA-498-1 2004-04-30
Mandrake MDKSA-2004:040 2004-04-29
OpenPKG OpenPKG-SA-2004.017 2004-04-29

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)

libxml2 - arbitrary code execution

Package(s):libxml2 CVE #(s):CAN-2004-0110
Created:February 26, 2004 Updated:July 21, 2004
Description: Yuuichi Teranishi discovered a flaw in libxml2 versions prior to 2.6.6. When fetching a remote resource via FTP or HTTP, libxml2 uses special parsing routines. These routines can overflow a buffer if passed a very long URL. If an attacker is able to find an application using libxml2 that parses remote resources and allows them to influence the URL, then this flaw could be used to execute arbitrary code.
Alerts:
Fedora-Legacy FLSA:1324 2004-07-19
Conectiva CLA-2004:836 2004-03-31
Gentoo 200403-01 2004-03-06
Trustix TSLSA-2004-0010 2004-03-05
OpenPKG OpenPKG-SA-2004.003 2004-03-05
Netwosix NW-2004-0004 2004-03-04
Debian DSA-455-1 2004-03-03
Mandrake MDKSA-2004:018 2004-03-03
Red Hat RHSA-2004:091-02 2004-03-03
Whitebox WBSA-2004:090-01 2004-03-01
Red Hat RHSA-2004:090-01 2004-02-26
Fedora FEDORA-2004-087 2004-02-25
Red Hat RHSA-2004:091-01 2004-02-26

Comments (none posted)

logcheck: symlink vulnerability

Package(s):logcheck CVE #(s):CAN-2004-0404
Created:April 21, 2004 Updated:December 22, 2004
Description: The logcheck utility handles temporary files in an unsafe way, possibly allowing local attackers to overwrite files.
Alerts:
Mandrake MDKSA-2004:155 2004-12-22
Debian DSA-488-1 2004-04-16

Comments (none posted)

mailman denial of service

Package(s):mailman CVE #(s):CAN-2003-0991
Created:February 9, 2004 Updated:May 25, 2004
Description: Matthew Galgoci of Red Hat discovered a Denial of Service (DoS) vulnerability in versions of Mailman prior to 2.1. An attacker could send a carefully-crafted message causing mailman to crash. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2003-0991 to this issue.
Alerts:
Conectiva CLA-2004:842 2004-05-25
Red Hat RHSA-2004:156-01 2004-04-14
Mandrake MDKSA-2004:013 2004-02-13
Red Hat RHSA-2004:019-01 2004-02-09

Comments (1 posted)

mc: multiple vulnerabilities

Package(s):mc CVE #(s):CAN-2004-0226 CAN-2004-0231 CAN-2004-0232
Created:April 29, 2004 Updated:May 26, 2004
Description: Midnight Commander has multiple vulnerabilities including buffer overflows, insecure temp files, and format string problems.
Alerts:
Gentoo 200405-21 2004-05-26
Red Hat RHSA-2004:172-01 2004-05-19
Slackware SSA:2004-136-01 2004-05-14
SuSE SuSE-SA:2004:012 2004-05-14
Red Hat RHSA-2004:173-01 2004-04-30
Mandrake MDKSA-2004:039 2004-04-29
Debian DSA-497-1 2004-04-29

Comments (none posted)

metamail: integer and buffer overflows

Package(s):metamail CVE #(s):CAN-2004-0104 CAN-2004-0105
Created:February 18, 2004 Updated:May 21, 2004
Description: Versions of metamail through 2.7 contain a set of integer and buffer overflows which are remotely exploitable via a properly crafted message.
Alerts:
Gentoo 200405-17 2004-05-21
Debian DSA-449-1 2004-02-24
Mandrake MDKSA-2004:014 2004-02-18
Slackware SSA:2004-049-02 2004-02-18
Red Hat RHSA-2004:073-01 2004-02-18

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)

mozilla: multiple vulnerabilties

Package(s):mozilla CVE #(s):CAN-2003-0594 CAN-2003-0564
Created:March 10, 2004 Updated:August 19, 2004
Description: Mozilla 1.4 contains a few vulnerabilities, including disclosure of cookies to the wrong server, a scripting vulnerability which can allow an attacker to run arbitrary code, and an S/MIME vulnerability which can lead to remote denial of service or code execution attacks.
Alerts:
Whitebox WBSA-2004:421-01 2004-08-19
Whitebox WBSA-2004:110-01 2004-03-29
Red Hat RHSA-2004:112-01 2004-03-17
Mandrake MDKSA-2004:021 2004-03-10

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)

MySQL: temporary file vulnerabilities

Package(s):mysql CVE #(s):CAN-2004-0381 CAN-2004-0388
Created:April 14, 2004 Updated:August 18, 2004
Description: The mysqlbug and mysqld_multi scripts contain temporary file vulnerabilities which could be used by a local attacker to overwrite files on the system.
Alerts:
Gentoo 200405-20 2004-05-25
Mandrake MDKSA-2004:034 2004-04-19
OpenPKG OpenPKG-SA-2004.014 2004-04-14
Debian DSA-483-1 2004-04-14

Comments (none posted)

neon: buffer overflow

Package(s):neon CVE #(s):CAN-2004-0398
Created:May 19, 2004 Updated:September 30, 2004
Description: The neon library (through version 0.24.5) contains a buffer overflow in its date parsing code, allowing arbitrary code execution when connecting to a hostile server. See this advisory for details. This vulnerability also affects related applications (such as cadaver).
Alerts:
Fedora-Legacy FLSA:1552 2004-09-29
Mandrake MDKSA-2004:078 2004-07-29
Gentoo 200406-03 2004-06-05
Gentoo 200405-25b 2004-06-02
Gentoo 200405-25 2004-05-30
Conectiva CLA-2004:841 2004-05-25
Gentoo 200405-15 2004-05-20
Gentoo 200405-13 2004-05-20
OpenPKG OpenPKG-SA-2004.024 2004-05-19
Mandrake MDKSA-2004:049 2004-05-19
Fedora FEDORA-2004-130 2004-05-19
Fedora FEDORA-2004-129 2004-05-19
Red Hat RHSA-2004:191-01 2004-05-19
Debian DSA-507-1 2004-05-19
Debian DSA-506-1 2004-05-19

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)

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)

OpenSSL: denial of service vulnerabilities

Package(s):OpenSSL CVE #(s):CAN-2004-0081 CAN-2003-0851
Created:March 17, 2004 Updated:November 2, 2005
Description: Versions 0.9.7a-c of the OpenSSL library suffer from two denial of service vulnerabilities; see the version 0.9.7d release announcement for details.
Alerts:
Red Hat RHSA-2005:830-00 2005-11-02
Red Hat RHSA-2005:829-00 2005-11-02
Fedora FEDORA-2005-1042 2005-10-31
Fedora-Legacy FLSA:1395 2004-05-08
Conectiva CLA-2004:834 2004-03-31
Whitebox WBSA-2004:084-01 2004-03-23
Red Hat RHSA-2004:084-01 2004-03-23
Fedora FEDORA-2004-095 2004-03-19
Whitebox WBSA-2004:120-01 2004-03-22
Trustix TSLSA-2004-0012 2004-03-17
Slackware SSA:2004-077-01 2004-03-17
Red Hat RHSA-2004:121-01 2004-03-17
OpenPKG OpenPKG-SA-2004.007 2004-03-18
Gentoo 200403-03 2004-03-17
Debian DSA-465-1 2004-03-17
Netwosix NW-2004-0005 2004-03-17
Mandrake MDKSA-2004:023 2004-03-17
SuSE SuSE-SA:2004:007 2004-03-17
Red Hat RHSA-2004:120-01 2004-03-17
Red Hat RHSA-2004:119-01 2004-03-17
EnGarde ESA-20040317-003 2004-03-17

Comments (1 posted)

passwd: various problems

Package(s):passwd CVE #(s):
Created:May 17, 2004 Updated:June 2, 2004
Description: Steve Grubb found some problems in the passwd program. Passwords given to passwd via stdin are one character shorter than they are supposed to be. He also discovered that pam may not have been sufficiently initialized to ensure safe and proper operation. A few small memory leaks have been fixed as well.
Alerts:
Mandrake MDKSA-2004:045 2004-05-17

Comments (none 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)

Pound format string vulnerability

Package(s):pound CVE #(s):
Created:May 18, 2004