LWN.net Logo

LWN.net Weekly Edition for April 7, 2005

The kernel and BitKeeper part ways

Back in early 1999, your editor got a call from Larry McVoy. He was worried that Linus Torvalds was on the verge of burning out as the kernel project grew. The problems in those days were quite evident; Linus, it was being said, did not scale. But, according to Larry, a complete burnout was not inevitable. If Linus could be given the right tools, many of his problems (and the frustrations of other kernel developers) could be solved, and the system would run smoothly again. The right tool, according to Larry, was a thing called BitKeeper; if some sort of agreement could be made on licensing, Larry (along with his company, BitMover) was willing to make BitKeeper available for kernel development. In fact, Larry wanted to see BitKeeper used for all free software development; see this article from the March 25, 1999 LWN Weekly Edition for a view of how things looked at that time.

Three years later, the situation did not look any better. The 2.4 kernel had taken almost a full year to stabilize after 2.4.0 came out. 2.5 had begun, but the process was looking rocky at best. Patches were being dropped, developers were complaining, and Linus was getting tired. After convincing himself that the tool had reached a point where it could do what he needed, Linus decided to give BitKeeper a try. There was no looking back.

Some of the development process issues could have been addressed by adopting any source code management system. But BitKeeper brought more than that; it established a model where there is no central repository. Instead, each developer could maintain one or more fully independent trees. When the time came, patches of interest could be "pulled" from one tree to another while retaining the full revision history. Rather than send patches in countless email messages - often multiple times - developers could simply request a pull from their BitKeeper trees. Meanwhile, the current development trees could be pulled automatically into the -mm kernel, allowing patches to be tested by a wider audience prior to merging into the mainline. BitKeeper enabled a work method and patch flow which naturally supported the kernel's development model.

Once the developers and the tools got up to speed, kernel development took off like never before. The rate at which patches were merged skyrocketed, the developers were happy, and the whole system ran smoothly. The public version of Linus's BitKeeper repository (and the repositories of many other developers) made the development process more transparent than ever. Anybody could look to see the up-to-the-minute state of the kernel and how it got there. Larry was right: with the right tools, Linus really could scale.

The only problem was that BitKeeper is proprietary software. Instead, it came (in binary-only form) with a license which allowed free use, but which imposed some significant restrictions. The free version of BitKeeper could only be used with open source projects; users could be required to make their repositories available on demand. The free version posted all changelog information on openlogging.org, and disabling the logging was not allowed. Users were required to upgrade to new versions, which could come with different licenses. And users were not only prohibited from reverse engineering the software, but they were prohibited from working on any sort of source code management system at all.

Larry wanted to have his cake and eat it too. He truly wanted to support the development of free software - as long as that software didn't threaten his own particular business niche. Supporting the kernel development cost real money - and supporting the business which created BitKeeper cost even more. Whenever BitMover felt that its business model was threatened, it responded; often the BitKeeper licensing terms were changed in response to perceived threats - to the point that the BitKeeper license became known in some circles as the "don't piss off Larry license."

Well, somebody pissed off Larry one time too many. The final straw, it seems, was a certain high-profile developer who refused to stop reverse engineering work while simultaneously doing some work for OSDL. BitMover is now withdrawing support for the free version of BitKeeper, and Linus has ceased to use it. BitKeeper is no longer the source code management system for the kernel. Proprietary software can be good stuff, but it always carries this threat: you never really know if it will be there for you tomorrow or not. BitMover has decided that it can no longer afford to make BitKeeper available for the free software community.

BitMover has issued a press release on this change:

BitMover looks forward to implementing our extensive roadmap and delivering advanced SCM technology to a wider market. As part of this focus, BitMover has replaced the free version of BitKeeper with the recently released open source BitKeeper client. Those developers who desire additional functionality may choose to migrate to the more powerful commercial version of BitKeeper.

The open source client, incidentally, enables the extraction of the current version from a repository, but does little else. The PR also states that "Our relationship with the Open Source community has been evolving and many of the key developers have already migrated to the commercial version of BitKeeper." Linus has, however, made it clear that he is not one of those "key developers":

Right now, the only real thing that has happened is that I've decided to not use BK mainly because I need to figure out the alternatives, and rather than continuing "things as normal", I decided to bite the bullet and just see what life without BK looks like. So far it's a gray and bleak world ;)

What happens next is far from clear. The kernel developers will not go back to the previous way of doing things - no source code management system at all. Even the developers who can continue to use BitKeeper are unlikely to continue doing so if Linus is unable to pull their patches. So a replacement will have to be found. It is not clear that any of the free alternatives is up to the task of handling a project as large as the kernel. One of them may end up growing up in a hurry in order to take the load. Thanks partly to the example and motivation provided by BitKeeper, the free alternatives do look far more viable than they did three years ago, when Linus first started using BitKeeper.

Larry has made it clear that he blames the free software community for this turn of events:

I'm far from blameless but the majority of this problem is an open source community problem. They simply don't want to play with non-open source. At least some of them don't and they ruin it for the rest of us. The problem here is one of policing. By ignoring/tolerating the bad apples the community punishes itself.

