LWN.net Logo

LWN.net Weekly Edition for May 3, 2007

A tale of two release cycles

As most LWN readers will be aware, the 2.6.21 kernel has been released. The 2.6.21 process was relatively difficult, mostly as a result of the core timer changes which went in. These changes were necessary - they are the path forward to a kernel which works better on all types of hardware - but they caused some significant delays in the release of the final 2.6.21 kernel. Even at release time, this kernel was known not to be perfect; there were a dozen or so known regressions which had not been fixed.

The reason we know about these regressions is that Adrian Bunk has been tracking them for the past few development cycles. Mr. Bunk has let it be known that he will not be doing this tracking for future kernels. From his point of view, the fact that the kernel was released with known regressions means that the time spent tracking them was wasted. Why bother doing that work if it doesn't result in the tracked problems being fixed?

What Mr. Bunk would like to see is a longer stabilization period:

There is a conflict between Linus trying to release kernels every 2 months and releasing with few regressions. Trying to avoid regressions might in the worst case result in an -rc12 and 4 months between releases. If the focus is on avoiding regressions this has to be accepted.

Here is where one finds the fundamental point of disagreement. The kernel used to operate with long release cycles, but the "stable" kernels which emerged at the end were not particularly well known for being regression free. Downloading and running an early 2.4.x kernel should prove that point to anybody who doubts it.

The reasoning behind the current development process (and the timing of the 2.6.21 release in particular), as stated by Linus Torvalds is:

Regressions _increase_ with longer release cycles. They don't get fewer.. This simply *does*not*work*. You might want it to work, but it's against human psychology. People get bored, and start wasting their time discussing esoteric scheduler issues which weren't regressions at all.

In other words, holding up a release for a small number of known bugs prevents a much larger set of fixes, updates, new features, additional support, and so on from getting to the user base. Meanwhile, the developers do not stop developing, and the pile of code to be merged in the next cycle just gets larger, leading to even more problems when the floodgates open. It would appear that most kernel developers believe that it is better to leave the final problems for the stable tree and let the development process move on.

The 2.6.21 experience might encourage a few small changes; in particular, Linus has suggested that truly disruptive changes should maybe have an entire development cycle to themselves. As a whole, however, the process is not seen as being broken and is unlikely to see any big "fixes."

For an entirely different example, let us examine the process leading to the Emacs 22 release. Projects managed by the Free Software Foundation have never been known for rapid or timely releases, but, even with the right expectations in place, this Emacs cycle has been a long one: the previous major release (version 21) was announced in October, 2001. In those days, LWN was talking about the 2.4.11 kernel, incorporation of patented technology into W3C standards, the upcoming Mozilla 1.0 release, and the Gartner Group's characterization of Linux as a convenient way for companies to negotiate lower prices from proprietary software vendors. Things have moved on a bit since those days, but Emacs 21 is still the current version.

The new Emacs major release was recently scheduled for April 23, but it has not yet happened. There is one significant issue in the way of this release: it seems that there is a cloud over some of the code which was merged into the Emacs Python editing mode. Until this code is either cleared or removed, releasing Emacs would not be a particularly good idea. It also appears that the wisdom of shipping a game called "Tetris" has been questioned anew and is being run past the FSF's lawyers.

Before this issue came up, however, the natives in the Emacs development community were getting a little restless. Richard Stallman may not do a great deal of software development anymore, but he is still heavily involved in the Emacs process. Emacs is still his baby. And this baby, it seems, will not be released until it is free of known bugs. This approach is distressing for Emacs developers who would like to make a release and get more than five years' worth of development work out to the user community.

This message From Emacs hacker Chong Yidong is worth quoting at length:

To be fair, I think RMS' style of maintaining software, with long release cycles and insistence on fixing all reported bugs, was probably a good approach back in the 80s, when there was only a handful of users with access to email to report bugs.

Nowadays, of course, the increase in the number of users with email and the fact that Emacs CVS is now publicly available means that there will always be a constant trickle of bug reports giving you something to fix. Insisting---as RMS does---on fixing all reported bugs, even those that are not serious and not regressions, now means that you will probably never make a release.

It has often been said that "perfect" is the enemy of "good." That saying does seem to hold true when applied to software release cycles; an attempt to create a truly perfect release results in no release at all. Users do not get the code, which does not seem like a "perfect" outcome to them.

Mr. Yidong has another observation which mirrors what was said in the kernel discussion:

There is also a positive feedback loop: RMS' style for maintaining Emacs drives away valuable contributors who feel their effects will never be rewarded with a release (and a release is, after all, the only reward you get from contributing to Emacs).

It's not only users who get frustrated by long development cycles; the developers, too, find them tiresome. Projects which adopt shorter, time-based release cycles rarely seem to regret the change. It appears that there really are advantages to getting the code out there in a released form. Your editor is not taking bets on when Emacs might move to a bounded-time release process, though.

Comments (36 posted)

The embedded Linux nightmare - an epilogue

May 1, 2007

This article was contributed by Thomas Gleixner

The usage of proprietary operating systems in companies over the last 25 years has established a set of constraints which are not really applicable to the way open source development - and Linux kernel development in particular - works. My keynote talk ("The Embedded Linux Nightmare") at the Embedded Linux Conference in Santa Clara addressed this mismatch; it created quite a bit of discussion. I would like to follow up and add some more details and thoughts about this topic.

Why follow mainline development?

The version cycles of proprietary operating systems are completely different than the Linux kernel version cycles. Proprietary operating systems have release cycles measured in years; the Linux kernel, instead, is released about every three months with major updates to the functionality and feature set and changes to internal APIs. This fundamental difference is one of the hardest problems to handle for the corporate mindset.

One can easily understand that companies try to apply the same mechanisms which they applied to their formerly- (and still-) used operating systems in order not to change procedures of development and quality assurance. Jamming Linux into these existing procedures seems to be somehow possible, but it is one of the main contributions to the embedded Linux nightmare, preventing companies from tapping the full potential of open source software. Embedded distribution vendors are equally guilty as they try to keep up the illusion of the one-to-one replacement of proprietary operating systems by creating heavily patched Linux Kernel variants.

It is undisputed that kernel versions need to be frozen for product releases, but it can be observed that those freezes are typically done very early in the development cycle and are kept across multiple versions of the product or product family. These freezes, which are the vain attempt to keep the existing procedures alive, lead to backports of features found in newer kernel versions and create monsters which put the companies into the isolated situation of maintaining their unique fork forever, without the help of the community.