If BitKeeper users were violating the license under which they received the software, they have indeed done something wrong. Every time we release code under a free license, we do so with the expectation that the terms of that license will be respected. To treat somebody else's license with less respect is hypocritical; if the license terms are not acceptable, do not use the software. That said, one could note a couple of other things. The notion that developers of proprietary software do not engage in reverse engineering - that it's "an open source community problem" - is debatable at best. And how, exactly, might the community be expected to do this sort of "policing"?

The ironic result of all this is likely to be the accelerated development of exactly what Larry claims to most fear: a free source code management system that, while it lacks much of what makes BitKeeper great, is "good enough" for a large portion of the user base. As the BitKeeper developers found out, hosting the kernel project is an effective way to shake out scalability and usability problems. Whichever system ends up hosting the kernel can be expected to go through a period of rapid improvement.

BitMover did, in fact, get a few benefits from hosting the kernel, even if, in the company's view, the benefits do not come close to equaling the associated costs. BitKeeper is a more scalable and robust system as a result of the use it saw in that role. There were also substantial PR benefits; see, for example, this 2004 press release with nice quotes from David Miller and Linus Torvalds. There can be no doubt that working with the kernel has brought a great deal of visibility to BitKeeper, and that must have resulted in some new business. The cynical among us might conclude (and some already have concluded) that BitMover simply decided that it had obtained most of the benefits it was going to get from hosting the kernel and decided to move on.

Whether or not that is the case, it cannot be doubted that Linux, too, has benefited strongly from its association with BitKeeper. We would not have a 2.6 kernel with anything near its level of capability, scalability, and robustness without the role played by BitKeeper. One could easily argue that the free source code management systems would not be as good as they are had BitKeeper not come along. BitKeeper was a gift to the community that was well worth accepting; now that it is gone, the best thing to do is to say "thanks" (with sincerity!) and figure out what comes next.

Comments (65 posted)

Ubuntu and UserLinux

April 6, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

Despite what you may have heard on Slashdot, UserLinux and Ubuntu aren't going to be merging anytime soon. A few weeks ago, Ubuntu's Jeff Waugh invited the UserLinux project to "collaborate with Ubuntu to build the finest platform and community for FOSS service providers." This was after a discussion about the problems of trying to build UserLinux around Debian when it's taking a long time for a new stable release from Debian. Waugh's invitation generated a fair amount of additional discussion on the UserLinux list, but little comment from UserLinux founder Bruce Perens. It's become clear that Ubuntu and UserLinux will remain separate for the foreseeable future, but we decided to check in with Perens to see what he had to say about the whole thing.

Perens was quick to note that he supports Ubuntu, but doesn't think that Ubuntu's corporate-sponsored model is the way to go for UserLinux.

When Mark [Shuttleworth] started to work on Ubuntu, he called me up and we talked about whether I'd be interested in taking a leadership position in Ubuntu and I decided not to pursue that, because I feel that a non-profit is the correct paradigm for a Linux distribution. A Linux distribution is inherently not a profit-making enterprise and we are seeing [some of] the commercial Linux distributions abuse the open source paradigm because of that fact.

In addition, Perens said that Debian's development process allows anyone to become a developer and run for Project Leader or hold another Debian office, which doesn't exist in other projects. "You can be part of Ubuntu's community or Fedora's community, you don't get the chance to be boss."

Shortly after Waugh's invitation on the UserLinux mailing list, some of the Ubuntu team created experimental UserLinux packages for Ubuntu. The metapackages would allow creating "a sort of Ubuntu-flavored UserLinux." Unfortunately, the packages were also in violation of the UserLinux trademark policy. When we asked about the situation, Perens noted the importance of having a trademark policy, given the abuse of the Debian trademark "in various ways" and that "the UserLinux guys get to say what can be called UserLinux when they do their version of the Debian release." He also said he didn't have a problem with labeling the packages "ul" or something similar to distinguish them from official UserLinux packages. It would appear, after a bit of friction, that the projects are sorting out the trademark issue so Ubuntu can include the metapackages.

But the Ubuntu effort highlights the problem of perceived inertia for UserLinux. Perens announced UserLinux in December of 2003. There was a great deal of interest in the idea at the time, but the wait for a Debian release has certainly had an impact on the momentum of the project.

Perens conceded that there was a perception among the Linux community that UserLinux had stagnated, but said that the perception can be overcome.

A lot of people would have given up now, because the time-to-market is totally blown, but this was never intended to be a start-up business. Having been on board or watching the last five companies that were attempting to commercialize Debian, I have some idea what went wrong and what went right and I think we can make this idea work with businesses.

As far as UserLinux, I think what I would like to do, is once Debian has made a release, have our roster of support companies ready to support it, and to just start giving these things out at Linux-related business events and saying 'here's a system with full support, here's a price sheet, and we're going to give you a lower cost of ownership than Linux. We're going to beat other Linux distributions on TCO and we're going to give you more control because, more than Fedora, more than Ubuntu, you get a chance to determine exactly how the system is built, because it's tracking what the Debian organization does, it's not a Debian variant.

Perens also told LWN that the best way for someone to help with UserLinux is to be involved with Debian.

For people in the community, my main desire is that they work on Debian, okay? We can use some people on the UserLinux project, but the UserLinux policy is when we make software, we do it on Debian teams, and check it into Debian Subversion, don't issue as separate UL packages unless there's a Debian freeze...I think that Debian is a very healthy community, despite the challenges.