I was asked recently whether a backport of the new upcoming wireless network stack into Linux 2.6.10 would be possible. Of course it is possible, but it does not make any sense at all. Backporting such a feature requires backporting other changes in the network stack and many other places of the kernel as well, making it even more complex to verify and maintain. Each update and bug fix in the mainline code needs to be tracked and carefully considered for backporting. Bugfixes which are made in the backported code are unlikely to apply to later versions and are therefore useless for others.

During another discussion about backporting a large feature into an old kernel, I asked why a company would want to do that. The answer was: the quality assurance procedures would require a full verification when the kernel would be upgraded to a newer version. This is ridiculous. What level of quality does such a process assure when there is a difference between moving to a newer kernel version and patching a heavy feature set into an old kernel? The risk of adding subtle breakage into the old kernel with a backport is orders of magnitudes higher than the risk of breakage from an up-to-date kernel release. Up-to-date kernels go through the community quality assurance process; unique forks, instead, are excluded from this free of charge service.

There is a fundamental difference between adding a feature to a proprietary operating system and backporting a feature from a new Linux kernel to an old one. A new feature of a proprietary operating system is written for exactly the version which is enhanced by the feature. A new feature for the Linux kernel is written for the newest version of the kernel and builds upon the enhancements and features which have been developed between the release of the old kernel and now. New Linux kernel features are simply not designed for backporting.

I only can discourage companies from even thinking about such things. The time spent doing backports and the maintenance of the resulting unique kernel fork is better spent on adjusting the internal development and quality assurance procedures to the way in which the Linux kernel development process is done. Otherwise it would be just another great example of a useless waste of resources.

Benefits to companies from working with the kernel process

There are a lot of arguments made why mainlining code is not practicable in the embedded world. One of the most commonly used arguments is that embedded projects are one-shot developments and therefore mainlining is useless and without value. My experience in the embedded area tells me, instead, that most projects are built on previous projects and a lot of products are part of a product series with different feature sets. Most special-function semiconductors are parts of a product family and development happens on top of existing parts. The IP blocks, which are the base of most ASIC designs, are reused all over the place, so the code to support those building blocks can be reused as well.

The one-shot project argument is a strawman for me. The real reasons are the reluctance to give up control over a piece of code, the already discussed usage of ancient kernel versions, the work which is related to mainlining, and to some degree the fear of the unknown.

The reluctance to give up control over code is an understandable but nevertheless misplaced relic of the proprietary closed source model. Companies have to open up their modifications and extensions to the Linux kernel and other open source software anyway when they ship their product. So handing it over to the community in the first place should be just a small step.

Of course mainlining of code is a fair amount of work and it forces changes to the way how the development in companies works. There are companies which have been through this change and they confirm that there are benefits in it.

According to Andrew Morton, we change approximately 9000 lines of kernel code per day, every day. That means that we touch something in the range of 3000 lines of code, when we take comments, blank lines and simple reshuffling into account. The COCOMO estimate of the value of 3000 lines of code is about $100k. So we have a total investment of $36 million per year which flows into the kernel development. That's with all the relevant factors set to 1. Taking David Wheelers factors into account would cause this figure to go up to $127 million. This estimate does not take other efforts around the kernel into account, like the test farms, the testing and documentation projects and the immense number of (in)voluntary testers and bug reporters who "staff" the QA department of the kernel.

Some companies realize the value of this huge cooperative investment and add their own stake for the long term benefit. We recently had a customer who asked if we could write a driver for an yet-unsupported flash chip. His second question was whether we would try to feed it back into the mainline. He was even willing to pay for the extra hours, simply because he understood that it was helpful for him. This is a small company with less than 100 employees and a definitely limited budget. But they cannot afford the waste of maintaining even such small drivers out of tree. I have seen such efforts of smaller companies quite often in recent years and I really hold those folks in great respect.

Bigger players in the embedded market apparently have budgets large enough to ignore the benefits of working with the community and just concentrate on their private forks. This is unwise with respect to their own investments, not to talk about the total disrespect for the values which are given them by the community.

It is understandable that companies want to open the code for new products very late in the product cycle, but there are ways to get this done nevertheless. One is to work through a community proxy, such as consultants or service providers, who know how kernel development works and can help to make the code ready for inclusion from the very beginning.

The value of community-style development is in avoiding mistakes and the benefit of the experience of other developers. Posting an early draft of code for comment can be helpful for both code quality and development time. The largest benefit of mainlining code is the automatic updates when the kernel internal interfaces are changed and the enhancements and bugfixes which are provided by users of the code. Mainlining code allows easy kernel upgrades later in a product cycle when new features and technologies have to be added. This is also true for security fixes, which are eventually hard to backport.

Benefits to developers

I personally know developers who are not interested in working in the open at all for a very dubious reason: as long as they have control over their own private kernel fork, they are the undisputed experts for code on which their company depends. If forced to hand over their code to the community, they fear losing control and making themselves easier to replace. Of course this is a short-sighted view, but it happens. These developers miss the beneficial effect of gaining knowledge and expertise by working together with others.

One of my own employees went through a ten-round review-update-review cycle which ended with satisfaction for both sides:

	> Other than that I am very happy with this latest version. Great
	> job!  Thanks for your patience, I know it's always a bit
	> frustrating when your code works well enough for yourself and you
	> are still told to make many changes before it is acceptable
	> upstream.

	Well, I really appreciate good code quality. If this is the price,
	I'm willing to pay it. Actually, I thank you for helping me so
	much.

Over the course of this review cycle the code quality of the driver improved; it also led to some general discussion about the affected sensors framework and the improvement of it on the fly. The developer improved his skills and he got an improved insight into the framework with the result that his next project will definitely have a much shorter review cycle. This growth makes him far more valuable for the company than having him as the internal expert for some "well it works for us" driver.

The framework maintainer benefited as well, as he needed to look at the requirements of the new device and adjust the framework to handle it in a generic way. This phenomenon is completely consistent with Greg Kroah-Hartman's statement in his OLS keynote last year:

We want more drivers, no matter how "obscure", because it allows us to see patterns in the code, and realize how we could do things better.

All of the above leads to a single conclusion: working with the kernel development community is worth the costs it imposes in changes to internal processes. Companies which work with the kernel developers get a kernel which better meets their needs, is far more stable and secure, and which will be maintained and improved by the community far into the future. Those companies which choose to stay outside the process, instead, miss many of the benefits of millions of dollars' worth of work being contributed by others. Developers are able to take advantage of working with a group of smart people with a strong dedication to code quality and long-term maintainability.

It can be a winning situation for everybody involved - far better than perpetuating the embedded Linux nightmare.

Comments (33 posted)

A tale of two dead companies

Once upon a time, there was a software firm named AppForge, Inc. This company sold development tools for mobile platforms, allowing others to create applications which would run on a number of different devices. These were all proprietary tools for proprietary systems, and so wouldn't normally be of interest on LWN. What has happened with AppForge turns out to be worth a look, however.

It seems that AppForge went bankrupt back in March. So there will be no support for AppForge's products going into the future. But, as it turns out, it's worse than that:

Crossfire licensing typically works by validating a serial number against AppForge's server before installation on any new device. Since AppForge went dark, end users have been unable to provision new devices with software that they thought they owned.

It does not take much searching to find forums full of AppForge customers looking for ways to activate the product licenses they had already bought and paid for. In the mean time, their businesses have come to a halt because a core component of their products has suddenly been pulled out from underneath them.

Adding the usual sanctimonious LWN sermon on the risks of using proprietary software seems superfluous here.

More recently, Progeny Linux Systems ceased operations. This company, which had based its hopes on a specialized, configurable version of the Debian distribution aimed at appliance vendors, had been quiet for some time. Founder Ian Murdock headed off to greener pastures (first the Free Standards Group, then Sun) a while back. Press releases and other communications had dried up. The last repository update posted to the mailing lists happened in October, 2006. The DCC Alliance, a Progeny-led effort to create a standard distribution based on Debian, has had no news to offer since 2005. Now the company's web site states that Progeny ceased operations on April 30.

Progeny seems to have lost out in the market to others with more interesting offerings. Ubuntu declined to join the DCC Alliance for what looks like a clear business reason: Ubuntu is becoming the standardized, cleaned-up version of Debian that DCC wanted to be, and with predictable releases as a bonus. Companies like rPath appear to be finding more success at signing up customers in the appliance market. With no wind in its sails, Progeny was unable to bring in the revenue to keep going.

Progeny's customers, too, will lose the support offered by the company. There will be no distribution upgrades, no security fixes, and nobody to answer questions. This loss will clearly be a concern for any affected customers, but those customers are in a very different position from those who were dependent on AppForge tools. Since they were using a free platform, nothing prevents Progeny's customers from continuing to ship their products. These customers can also readily find companies (or consultants) who can continue to support the Progeny platform, should they need that support. The cost may be unwelcome, but the core truth remains: any Progeny customer which has a need to keep the Progeny platform secure or fix bugs in it will be able to do so.

The nature of the technology market is such that the failure of product lines and entire companies is not an uncommon event. When one company depends on another company's products, the risk of this sort of failure must be kept in mind. That risk is far lower, however, when companies base their products on free software.

(Thanks to Scott Preece for bringing the AppForge situation to our awareness).

Comments (5 posted)

Page editor: Jonathan Corbet

Security

IPv6 source routing: history repeats itself

May 2, 2007

This article was contributed by Jake Edge.

A feature slipped into the IPv6 protocol because of political, rather than technical, considerations and has, perhaps unsurprisingly, come back to haunt the IPv6 working group. It also caused a recent Linux kernel release that disables a particular routing 'feature' of IPv6 by default; it also allows administrators to enable it if they wish. Even a cursory look at the IPv6 routing header type 0 (RH0) might lead one to remember a similar IPv4 feature that eventually fell out of favor: source routing.

Mostly used as a diagnostic tool, source routing allows a packet to specify the route, as a list of IP addresses, that should be used to reply to it. This capability was abused in IP address spoofing attacks by enabling the spoofer to see responses that normally would be routed directly to the spoofed address. Because of this (and other source routing abuses), most routers are configured to drop packets that have source routing information and have been since the mid-90s. Ten years or more would seem to be enough time to ensure that the 'next generation' of IP (IPv6 was originally billed as 'IPng') missed out on repeating these mistakes of the past; sadly, that is not the case.

IPv6 introduces something called a 'routing header' into the protocol as part of the extension headers, which are meant to replace the IPv4 options field. Three types of routing header are defined, one of which is unused (type 1) and another which is only used by Mobile IPv6 implementations (type 2). It is the third (type 0) that is the cause of all the current uproar. Also known as RH0 headers, they contain a list of hosts to be 'visited' on the way back to the source address. It should be noted that the IPv6 RFC mentions IPv4 source routing as part of the description of RH0.

A presentation (PDF) at the CanSecWest 2007 conference outlined several vulnerabilities with RH0 and that led to the kernel changes in 2.6.20.9. The biggest vulnerability appears to be in the amplification effect that can be caused by listing hosts multiple times in the 'route'. One packet can then cause what are essentially multiple copies of itself to be sent back and forth between the hosts listed in the header. This can be used to multiply the traffic in a denial of service attack as well as masking the source of the attack. The BSD operating systems have also released new versions to address this problem and the router vendors will not be far behind. (It should be noted that a bug in the original Linux fix was addressed in 2.6.20.10 and because 2.6.21 had been released in the interim, in 2.6.21.1 as well.)

Given that the problems with source routing are known and that the parallels between RH0 and source routing are also known, how did we get to the point where this kind of feature was added into IPv6? The Internet Engineering Task Force (IETF) IPv6 working group is discussing some of that in a thread on their mailing list. A memorable rant by Theo de Raadt seems to indicate that 'academics' in the process forced the inclusion of RH0 through politics. Paul Vixie commiserates and indicates that he sees it as more evidence that the IETF is largely irrelevant in setting internet standards today. In addition, no one responding to the thread seems to be able to come up with a particularly valid use case for the feature.

This would appear to be a classic case of ignoring the past and being doomed to repeat it, but it would also appear that the politics of standards bodies played a role. We certainly are not well served when political considerations trump security (or, really, any technical) considerations. Hopefully this will be yet another object lesson for those of a political bent.

Comments (19 posted)

New vulnerabilities

capi4k-utils: buffer overflow

Package(s):capi4k-utils CVE #(s):CVE-2007-1217
Created:April 30, 2007 Updated:May 2, 2007
Description: The bufprint() function in capi4k-utils fails to properly check boundaries of data coming from CAPI packets. A local attacker could possibly escalate privileges or cause a Denial of Service by sending a crafted CAPI packet.
Alerts:
Gentoo 200704-23 2007-04-27

Comments (none posted)

gimp: arbitrary code execution

Package(s):gimp CVE #(s):CVE-2007-2356
Created:May 1, 2007 Updated:June 11, 2007
Description: From this Secunia advisory: "Marsu has discovered a vulnerability in Gimp, which can be exploited by malicious people to compromise a user's system. The vulnerability is caused due to an error within the "set_color_table()" function in plug-ins/common/sunras.c. This can be exploited to cause a stack-based buffer overflow by e.g. tricking a user into opening a specially crafted .RAS file."
Alerts:
Debian DSA-1301-1 2007-06-09
Ubuntu USN-467-1 2007-05-31
Mandriva MDKSA-2007:108 2007-05-22
Red Hat RHSA-2007:0343-01 2007-05-21
SuSE SUSE-SR:2007:011 2007-05-16
Gentoo 200705-08 2007-05-07
rPath rPSA-2007-0090-1 2007-05-03
Foresight FLEA-2007-0015-1 2007-04-30