To outsiders, however, it may appear at times that the Debian Project is too mired in political disagreements and flame wars to actually get anything done -- which is a significant objection to wanting to be involved with Debian. Perens said that there is a need to convince "a significant portion of 1,000 active developers that your policy is right" when working with Debian, but "that in itself is a quality assurance process."

Perens said he was "heartened" by the recent announcement that Debian will soon be doing a release, and that "when Debian wants to get off the dime, they can." He also said that the Debian developers have been "pretty embarrassed by the long delay of the release" and have bit the bullet to get it out the door. He also predicted that the next Debian release after Sarge will be scheduled, and it will be kept on schedule.

It will be interesting to see what happens after Debian Sarge is released, and whether the UserLinux project can succeed as distribution for "businesses of all sizes."

Comments (4 posted)

GCJ - past, present, and future

April 6, 2005

This article was contributed by Mark Wielaard

GCJ (the GNU Compiler for the java programming language) is part of GCC (the GNU Compiler Collection) and provides a compiler, runtime environment, core libraries and tools for the Java language - it's an object oriented, strongly typed, garbage collected programming framework with a rich core library. GCJ is modeled after, and is a free replacement for, the proprietary Java platform. But like GNU is Not Unix, GCJ is not Java.

The traditional Java platform is clearly not an ideal system, especially when combined with the traditional GNU system, but it is not too bad. The essential features seem to be good ones. Lots of Free Software is already written in the Java programming language so a free system compatible with the Java platform would be convenient for many hackers. GCJ is an extension of GCC and facilitates integration with other languages supported by GCC. GCJ 4, part of GCC 4.0, adds more features to easily integrate programs written using the GCJ development environment with the rest of the GNU platform while being even more compatible with the traditional Java platforms then previous releases. GCC 4.0 is scheduled to be released around April 15.

GCJ design history

Originally GCJ was designed as a “radically traditional” compiler for the Java programming language. It is an AOT (Ahead Of Time) compiler which automatically uses every GCC optimization available during compile time for a given architecture and produces binaries or (shared) libraries for the given platform. These programs run at full native speed without needing any interpreter or JIT (Just In Time) compilation. GCC is available for a large number of architectures and platforms so compiling directly to native code using the GCC back-ends makes programs written with GCJ much more portable then the traditional (proprietary) Java platform. This radically traditional approach makes all normal GNU tools like GDB available to the programmer writing code in the Java programming language just like when programming in any other language supported by GCC.

Thereafter, support for generating and interpreting byte code .class and .jar files was added. This made GCJ more compatible with traditional applications written in the Java programming language that are compiled to byte code. GCJ can be used in various modes:

  1. Compile and link .java source files to binaries, .o or .so files.
  2. Compile and link .class or .jar byte code files to binary.
  3. Compile .java source files to .class byte code files (gcj -C).
  4. Interpret .class or .jar byte code files during runtime (gij).

The byte code interpreter is included as part of the standard runtime libgcj and can be used by programs to switch between interpreting byte code and executing natively compiled code on demand. So not all of the program has to be completely interpreted or completely compiled ahead of time at the same time.

To facilitate integration with code written in other languages, GCJ defines the CNI (Compiled Native Interface). CNI makes it easy to mix and match code and classes written in C, C++ and Java by allowing you to write some methods of a class in C++ and to catch and throw exceptions directly to and from parts of the program written in different languages. GCJ also support the more traditional JNI (Java Native Interface) for using code written in C from your programs.

Anthony Green posted the original design document for GCJ from 1998.

Drawbacks of the GCJ 3.x approach

GCJ 3.x provides a good “better than Java” development environment that allows tight integration with the rest of the GNU platform. But it has disappointed some traditional Java programmers. The possibility to mix and match native code with byte code in the compiler and libgcj runtime makes GCJ very flexible. But falling back to interpreting byte code doesn't really take full advantage of the whole “radically traditional” approach. Especially programs using advanced byte code based class loader tricks used to work slowly because they fell back to using the interpreter during runtime.

There are GCJ extensions to add support for using natively compiled code all the time. But programs had to be adapted to use these extensions. Instead of using .jar files containing byte code definitions of new classes programs would have to use a new URL scheme (gcjlib:) for their URLClassLoader uses. The first “Fast Free Eclipse” port to GCJ was done this way. The source code of the plugin loading mechanism was adapted to search for natively compiled plugins in shared library .so files besides ordinary .jar byte code files. There was even a moderately popular project, rhug, that maintained a lot of patched versions of traditional free Java programs that were adapted to gcj's view of the world. But these patches were almost never adopted upstream and the maintenance of these forks took a lot of time. So the benefits of the GCJ approach were only seen by programs written explicitly for it, but not by traditional Java programs.

One of the main goals of the GCJ 4 effort was to bring all the advantages of the “radically traditional” approach to any program written in the Java programming language without needing any application-level changes.

GCJ 4 enhancements

Probably the most visible enhancement of GCJ 4 comes from merging the libgcj runtime with the GNU Classpath core class library project. By collaborating with other free runtimes like the traditional kaffe environment and around 20 other projects, GCJ 4 is able to offer a core class library comparable to JDK 1.3 or 1.4. The collaboration of all these projects on a common core library implementation means that a lot of the libraries needed by applications, except for advanced Swing, Corba and sound usage, are available out of the box. Kaffe, for example, is being used by the Apache project to track the build of most of the jakarta projects using their Gump auto-builder.