Comments (3 posted)

kernel: denial of service

Package(s):kernel CVE #(s):CVE-2007-1861 CVE-2007-2242
Created:May 1, 2007 Updated:February 8, 2008
Description: The netlink protocol has an infinite recursion bug that allows users to cause a kernel crash. Also the IPv6 protocol allows remote attackers to cause a denial of service via crafted IPv6 type 0 route headers (IPV6_RTHDR_TYPE_0) that create network amplification between two routers.
Alerts:
SuSE SUSE-SA:2008:006 2008-02-07
Ubuntu USN-508-1 2007-08-31
Mandriva MDKSA-2007:171 2007-08-28
Ubuntu USN-489-1 2007-07-19
Ubuntu USN-486-1 2007-07-17
SuSE SUSE-SA:2007:051 2007-09-06
Mandriva MDKSA-2007:216 2007-11-13
Red Hat RHSA-2007:0347-01 2007-05-16
Debian DSA-1289-1 2007-05-13
Foresight FLEA-2007-0016-1 2007-05-08
rPath rPSA-2007-0084-1 2007-05-01
Fedora FEDORA-2007-483 2007-05-01
Fedora FEDORA-2007-482 2007-05-01

Comments (none posted)

net-snmp: denial of service

Package(s):net-snmp CVE #(s):CVE-2005-4837
Created:May 2, 2007 Updated:May 4, 2007
Description: From the Ubuntu advisory: the SNMP service did not correctly handle TCP disconnects. Remote subagents could cause a denial of service if they dropped a connection at a specific time. Note that this vulnerability has been known since 2005.
Alerts:
rPath rPSA-2007-0089-1 2007-05-03
Ubuntu USN-456-1 2007-05-02

Comments (none posted)

qemu: multiple vulnerabilities

Package(s):qemu CVE #(s):CVE-2007-1320 CVE-2007-1321 CVE-2007-1322 CVE-2007-1323 CVE-2007-1366
Created:May 1, 2007 Updated:August 8, 2008
Description: Several vulnerabilities have been discovered in the QEMU processor emulator, which may lead to the execution of arbitrary code or denial of service.
Alerts:
Mandriva MDVSA-2008:162 2008-08-07
Fedora FEDORA-2008-4386 2008-05-28
Fedora FEDORA-2008-4604 2008-05-28
Fedora FEDORA-2007-713 2007-10-08
Debian DSA-1384-1 2007-10-05
Fedora FEDORA-2007-2270 2007-10-03
Red Hat RHSA-2007:0323-01 2007-10-02
Debian-Testing DTSA-38-1 2007-05-26
Debian DSA-1284-1 2007-05-01

Comments (none posted)

quagga: denial of service

Package(s):quagga CVE #(s):CVE-2007-1995
Created:May 2, 2007 Updated:July 3, 2007
Description: A malicious peer can cause the quagga routing daemon to crash by sending a properly crafted BGP packet.
Alerts:
Fedora FEDORA-2007-0838 2007-07-03
Fedora FEDORA-2007-525 2007-06-06
Red Hat RHSA-2007:0389-01 2007-05-30
Ubuntu USN-461-1 2007-05-17
OpenPKG OpenPKG-SA-2007.015 2007-05-18
Debian DSA-1293-1 2007-05-17
Mandriva MDKSA-2007:096 2007-05-02
Gentoo 200705-05 2007-05-02

Comments (none posted)

tomcat: directory traversal

Package(s):tomcat CVE #(s):CVE-2007-0450
Created:May 2, 2007 Updated:February 27, 2008
Description: Versions of tomcat prior to 5.5.22 do not properly filter filename separator characters, enabling information disclosure attacks.
Alerts:
SuSE SUSE-SR:2007:015 2007-08-03
Mandriva MDKSA-2007:241 2007-12-10
Red Hat RHSA-2007:0360-01 2007-05-24
Red Hat RHSA-2007:0328-01 2007-05-24
Fedora FEDORA-2007-514 2007-05-21
Red Hat RHSA-2007:0326-01 2007-05-21
Red Hat RHSA-2007:0327-01 2007-05-14
Gentoo 200705-03 2007-05-01

Comments (none posted)

util-linux: access restriction bypass

Package(s):util-linux CVE #(s):CVE-2006-7108
Created:May 2, 2007 Updated:June 15, 2007
Description: From the Red Hat advisory: a flaw was found in the way the login process handled logins which did not require authentication. Certain processes which conduct their own authentication could allow a remote user to bypass intended access policies which would normally be enforced by the login process.
Alerts:
rPath rPSA-2007-0126-1 2007-06-15
Mandriva MDKSA-2007:111 2007-06-04
Red Hat RHSA-2007:0235-02 2007-05-01

Comments (none posted)

vim: arbitrary shell code execution

Package(s):vim CVE #(s):CVE-2007-2438
Created:April 30, 2007 Updated:May 25, 2007
Description: Vim allows two functions, feedkeys() and writefile(), to be used in the sandbox. Functions executed via modelines in files being edited are verified by the sandbox; a user who is coerced into opening a specially-crafted file could cause the system to execute arbitrary shell code supplied by the attacker.
Alerts:
SuSE SUSE-SR:2007:012 2007-05-25
Ubuntu USN-463-1 2007-05-22
Mandriva MDKSA-2007:101 2007-05-09
Red Hat RHSA-2007:0346-01 2007-05-09
Fedora FEDORA-2007-492 2007-05-07
Foresight FLEA-2007-0014-1 2007-04-30

Comments (1 posted)

wordpress: another pile of vulnerabilities

Package(s):wordpress CVE #(s):CVE-2007-1622 CVE-2007-1893 CVE-2007-1894 CVE-2007-1897
Created:May 2, 2007 Updated:July 6, 2007
Description: Wordpress suffers from another set of vulnerabilities including a couple of cross-site scripting problems, an access restrictions bypass issue, and an SQL injection vulnerability.
Alerts:
Fedora FEDORA-2007-0894 2007-07-05
Debian DSA-1285-1 2007-05-01

Comments (none posted)

xscreensaver: password check bypass