The other big change is the addition of the -findirect-dispatch switch to the compiler. Using that option causes GCJ to generate native code for classes and methods that follow the precise same binary compatibility rules as described in the Java Language Specification. This means that native compiled code can now be used everywhere, even in the most tricky class loader situations, where previously the program would fall back to interpreted byte code. At the 2004 GCC Summit Tom Tromey and Andrew Haley described this new binary compatibility ABI for GCJ in more detail.

The new binary compatibility (BC) ABI makes it possible to transparently compile programs to native code using gcj -findirect-dispatch without having to change the application source code or even the build process. To map byte code to GCJ compiled native code, GCJ 4 introduces gcj-dbtool. This tool is used by the packager during deployment of the application or library to create a database mapping the bytecode of a class to the native code during runtime. Programs can use different databases using the gnu.gcj.precompiled.db.path system property. The databases make it possible to create a cache of all native compiled code that can be shared by different programs installed on the system. The How to BC compile with GCJ GCC wiki page has examples.

This approach is used by the native Eclipse packages in Fedora Core 4. No changes to the eclipse code base are necessary anymore and, after the project is bootstrapped, all resulting .jar files are BC compiled. To almost completely automate this process, Thomas Fitzsimmons created java-gcj-compat. A collection of wrapper scripts, symlinks and jar files that provide a Java-SDK-like interface to this new GCJ 4 tool set.

Future plans

The -findirect-dispatch switch can currently only be used for byte code and not in combination with CNI (JNI is already supported). This limitation currently prevents parts of the core class libraries from being BC compiled. Lifting this restricting will facilitate more integration with GNU Classpath.

With GCJ and GDB a programmer can step through native C, C++ and Java source code using the same tool. Traditional Java developers are more used to JDWP (Java Debugging Wire Protocol) for debugging their applications. Eclipse comes with built-in support for JDWP. Work is in progress to provide JDWP debugging support for the different execution mechanisms. This code will also be shared with the GNU Classpath project.

Benchmarks show that GCJ is comparable (sometimes faster, sometimes slower) to traditional execution mechanisms for Java programs. But GCJ currently doesn't really take advantage of the new GCC 4.0 Tree SSA optimizer framework. For 4.1 the GCJ developers hope to add a couple of GCJ specific optimizations.

Tom Tromey is currently working on GCJX, a new GCC frontend that will include support for the new 1.5 language additions, such as generics. And the GNU Classpath project has a separate branch for the core class libraries that depend on the new 1.5 language additions.

Escaping the Java Trap

GCJ 4 is the result of seven years of work by a large and active community of Free Software hackers. This new version is complete enough to replace most interesting uses of the proprietary Java platform. It adds a whole new set of core libraries and adds some new features to help integration with the rest of the GNU platform. Upcoming versions of some GNU/Linux distributions will use GCJ 4 to provide much more Java-based Free Software, including Eclipse, Jonas, OpenOffice.org 2, Tomcat and the Jakarta libraries. There is also a great deal of free software to integrate with traditional GNU/Linux distributions provided by the JPackage project. Both Debian and Fedora are working with the jpackage hackers to support more of these packages “out of the box”.

All this doesn't mean that we have escaped the Java trap yet. As pointed out by Richard Stallman in “Free But Shackled - The Java Trap” we have to actively work together to keep code safe and free. It looks like the main target projects for GCJ 4 (Apache Jakarta, Eclipse and OpenOffice.org 2), have all reacted positively to the feedback and patches provided to support free alternatives to the Java platform. The fact that the changes requested were for making the projects more portable ("don't use undocumented com.sun internal classes") rather than requests to dramatically change the code, (core) libraries used or build infrastructure has helped a lot. But the above projects were already free software projects at heart. It remains to be seen if other more traditional java projects will adapt so easily to support GCJ 4 out of the box.

Comments (44 posted)

Page editor: Jonathan Corbet

Security

Blocking popups in FireFox

April 6, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

One of the most compelling features of Firefox, for many users, is its built-in pop-up blocking. However, the advertising networks and webmasters looking to inflict pop-up ads on users weren't content to allow Firefox users (or anyone else, for that matter) to browse in peace. It's not surprising that, as Firefox gains in popularity, the Mozilla team would be faced with an "arms race" with advertisers determined to spawn pop-ups on all visitors to sponsored sites.

This writer has recently noticed that some sites had begun spawning pop-ups, despite the fact that Firefox's preferences had been configured to block them. After so long without having to cope with pop-ups, it was doubly annoying to see the nuisance starting all over again.

For the most part, before Firefox and other pop-up blockers appeared on the scene, pop-ups and pop-unders were spawned by JavaScript as soon as a site loads. The Firefox pop-up blocking settings were very successful in blocking almost all pop-up ads. The notable exception, at least for this user, was the New York Times website, which was one of the first sites to find a workaround for Firefox's pop-up blocking.

JavaScript, however, is not the only method that can be used to spawn pop-ups. Notably, Flash, Java and other plugins are capable of spawning pop-ups and bypass the restrictions used to stop pop-ups spawned by JavaScript. To start blocking pop-ups on sites that take advantage of features in Flash or Java to spawn pop-ups, users can install the Pop-ups Must Die! extension.