Package(s):xscreensaver CVE #(s):CVE-2007-1859
Created:May 2, 2007 Updated:June 13, 2007
Description: On a system which uses a remote directory service for passwords, a local attacker can crash xscreensaver by disrupting network connectivity, thus bypassing the password check and gaining access to the system.
Alerts:
Ubuntu USN-474-1 2007-06-12
Gentoo 200705-14 2007-05-13
SuSE SUSE-SR:2007:009 2007-05-04
rPath rPSA-2007-0088-1 2007-05-03
Mandriva MDKSA-2007:097 2007-05-02
Red Hat RHSA-2007:0322-01 2007-05-02

Comments (none posted)

Updated vulnerabilities

3proxy: buffer overflow

Package(s):3proxy CVE #(s):CVE-2007-2031
Created:April 23, 2007 Updated:April 25, 2007
Description: The 3proxy development team reported a buffer overflow in the logurl() function when processing overly long requests. A remote attacker could send a specially crafted transparent request to the proxy, resulting in the execution of arbitrary code with privileges of the user running 3proxy. This has been fixed in the 3proxy 0.5.3i bugfix release.
Alerts:
Gentoo 200704-17 2007-04-22

Comments (none posted)

aircrack-ng: remote execution of arbitrary code

Package(s):aircrack-ng CVE #(s):CVE-2007-2057
Created:April 23, 2007 Updated:May 23, 2007
Description: Jonathan So reported that the airodump-ng module does not correctly check the size of 802.11 authentication packets before copying them into a buffer. A remote attacker could trigger a stack-based buffer overflow by sending a specially crafted 802.11 authentication packet to a user running airodump-ng with the -w (--write) option. This could lead to the remote execution of arbitrary code with the permissions of the user running airodump-ng, which is typically the root user.
Alerts:
Debian-Testing DTSA-35-1 2007-05-16
Debian DSA-1280-1 2007-04-24
Gentoo 200704-16 2007-04-22

Comments (none posted)

apache: cross-site scripting

Package(s):apache CVE #(s):CVE-2006-3918
Created:August 9, 2006 Updated:April 4, 2008
Description: From the Red Hat advisory: "A bug was found in Apache where an invalid Expect header sent to the server was returned to the user in an unescaped error message. This could allow an attacker to perform a cross-site scripting attack if a victim was tricked into connecting to a site and sending a carefully crafted Expect header."
Alerts:
SuSE SUSE-SA:2008:021 2008-04-04
Ubuntu USN-575-1 2008-02-04
SuSE SUSE-SA:2006:051 2006-09-08
Debian DSA-1167-1 2005-09-04
Red Hat RHSA-2006:0619-01 2006-08-10
Red Hat RHSA-2006:0618-01 2006-08-08

Comments (none posted)

Asterisk: two SIP denial of service vulnerabilities

Package(s):Asterisk CVE #(s):CVE-2007-1561 CVE-2007-1594
Created:April 3, 2007 Updated:August 27, 2007
Description: The Madynes research team at INRIA has discovered that Asterisk contains a null pointer dereferencing error in the SIP channel when handling INVITE messages. Furthermore qwerty1979 discovered that Asterisk 1.2.x fails to properly handle SIP responses with return code 0. A remote attacker could cause an Asterisk server listening for SIP messages to crash by sending a specially crafted SIP message or answering with a 0 return code.
Alerts:
Debian DSA-1358-1 2007-08-26
SuSE SUSE-SA:2007:034 2007-06-06
Gentoo 200704-01 2007-04-02

Comments (none posted)

blender: user-assisted remote execution of arbitrary code

Package(s):blender CVE #(s):CVE-2007-1253
Created:April 24, 2007 Updated:April 25, 2007
Description: Stefan Cornelius of Secunia Research discovered an insecure use of the "eval()" function in kmz_ImportWithMesh.py. A remote attacker could entice a user to open a specially crafted Blender file (.kmz or .kml), resulting in the execution of arbitrary Python code with the privileges of the user running Blender.
Alerts:
Gentoo 200704-19 2007-04-23

Comments (1 posted)

bluez-utils: hidd vulnerability

Package(s):bluez-utils CVE #(s):CVE-2006-6899
Created:January 16, 2007 Updated:May 14, 2007
Description: hidd in BlueZ (bluez-utils) before 2.25 allows remote attackers to obtain control of the Mouse and Keyboard Human Interface Device (HID) via a certain configuration of two HID (PSM) endpoints, operating as a server, aka HidAttack.
Alerts:
Red Hat RHSA-2007:0065-01 2007-05-14
Ubuntu USN-413-1 2007-01-24
Mandriva MDKSA-2007:014 2006-01-15

Comments (none posted)

bugzilla: multiple vulnerabilities

Package(s):bugzilla CVE #(s):CVE-2006-5453 CVE-2006-5454 CVE-2006-5455
Created:November 10, 2006 Updated:August 28, 2007
Description: Bugzilla has the following vulnerabilities:

Input data passed to various fields is not properly sanitized before being passed back to users.

Users can gain unauthorized access to read attachment descriptions while using diff mode.

HTTP GET and HTTP POST requests can be used to perform unauthorized actions due to improper verification.

Input that is passed to showdependencygraph.cgi is not properly sanitized before being returned to users.

Alerts:
Debian DSA-1208-1 2006-11-11
Gentoo 200611-04 2006-11-09

Comments (none posted)

busybox: insecure password generation

Package(s):busybox CVE #(s):CVE-2006-1058
Created:May 5, 2006 Updated:May 2, 2007
Description: The BusyBox 1.1.1 passwd command does not use a proper salt when generating passwords. This would create an instance where a brute force attack could take very little time.
Alerts:
Red Hat RHSA-2007:0244-02 2007-05-01
Fedora FEDORA-2006-511 2006-05-04
Fedora FEDORA-2006-510 2006-05-04

Comments (2 posted)

clamav: several vulnerabilities

Package(s):clamav CVE #(s):CVE-2007-1745 CVE-2007-1997
Created:April 20, 2007 Updated:May 9, 2007
Description: The chm_decompress_stream function in libclamav/chmunpack.c leaks file descriptors, which has unknown impact and attack vectors involving a crafted CHM file. (CVE-2007-1745)

Integer signedness error in the (1) cab_unstore and (2) cab_extract functions in libclamav/cab.c might allow remote attackers to execute arbitrary code via a crafted CHM file that contains a negative integer, which passes a signed comparison and leads to a stack-based buffer overflow. (CVE-2007-1997)

Alerts:
Mandriva MDKSA-2007:098 2007-05-08
Debian DSA-1281-1 2007-04-25
Gentoo 200704-21 2007-04-24
Trustix TSLSA-2007-0013 2007-04-20
SuSE SUSE-SA:2007:026 2007-04-20

Comments (none posted)

Courier-IMAP: remote execution of arbitrary code

Package(s):courier-imap CVE #(s):
Created:April 23, 2007 Updated:April 25, 2007
Description: CJ Kucera has discovered that some Courier-IMAP scripts don't properly handle the XMAILDIR variable, allowing for shell command injection. A remote attacker could send specially crafted login credentials to a Courier-IMAP server instance, possibly leading to remote code execution with root privileges.
Alerts:
Gentoo 200704-18 2007-04-22

Comments (2 posted)

cpio: arbitrary code execution

Package(s):cpio CVE #(s):CVE-2005-4268
Created:January 2, 2006 Updated:May 8, 2007
Description: Richard Harms discovered that cpio did not sufficiently validate file properties when creating archives. Files with e. g. a very large size caused a buffer overflow. By tricking a user or an automatic backup system into putting a specially crafted file into a cpio archive, a local attacker could probably exploit this to execute arbitrary code with the privileges of the target user (which is likely root in an automatic backup system).
Alerts:
rPath rPSA-2007-0094-1 2007-05-07
Red Hat RHSA-2007:0245-02 2007-05-01
Ubuntu USN-234-1 2006-01-02

Comments (none posted)

cups: denial of service

Package(s):cups CVE #(s):CVE-2007-0720
Created:March 26, 2007 Updated:February 7, 2008
Description: Previous versions of the cups package could be forced to hang via a client "partially negotiating" an ssl connection. In this state, cups would not allow other connections to be made, a denial of service.
Alerts:
Mandriva MDVSA-2008:036 2007-02-06
Mandriva MDKSA-2007:086 2007-04-16
Red Hat RHSA-2007:0123-01 2007-04-16
Gentoo 200703-28 2007-03-31
Foresight FLEA-2007-0003-1 2007-03-25

Comments (none posted)

Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service

Package(s):cyrus-sasl CVE #(s):CVE-2006-1721
Created:April 21, 2006 Updated:September 4, 2007
Description: Cyrus-SASL contains an unspecified vulnerability in the DIGEST-MD5 process that could lead to a Denial of Service. An attacker could possibly exploit this vulnerability by sending specially crafted data stream to the Cyrus-SASL server, resulting in a Denial of Service even if the attacker is not able to authenticate.
Alerts:
Red Hat RHSA-2007:0878-01 2007-09-04
Red Hat RHSA-2007:0795-01 2007-09-04
SuSE SUSE-SA:2006:025 2006-05-05
Fedora FEDORA-2006-515 2006-05-04
Debian DSA-1042-1 2006-04-25
Mandriva MDKSA-2006:073 2006-04-24
Ubuntu USN-272-1 2006-04-24
Gentoo 200604-09 2006-04-21

Comments (none posted)

dovecot: index cache file handling error

Package(s):dovecot CVE #(s):CVE-2006-5973
Created:November 29, 2006 Updated:May 8, 2007
Description: The dovecot IMAP server has an error in its index cache file handling code which could be exploited by an authenticated user to execute arbitrary code. Only servers with the (non-default) mmap_disable=yes option setting are vulnerable.
Alerts:
Fedora FEDORA-2006-1504 2006-12-27
Fedora FEDORA-2006-1396 2006-12-18
rPath rPSA-2006-0220-1 2006-11-30
Ubuntu USN-387-1 2006-11-28

Comments (none posted)

evolution: format string error

Package(s):evolution CVE #(s):CVE-2007-1002
Created:March 27, 2007 Updated:February 27, 2008
Description: A format string error in the "write_html()" function in calendar/gui/ e-cal-component-memo-preview.c when displaying a memo's categories can potentially be exploited to execute arbitrary code via a specially crafted shared memo containing format specifiers.
Alerts:
SuSE SUSE-SR:2007:015 2007-08-03
Gentoo 200706-02 2007-06-06
Red Hat RHSA-2007:0158-01 2007-05-03
Foresight FLEA-2007-0010-1 2007-04-05
Fedora FEDORA-2007-404 2007-04-04
Fedora FEDORA-2007-393 2007-04-04
Mandriva MDKSA-2007:070 2007-03-27

Comments (1 posted)

fail2ban: denial of service

Package(s):fail2ban CVE #(s):CVE-2006-6302
Created:February 16, 2007 Updated:July 30, 2007
Description: fail2ban 0.7.4 and earlier does not properly parse sshd logs file, which allows remote attackers to add arbitrary hosts to the /etc/hosts.deny file and cause a denial of service by adding arbitrary IP addresses to the sshd log file, as demonstrated by logging in to ssh using a login name containing certain strings with an IP address.
Alerts:
Gentoo 200702-05 2007-02-16

Comments (3 posted)

ffmpeg: buffer overflows

Package(s):ffmpeg CVE #(s):CVE-2006-4799 CVE-2006-4800
Created:September 14, 2006 Updated:May 28, 2007
Description: the AVI processing code in FFmpeg has a number of buffer overflow vulnerabilities. If an attacker can trick a user into loading a specially crafted crafted AVI, arbitrary code can be executed with the user's privileges.
Alerts:
Gentoo 200609-09 2006-09-13

Comments (2 posted)

file: denial of service

Package(s):file CVE #(s):CVE-2007-2026
Created:April 18, 2007 Updated:May 25, 2007
Description: The gnu regular expression code in file 4.20 allows context-dependent attackers to cause a denial of service (CPU consumption) via a crafted document with a large number of line feed characters, which is not well handled by OS/2 REXX regular expressions that use wildcards, as originally reported for AMaViS.
Alerts:
rPath rPSA-2007-0109-1 2007-05-24
Foresight FLEA-2007-0022-1 2007-05-24
Gentoo 200704-13 2007-04-17

Comments (none posted)

file: arbitrary code execution

Package(s):file CVE #(s):CVE-2007-1536
Created:March 22, 2007 Updated:May 30, 2007
Description: The "file" utility incorrectly checks the allocated heap memory size. If a remote attacker can trick a user into looking at specially crafted files with file, arbitrary code can be executed with the user's privileges.
Alerts:
Red Hat RHSA-2007:0391-01 2007-05-30
Slackware SSA:2007-093-01 2007-04-04
Gentoo 200703-26 2007-03-30
Debian DSA-1274-1 2007-04-02
Fedora FEDORA-2007-391 2007-03-30
Red Hat RHSA-2007:0124-01 2007-03-23
Mandriva MDKSA-2007:067 2007-03-22
rPath rPSA-2007-0059-1 2007-03-22
Ubuntu USN-439-1 2007-03-21

Comments (1 posted)

firefox: FTP PASV port-scanning