Alternately, users can get the same effect by manually fine-tuning Firefox's settings. The first change, adding "privacy.popups.disable_from_plugins" is described here. The extension also changes the value of "dom.popup_allowed_events" to block all allowed pop-up events. This can be done by entering "about:config" in the Firefox address bar, and finding "dom.popup_allowed_events," and removing all of the options. These are the only two changes made by the extension.

The changes seem to have been very effective -- perhaps a little too effective. Several users have complained that the extension blocks requested pop-ups as well. This is true, but Firefox still allows users to whitelist sites after a pop-up has been blocked by the new settings. This writer considers it a small price to pay to avoid unrequested pop-ups. For those who would rather deal with the occasional unrequested pop-up, one may change "privacy.popups.disable_from_plugins" to "1" to allow pop-ups to be opened when a link is clicked. This will limit the number of windows opened by a link, so nefarious webmasters cannot open an unlimited number of windows.

Determined webmasters, however, can find ways to inflict advertising on users in other ways. Consider this site which was pointed out in the discussion about the "Pop-ups Must Die!" extension. Rather than spawning a pop-up, it creates a frame within the window that blocks the content of the site until the frame "window" is closed. Without disabling frames, which would cause a great deal of problems for sites that use them legitimately, it's difficult to imagine how one could avoid this kind of "pop-up." (Note, disabling frames by changing the value of "browser.frames.enabled" to false appears to break Firefox entirely.)

Ultimately, the best solution may not rest with Firefox. Users who are offended by pop-ups, and other intrusive advertising, have an infallible weapon at their disposal -- stop visiting sites that insist on using pop-ups. While it would require a great number of users to be effective, even the most persistent webmasters and advertisers would have to reconsider their methods if they have no audience for their ads.

Comments (7 posted)

New vulnerabilities

Dnsmasq: poisoning and DoS

Package(s):dnsmasq CVE #(s):
Created:April 4, 2005 Updated:July 21, 2005
Description: Dnsmasq does not properly detect that DNS replies received do not correspond to any DNS query that was sent. Rob Holland of the Gentoo Linux Security Audit team also discovered two off-by-one buffer overflows that could crash DHCP lease files parsing.
Alerts:
Slackware SSA:2005-201-01 2005-07-21
Gentoo 200504-03 2005-04-04

Comments (none posted)

gaim: buffer overflow, DoS

Package(s):gaim CVE #(s):CAN-2005-0965 CAN-2005-0966
Created:April 5, 2005 Updated:May 15, 2005
Description: Jean-Yves Lefort discovered a buffer overflow in the gaim_markup_strip_html() function. This caused Gaim to crash when receiving certain malformed HTML messages. (CAN-2005-0965)

Jean-Yves Lefort also noticed that many functions that handle IRC commands do not escape received HTML metacharacters; this allowed remote attackers to cause a Denial of Service by injecting arbitrary HTML code into the conversation window, popping up arbitrarily many empty dialog boxes, or even causing Gaim to crash. (CAN-2005-0966)

Alerts:
Slackware SSA:2005-133-01 2005-05-15
Conectiva CLA-2005:949 2005-04-27
Slackware SSA:2005-111-03 2005-04-22
Mandriva MDKSA-2005:071 2005-04-13
Red Hat RHSA-2005:365-01 2005-04-12
Gentoo 200504-05 2005-04-06
Fedora FEDORA-2005-299 2005-04-05
Fedora FEDORA-2005-298 2005-04-05
Ubuntu USN-106-1 2005-04-05

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CAN-2005-0400 CAN-2005-0749 CAN-2005-0750 CAN-2005-0815 CAN-2005-0839
Created:April 1, 2005 Updated:July 1, 2005
Description: More kernel vulnerabilities have been discovered including:
  • Mathieu Lafon discovered an information leak in the ext2 file system driver. (CAN-2005-0400)
  • Yichen Xie discovered a Denial of Service vulnerability in the ELF loader. (CAN-2005-0749)
  • Ilja van Sprundel discovered that the bluez_sock_create() function did not check its "protocol" argument for negative values. (CAN-2005-0750)
  • Michal Zalewski discovered that the iso9660 file system driver fails to check ranges properly in several cases. (CAN-2005-0815)
  • Previous kernels did not restrict the use of the N_MOUSE line discipline in the serial driver. (CAN-2005-0839)
Alerts:
Mandriva MDKSA-2005:110 2005-06-30
Mandriva MDKSA-2005:111 2005-06-30
Fedora-Legacy FLSA:152532 2005-06-04
Conectiva CLA-2005:952 2005-05-02
Red Hat RHSA-2005:284-01 2005-04-28
Red Hat RHSA-2005:283-01 2005-04-28
Red Hat RHSA-2005:293-01 2005-04-22
Fedora FEDORA-2005-313 2005-04-11
Trustix TSLSA-2005-0011 2005-04-05
SuSE SUSE-SA:2005:021 2005-04-04
Ubuntu USN-103-1 2005-04-01

Comments (1 posted)

limewire: input validation errors

Package(s):limewire CVE #(s):CAN-2005-0788 CAN-2005-0789
Created:March 31, 2005 Updated:April 6, 2005
Description: LimeWire, a Java-based peer-to-peer client that works with the Gnutella file-sharing protocol, has two input validation errors that can allow a remote attacker to read arbitrary files with the permissions that LimeWire is running under.
Alerts:
Gentoo 200503-37 2005-03-31

Comments (none posted)

remstats: tempfile, missing input sanitizing

Package(s):remstats CVE #(s):CAN-2005-0387 CAN-2005-0388
Created:April 4, 2005 Updated:April 6, 2005
Description: Jens Steube discovered several vulnerabilities in remstats, the remote statistics system. When processing uptime data on the unix-server a temporary file is opened in an insecure fashion which could be used for a symlink attack to create or overwrite arbitrary files with the permissions of the remstats user. (CAN-2005-0387) The remoteping service can be exploited to execute arbitrary commands due to missing input sanitizing. (CAN-2005-0388)
Alerts:
Debian DSA-704-1 2005-04-04

Comments (none posted)

php4: denial of service vulnerabilities

Package(s):php4 CVE #(s):CAN-2005-0524 CAN-2005-0525
Created:April 5, 2005 Updated:May 26, 2005
Description: Two DoS vulnerabilities exist in PHP versions 4.2.2, 4.3.9, 4.3.10 and 5.0.3. One in the php_handle_iff function in image.c allows remote attackers to cause a denial of service (infinite loop) via a -8 size value. The php_next_marker function in image.c allows remote attackers to cause a denial of service (infinite loop) via a JPEG image with an invalid marker value, which causes a negative length value to be passed to php_stream_seek. This later vulnerability also exists in PHP 3.
Alerts:
Debian DSA-729-1 2005-05-26
Gentoo 200504-15 2005-04-18
Fedora FEDORA-2005-315 2005-04-15
Debian DSA-708-1 2005-04-15
SuSE SUSE-SA:2005:023 2005-04-15
Slackware SSA:2005-095-01 2005-04-06
Ubuntu USN-105-1 2005-04-05

Comments (none posted)

sharutils: insecure temporary files

Package(s):sharutils CVE #(s):
Created:April 4, 2005 Updated:April 14, 2005
Description: Joey Hess discovered that "unshar" created temporary files in an insecure manner. This could allow a symbolic link attack to create or overwrite arbitrary files with the privileges of the user invoking the program.
Alerts:
Fedora FEDORA-2005-319 2005-04-14
Mandrake MDKSA-2005:067 2005-04-07
Gentoo 200504-06 2005-04-06
Ubuntu USN-104-1 2005-04-04

Comments (1 posted)

sylpheed: buffer overflow on message

Package(s):sylpheed sylpheed-claws CVE #(s):
Created:April 4, 2005 Updated:April 6, 2005
Description: Sylpheed and Sylpheed-claws fail to properly handle messages containing attachments with MIME-encoded filenames.
Alerts:
Gentoo 200504-02 2005-04-02

Comments (none posted)

wu-ftpd: missing input sanitizing

Package(s):wu-ftpd CVE #(s):CAN-2005-0256
Created:April 4, 2005 Updated:April 6, 2005
Description: The wu_fnmatch function in wu_fnmatch.c for wu-fptd 2.6.1 and 2.6.2 allows remote attackers to cause a denial of service (CPU exhaustion by recursion) via a glob pattern with a large number of * (wildcard) characters, as demonstrated using the dir command.
Alerts:
Debian DSA-705-1 2005-04-04

Comments (none posted)

Updated vulnerabilities

a2ps: input validation error

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

Comments (none posted)

cdrecord: insecure temp file

Package(s):cdrecord CVE #(s):CAN-2005-0866
Created:March 24, 2005 Updated:April 28, 2005
Description: The cdrecord utility makes insecure temp files if DEBUG is enabled in /etc/cdrecord/rscsi. This can allow a local user to launch a sym link attack and execute code with the user's privileges.
Alerts:
Mandriva MDKSA-2005:077 2005-04-20
Ubuntu USN-100-1 2005-03-24

Comments (1 posted)

cpio - file permissions error

Package(s):cpio CVE #(s):CAN-1999-1572
Created:February 2, 2005 Updated:July 19, 2005
Description: Some versions of cpio contain an ancient vulnerability where files created by that utility have overly generous access permissions.
Alerts:
Fedora-Legacy FLSA:152891 2005-07-15
Red Hat RHSA-2005:080-01 2005-02-18
Red Hat RHSA-2005:073-01 2005-02-15
Mandrake MDKSA-2005:032-1 2005-02-11
Mandrake MDKSA-2005:032 2005-02-10
Ubuntu USN-75-1 2005-02-04
Debian DSA-664-1 2005-02-02

Comments (none posted)

cURL: buffer overflow

Package(s):curl CVE #(s):CAN-2005-0490
Created:February 28, 2005 Updated:July 19, 2005
Description: Multiple stack-based buffer overflows in libcURL and cURL 7.12.1, and possibly other versions, allow remote malicious web servers to execute arbitrary code via base64 encoded replies that exceed the intended buffer lengths when decoded.
Alerts:
Fedora-Legacy FLSA:152917 2005-07-15
Fedora FEDORA-2005-325 2005-04-20
Red Hat RHSA-2005:340-01 2005-04-05
Conectiva CLA-2005:940 2005-03-21
Gentoo 200503-20 2005-03-16
Mandrake MDKSA-2005:048 2005-03-04
SuSE SUSE-SA:2005:011 2005-02-28
Ubuntu USN-86-1 2005-02-28