Package(s):firefox seamonkey CVE #(s):CVE-2007-1562
Created:March 23, 2007 Updated:June 4, 2007
Description: According to this advisory, the FTP protocol includes the PASV (passive) command which is used by Firefox to request an alternate data port. The specification of the FTP protocol allows the server response to include an alternate server address as well, although this is rarely used in practice.
Alerts:
Fedora FEDORA-2007-0066 2007-06-01
Fedora FEDORA-2007-0050 2007-06-01
Fedora FEDORA-2007-0001 2007-06-04
rPath rPSA-2007-0112-1 2007-05-31
Foresight FLEA-2007-0023-1 2007-05-31
Fedora FEDORA-2007-0001 2007-06-01
Fedora FEDORA-2007-0001 2007-06-01
Fedora FEDORA-2007-0001 2007-06-01
Fedora FEDORA-2007-554 2007-05-31
Fedora FEDORA-2007-549 2007-05-31
Fedora FEDORA-2007-549 2007-05-31
Fedora FEDORA-2007-549 2007-05-31
Fedora FEDORA-2007-549 2007-05-31
Red Hat RHSA-2007:0402-01 2007-05-30
Red Hat RHSA-2007:0400-01 2007-05-30
rPath rPSA-2007-0062-1 2007-04-04
Ubuntu USN-443-1 2007-03-27
Foresight FLEA-2007-0001-1 2007-03-22

Comments (1 posted)

freeradius: memory leak

Package(s):freeradius CVE #(s):CVE-2007-2028
Created:April 17, 2007 Updated:May 15, 2007
Description: A memory leak in freeRADIUS 1.1.5 and earlier allows remote attackers to cause a denial of service (memory consumption) via a large number of EAP-TTLS tunnel connections using malformed Diameter format attributes, which causes the authentication request to be rejected but does not reclaim VALUE_PAIR data structures.
Alerts:
Fedora FEDORA-2007-499 2007-05-14
Red Hat RHSA-2007:0338-01 2007-05-10
Gentoo 200704-14 2007-04-17
Mandriva MDKSA-2007:085 2007-04-16

Comments (none posted)

freetype: integer overflows

Package(s):freetype CVE #(s):CVE-2006-0747 CVE-2006-1861 CVE-2006-2493 CVE-2006-2661 CVE-2006-3467
Created:June 8, 2006 Updated:October 10, 2007
Description: The FreeType library has several integer overflow vulnerabilities. If a user can be tricked into installing a specially crafted font file, arbitrary code can be executed with the privilege of the user.
Alerts:
Gentoo 200710-09 2007-10-09
Debian DSA-1178-1 2006-09-16
Ubuntu USN-341-1 2006-09-06
Gentoo 200609-04 2006-09-06
rPath rPSA-2006-0157-1 2006-08-25
Mandriva MDKSA-2006:148 2006-08-24
Red Hat RHSA-2006:0635-01 2006-08-21
Red Hat RHSA-2006:0634-01 2006-08-21
Fedora FEDORA-2006-912 2006-08-14
SuSE SUSE-SA:2006:045 2006-08-01
OpenPKG OpenPKG-SA-2006.017 2006-07-28
Ubuntu USN-324-1 2006-07-27
Slackware SSA:2006-207-02 2006-07-27
Mandriva MDKSA-2006:129 2006-07-20
Gentoo 200607-02 2006-07-09
SuSE SUSE-SA:2006:037 2006-06-27
Mandriva MDKSA-2006:099-1 2006-06-13
Mandriva MDKSA-2006:099 2006-06-12
rPath rPSA-2006-0100-1 2006-06-12
Debian DSA-1095-1 2006-06-10
Ubuntu USN-291-1 2006-06-08

Comments (none posted)

gcc: file overwrite vulnerability

Package(s):gcc CVE #(s):CVE-2006-3619
Created:September 6, 2006 Updated:March 14, 2008
Description: The fastjar utility found in the GNU compiler collection does not perform adequate file path checking, allowing the creation or overwriting of files outside of the current directory tree.
Alerts:
Mandriva MDVSA-2008:066 2007-03-13
Red Hat RHSA-2007:0473-01 2007-06-11
Red Hat RHSA-2007:0220-02 2007-05-01
Debian DSA-1170-1 2006-09-06

Comments (none posted)

gd: buffer overflow

Package(s):gd CVE #(s):CVE-2007-0455
Created:February 7, 2007 Updated:February 28, 2008
Description: The gd graphics library contains a buffer overflow which could enable a remote attacker to execute arbitrary code. Note that various other packages include code from gd and could also be vulnerable.
Alerts:
Red Hat RHSA-2008:0146-01 2008-02-28
Ubuntu USN-473-1 2007-06-11
OpenPKG OpenPKG-SA-2007.016 2007-05-18
Trustix TSLSA-2007-0007 2007-02-13
Fedora FEDORA-2007-150 2007-02-12
Fedora FEDORA-2007-149 2007-02-12
rPath rPSA-2007-0028-1 2007-02-08
Mandriva MDKSA-2007:038 2006-02-06
Mandriva MDKSA-2007:036 2006-02-06
Mandriva MDKSA-2007:035 2006-02-06

Comments (2 posted)

gdb: buffer overflow

Package(s):gdb CVE #(s):CVE-2006-4146
Created:September 15, 2006 Updated:June 12, 2007
Description: A buffer overflow in dwarfread.c and dwarf2read.c debugging code in GNU Debugger (GDB) 6.5 allows user-assisted attackers, or restricted users, to execute arbitrary code via a crafted file with a location block (DW_FORM_block) that contains a large number of operations.
Alerts:
Red Hat RHSA-2007:0469-01 2007-06-11
Red Hat RHSA-2007:0229-02 2007-05-01
Ubuntu USN-356-1 2006-10-02
Fedora FEDORA-2006-975 2006-09-14

Comments (none posted)

gdm: improper file permissions

Package(s):gdm CVE #(s):CVE-2006-1057
Created:April 19, 2006 Updated:May 2, 2007
Description: The .ICEauthority file may be created with the wrong ownership and permissions; gdm 2.14.2 fixes the problem.
Alerts:
Red Hat RHSA-2007:0286-02 2007-05-01
Mandriva MDKSA-2006:083 2006-05-09
Ubuntu USN-278-1 2006-05-03
Debian DSA-1040-1 2006-04-24
Fedora FEDORA-2006-338 2006-04-19

Comments (none posted)

gzip: multiple vulnerabilities

Package(s):gzip CVE #(s):CVE-2006-4334 CVE-2006-4335 CVE-2006-4336 CVE-2006-4337 CVE-2006-4338
Created:September 19, 2006 Updated:June 1, 2007
Description: Tavis Ormandy of the Google Security Team discovered two denial of service flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to hang or crash.