Comments (none posted)

cyrus-imapd: buffer overflows

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

Comments (none posted)

devhelp: buffer overflow

Package(s):devhelp CVE #(s):
Created:March 24, 2005 Updated:March 30, 2005
Description: A buffer overflow in the Mozilla GIF file handling code (used by devhelp) can be exploited by specially crafted images, causing arbitrary code execution.
Alerts:
Fedora FEDORA-2005-251 2005-03-25
Fedora FEDORA-2005-252 2005-03-23

Comments (none posted)

dhcp: format string vulnerability

Package(s):dhcp CVE #(s):CAN-2004-1006
Created:November 4, 2004 Updated:July 13, 2005
Description: Dhcp has a format string vulnerability in the log functions of dhcp 2.x that may be exploited via a malicious DNS server.
Alerts:
Fedora-Legacy FLSA:152835 2005-07-10
Red Hat RHSA-2005:212-01 2005-04-12
Debian DSA-584-1 2004-11-04

Comments (none posted)

emacs21: format string vulnerability in "movemail"

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

Comments (none posted)

enscript: arbitrary code execution

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

Comments (none posted)

epiphany: buffer overflow

Package(s):epiphany CVE #(s):
Created:March 24, 2005 Updated:March 30, 2005
Description: A buffer overflow in the Mozilla GIF file handling code can be exploited by specially crafted images, causing arbitrary code execution.
Alerts:
Fedora FEDORA-2005-253 2005-03-25
Fedora FEDORA-2005-254 2005-03-23

Comments (none posted)

evolution: arbitrary code execution

Package(s):evolution CVE #(s):CAN-2005-0102
Created:January 24, 2005 Updated:May 19, 2005
Description: Max Vozeler discovered an integer overflow in camel-lock-helper. A user-supplied length value was not validated, so that a value of -1 caused a buffer allocation of 0 bytes; this buffer was then filled by an arbitrary amount of user-supplied data. A local attacker or a malicious POP3 server could exploit this to execute arbitrary code with root privileges (because camel-lock-helper is installed as setuid root).
Alerts:
Red Hat RHSA-2005:238-01 2005-05-19
Conectiva CLA-2005:925 2005-02-16
Debian DSA-673-1 2005-02-10
Mandrake MDKSA-2005:024 2005-01-27
Gentoo 200501-35 2005-01-24
Ubuntu USN-69-1 2005-01-24

Comments (1 posted)

evolution: message crash vulnerability

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

Comments (none posted)

evolution: buffer overflow

Package(s):evolution CVE #(s):
Created:March 24, 2005 Updated:March 30, 2005
Description: A buffer overflow in the Mozilla GIF file handling code (used by evolution) can be exploited by specially crafted images, causing arbitrary code execution.
Alerts:
Fedora FEDORA-2005-255 2005-03-23

Comments (none posted)

f2c: insecure temp files

Package(s):f2c CVE #(s):CAN-2005-0017 CAN-2005-0018
Created:January 27, 2005 Updated:April 20, 2005
Description: The f2c fortran to C translator has a vulnerability due to insecure opening of temporary files. A local attacker can use this to launch a symlink attack.
Alerts:
Debian DSA-661-2 2005-04-20
Gentoo 200501-43 2005-01-30
Debian DSA-661-1 2005-01-27

Comments (none posted)

Foomatic: Arbitrary command execution in foomatic-rip

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

Comments (none posted)

gaim: client freezes

Package(s):gaim CVE #(s):CAN-2005-0472 CAN-2005-0473
Created:February 22, 2005 Updated:April 27, 2005
Description: The Gaim client freezes when receiving certain invalid messages and crashes when receiving specific malformed HTML. See this Secunia Advisory for additional information.
Alerts:
Debian DSA-716-1 2005-04-27
Ubuntu USN-85-1 2005-02-25
Fedora FEDORA-2005-160 2005-02-21
Fedora FEDORA-2005-159 2005-02-21

Comments (none posted)

gtk-pixbuf, gtk2: denial of service

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

Comments (none posted)

gettext: Insecure temporary file handling

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

Comments (1 posted)

gftp: missing input sanitizing

Package(s):gftp CVE #(s):CAN-2005-0372 CAN-2004-1376
Created:February 17, 2005 Updated:July 13, 2005
Description: gftp has a directory traversal vulnerability. A remote server could use specially crafted filenames to overwrite local files.
Alerts:
Fedora-Legacy FLSA:152908 2005-07-10
Red Hat RHSA-2005:410-01 2005-06-13
Fedora FEDORA-2005-310 2005-04-07
Fedora FEDORA-2005-309 2005-04-07
Mandrake MDKSA-2005:050 2005-03-04
Gentoo 200502-27 2005-02-19
SuSE SUSE-SR:2005:005 2005-02-18
Debian DSA-686-1 2005-02-17

Comments (none posted)

ghostscript: symlink vulnerabilities

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

Comments (none posted)

glibc: Information leak with LD_DEBUG

Package(s):glibc CVE #(s):CAN-2004-1453
Created:August 17, 2004 Updated:May 26, 2005
Description: Silvio Cesare discovered a potential information leak in glibc. It allows LD_DEBUG on SUID binaries where it should not be allowed. This has various security implications, which may be used to gain confidential information. An attacker can gain the list of symbols a SUID application uses and their locations and can then use a trojaned library taking precedence over those symbols to gain information or perform further exploitation.
Alerts:
Red Hat RHSA-2005:256-01 2005-05-18
Gentoo 200408-16 2004-08-16

Comments (1 posted)

glibc: tempfile vulnerability in catchsegv script

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

Comments (none posted)

gnupg: information leak

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

Comments (none posted)

grip: buffer overflow

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

Comments (none posted)

groff: insecure temporary directory

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

Comments (none posted)

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)

htdig: cross site scripting

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

Comments (none posted)

imagemagick: format string vulnerability

Package(s):imagemagick CVE #(s):CAN-2005-0397
Created:March 3, 2005 Updated:April 4, 2005
Description: The ImageMagick file name handling code has a format string vulnerability. Specially crafted file names can be used to crash ImageMagick and possibly execute arbitrary code.
Alerts:
Mandrake MDKSA-2005:065 2005-04-01
Debian DSA-702-1 2005-04-01
Fedora FEDORA-2005-235 2005-03-30
Fedora FEDORA-2005-234 2005-03-30
SuSE SUSE-SA:2005:017 2005-03-23
Red Hat RHSA-2005:320-01 2005-03-23
Gentoo 200503-11 2005-03-06
Ubuntu USN-90-1 2005-03-03

Comments (none posted)

imap: buffer overflow in c-client

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

Comments (none posted)

imlib2: buffer overflows

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

Comments (none posted)

IPsec-Tools: denial of service

Package(s):ipsec-tools setkey racoon CVE #(s):CAN-2005-0398
Created:March 14, 2005 Updated:April 5, 2005
Description: The IPsec-Tools package is used to build other programs such as setkey and racoon. There is a potential denial of service vulnerability when parsing ISAKMP headers in racoon.
Alerts:
Ubuntu USN-107-1 2005-04-05
SuSE SUSE-SA:2005:020 2005-03-31
Mandrake MDKSA-2005:062 2005-03-31
Gentoo 200503-33 2005-03-25
Red Hat RHSA-2005:232-01 2005-03-23
Fedora FEDORA-2005-217 2005-03-14
Fedora FEDORA-2005-216 2005-03-14

Comments (none posted)

kdelibs: unsanitzied input

Package(s):kdelibs CVE #(s):CAN-2004-1165
Created:January 10, 2005 Updated:July 19, 2005
Description: Thiago Macieira discovered a vulnerability in the kioslave library, which is part of kdelibs, which allows a remote attacker to execute arbitrary FTP commands via an ftp:// URL that contains an URL-encoded newline before the FTP command.
Alerts:
Fedora-Legacy FLSA:152769 2005-07-15
Mandrake MDKSA-2005:045 2005-02-17
Red Hat RHSA-2005:065-01 2005-02-15
Red Hat RHSA-2005:009-01 2005-02-10
Fedora FEDORA-2005-064 2005-01-25
Fedora FEDORA-2005-063 2005-01-25
Gentoo 200501-18 2005-01-11
Debian DSA-631-1 2005-01-10

Comments (none posted)

kdelibs: dcopserver vulnerability

Package(s):kdelibs CVE #(s):CAN-2005-0396 CAN-2005-0237 CAN-2005-0365
Created:March 17, 2005 Updated:May 17, 2005
Description: The KDE Desktop Communication Protocol daemon (dcopserver) is vulnerable to lockup by a local user, leading to a denial of service.
Alerts:
Conectiva CLA-2005:953 2005-05-17
SuSE SUSE-SA:2005:022 2005-04-11
Red Hat RHSA-2005:307-01 2005-04-06
Fedora FEDORA-2005-245 2005-03-23
Fedora FEDORA-2005-244 2005-03-23
Red Hat RHSA-2005:325-01 2005-03-23
Gentoo 200503-22 2005-03-19
Mandrake MDKSA-2005:058 2005-03-16

Comments (none posted)

kernel: multiple vulnerabilities

Package(s):kernel CVE #(s):CAN-2005-0449 CAN-2005-0209 CAN-2005-0529 CAN-2005-0530 CAN-2005-0532 CAN-2005-0384 CAN-2005-0210 CAN-2005-0504 CAN-2005-0003
Created:March 24, 2005 Updated:May 31, 2006
Description: A number of vulnerabilities have been found in the Linux kernel, including a PPP-related denial of service problem, an integer overflow in the epoll() code, memory corruption in the ELF loader, and exploitable overflows in the ISO9660 code.
Alerts:
Debian DSA-1082-1 2006-05-29
Debian DSA-1069-1 2006-05-20
Debian DSA-1070-1 2006-05-21
Debian DSA-1067-1 2006-05-20
Conectiva CLA-2005:945 2005-03-31
Fedora FEDORA-2005-262 2005-03-28
SuSE SUSE-SA:2005:018 2005-03-24

Comments (none posted)

libdbi-perl: insecure temporary file

Package(s):libdbi-perl CVE #(s):CAN-2005-0077