Tavis Ormandy of the Google Security Team discovered several code execution flaws in the way gzip expanded archive files. If a victim expanded a specially crafted archive, it could cause the gzip executable to crash or execute arbitrary code.

Alerts:
Fedora FEDORA-2007-557 2007-05-31
Gentoo 200611-24 2006-11-28
Fedora-Legacy FLSA:211760 2006-11-13
Fedora FEDORA-2006-989 2006-10-10
SuSE SUSE-SA:2006:056 2006-09-26
Gentoo 200609-13 2006-09-23
Trustix TSLSA-2006-0052 2006-09-22
Mandriva MDKSA-2006:167 2006-09-20
Slackware SSA:2006-262-01 2006-09-20
OpenPKG OpenPKG-SA-2006.020 2006-09-20
Debian DSA-1181-1 2006-09-19
rPath rPSA-2006-0170-1 2006-09-19
Ubuntu USN-349-1 2006-09-19
Red Hat RHSA-2006:0667-01 2006-09-19

Comments (1 posted)

horde-kronolith: local file inclusion

Package(s):horde-kronolith CVE #(s):CVE-2006-6175
Created:January 17, 2007 Updated:March 7, 2008
Description: Kronolith contains a mistake in lib/FBView.php where a raw, unfiltered string is used instead of a sanitized string to view local files. An authenticated attacker could craft an HTTP GET request that uses directory traversal techniques to execute any file on the web server as PHP code, which could allow information disclosure or arbitrary code execution with the rights of the user running the PHP application (usually the webserver user).
Alerts:
Gentoo 200701-11 2007-01-16

Comments (none posted)

ImageMagick: integer overflows

Package(s):imagemagick CVE #(s):CVE-2007-1797
Created:April 4, 2007 Updated:April 17, 2008
Description: Multiple integer overflows in ImageMagick before 6.3.3-5 allow remote attackers to execute arbitrary code via (1) a crafted DCM image, which results in a heap-based overflow in the ReadDCMImage function, or (2) the (a) colors or (b) comments field in a crafted XWD image, which results in a heap-based overflow in the ReadXWDImage function, different issues than CVE-2007-1667.
Alerts:
Red Hat RHSA-2008:0165-01 2008-04-16
Red Hat RHSA-2008:0145-01 2008-04-16
Fedora FEDORA-2007-1340 2007-07-30
Mandriva MDKSA-2007:147 2007-07-20
Ubuntu USN-481-1 2007-07-10
Gentoo 200705-13 2007-05-10
Fedora FEDORA-2007-414 2007-04-17
Fedora FEDORA-2007-413 2007-04-05
rPath rPSA-2007-0064-1 2007-04-04

Comments (none posted)

imlib2: arbitrary code execution

Package(s):imlib2 CVE #(s):CVE-2006-4806 CVE-2006-4807 CVE-2006-4808 CVE-2006-4809
Created:November 6, 2006 Updated:August 13, 2007
Description: M. Joonas Pihlaja discovered that imlib2 did not sufficiently verify the validity of ARGB, JPG, LBM, PNG, PNM, TGA, and TIFF images. If a user were tricked into viewing or processing a specially crafted image with an application that uses imlib2, the flaws could be exploited to execute arbitrary code with the user's privileges.
Alerts:
Mandriva MDKSA-2007:156 2007-08-10
Gentoo 200612-20 2006-12-20
Fedora FEDORA-EXTRAS-2006-004 2006-11-09
Mandriva MDKSA-2006:198-1 2006-11-06
Mandriva MDKSA-2006:198 2006-11-06
Ubuntu USN-376-2 2006-11-06
Ubuntu USN-376-1 2006-11-03

Comments (none posted)

ipsec-tools: denial of service

Package(s):ipsec-tools CVE #(s):CVE-2007-1841
Created:April 10, 2007 Updated:August 28, 2007
Description: A flaw was discovered in the IPSec key exchange server "racoon". Remote attackers could send a specially crafted packet and disrupt established IPSec tunnels, leading to a denial of service.
Alerts:
Fedora FEDORA-2007-665 2007-08-27
Debian DSA-1299-1 2007-06-07
Red Hat RHSA-2007:0342-01 2007-05-17
Gentoo 200705-09 2007-05-08
SuSE SUSE-SR:2007:008 2007-04-27
Mandriva MDKSA-2007:084 2007-04-16
Ubuntu USN-450-1 2007-04-09

Comments (none posted)

java: multiple vulnerabilities

Package(s):java CVE #(s):CVE-2006-4339 CVE-2006-4790 CVE-2006-6731 CVE-2006-6736 CVE-2006-6737 CVE-2006-6745
Created:January 18, 2007 Updated:June 8, 2007
Description: java has multiple vulnerabilities, these include: an RSA exponent padding attack vulnerability, two vulnerabilities which allow untrusted applets to access data in other applets, vulnerabilities that involve applets gaining privileges due to serialization bugs in the JRE and buffer overflows in the java image handling routines that can give attackers read/write/execute capabilities for local files.
Alerts:
Gentoo 200705-20 2007-05-26
Red Hat RHSA-2007:0073-01 2007-02-09
Red Hat RHSA-2007:0072-01 2007-02-08
Red Hat RHSA-2007:0062-02 2007-02-07
Gentoo 200701-15 2007-01-22
SuSE SUSE-SA:2007:010 2007-01-18

Comments (1 posted)

kdelibs: cross-site scripting

Package(s):kdelibs konqeror CVE #(s):CVE-2007-0537
Created:February 5, 2007 Updated:August 13, 2007
Description: Konqueror 3.5.5 does not properly parse HTML comments, which allows remote attackers to conduct cross-site scripting (XSS) attacks and bypass some XSS protection schemes by embedding certain HTML tags within a comment, a related issue to CVE-2007-0478.
Alerts:
Mandriva MDKSA-2007:157 2007-08-10
Gentoo 200703-10 2007-03-10
rPath rPSA-2007-0052-1 2007-03-07
Ubuntu USN-420-1 2007-02-06
Mandriva MDKSA-2007:031 2007-02-02

Comments (none posted)

kernel: denial of service

Package(s):kernel CVE #(s):CVE-2007-1357
Created:April 16, 2007 Updated:November 14, 2007
Description: The atalk_sum_skb function in AppleTalk for Linux kernel 2.6.x before 2.6.21, and possibly 2.4.x, allows remote attackers to cause a denial of service (crash) via an AppleTalk frame that is shorter than the specified length, which triggers a BUG_ON call when an attempt is made to perform a checksum.