Sponsored link
Serve your customers, not your servers, with VERIO Linux VPS. Full-access test-drive here.
| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
LWN.net Weekly Edition for November 18, 2004
Fedora: an example of community involvement
The Fedora Project, after more than one year, has not become a "community" project by any means. It is centrally controlled, and many crucial decisions seem to come from some sort of smoke-filled room in Raleigh. The long-promised publicly-available source code repository ("intended to be available by the release of Fedora Core 2") is nowhere to be seen, the governing councils have not been created, and the project's technical leader is rarely seen on the mailing lists. In many ways, Fedora looks more like an open beta testing program run by Red Hat than a true community project.That said, a couple of things are worth pointing out. One is that the Fedora Project has clearly succeeded in creating, evolving, and supporting a top-quality distribution with bleeding-edge software and predictable release cycles. The other is that, in some ways at least, Fedora's interaction with its user community is yielding clear benefits. Simple testing and filing of bugs is probably the biggest part of it. Beyond that, however, the project does seem to listen to its users and be influenced by what they say, even if Red Hat does have the final word on important decisions. And, at times, members of the community can truly help to make the distribution better.
As an example, consider this challenge recently posted by Owen Taylor. He noted that a Linux system still takes a couple of minutes to boot, which is too much:
Owen asked for help from the community in figuring out what was slowing
down the boot process. That help was all of two days in coming, when Ziga
![[Boot chart]](http://www.klika.si/ziga/bootchart/bootchart.png)
Mahkovec posted some results. He had
modified the kernel boot process to instrument what was going on, and
produced a
pretty chart showing where the time was being spent. One immediate
culprit stands out from the chart: the rhgb process. That is the
"Red Hat Graphical Boot" utility, which does no actual work; it simply
watches over the initialization process and shows its progress on the
console. It's not something which should be occupying a large part of the
time required to boot. But it was responsible for over 1/3 of the time
required to boot a Fedora system.
As it turns out, rhgb gets into a loop where it simply spins in the CPU, slowing down everything else. A bugzilla entry was created, the bug was fixed, and life improved. Ziga made a new chart showing an improved situation - and a boot time of 46 seconds.
Fedora users may have even more to cheer soon. Ziga made yet another chart which follows the process through a GNOME graphical login. One of the big culprits there is the obnoxious, throbbing Red Hat Network update applet. It turns out that Red Hat developers detest that applet too and tend to kill it on their systems. Now that it has been shown to be a major factor in making users wait to be able to do anything with their systems, it may just get some needed attention.
Meanwhile, the bottom line is this: Fedora may not be a community project like, for example, Debian. But neither is it a sealed product from a corporate cathedral. Fedora is clearly a better distribution as a result of its interactions with its users. Hopefully, someday, Red Hat will follow through on its promises (source code management server, community governing council) and bring the community further into the process. Fedora is blessed with a community of users who want to help; it shouldn't let the desire for corporate control keep them from being part of the project.
Book review: SELinux
![[Cover]](/images/ns/selinux-book.png)
The NSA's Security Enhanced Linux project is controversial. To some, it is
the future of Linux computing; with SELinux, many of our current security
nightmares will cease to trouble us. To others, SELinux is a morass of
complexity which is difficult, if not impossible, to understand well enough
to get any sense of whether it is configured in a secure way or not. This
whole situation is not helped by the current state of SELinux
documentation. There are few resources out there for people wanting to
know how SELinux works, how to manage it, or even whether to try to adopt
it.
There is, however, a new book on the shelves: SELinux: NSA's Open Source Security Enhanced Linux, by Bill McCarty. At 254 pages, this book is relatively thin by contemporary technical book standards. It offers a finicky editor a fair number of things to grumble about, but those grumbles should not overshadow the important point: this book is an important step in the process of bringing SELinux to a level where software developers and system administrators can make some sense of it.
Let's get the grumbles out of the way first. The book shows some signs of having been written and produced in a hurry; as a result, it has more than the desirable number of typos and contradictions. It talks alternately about the runcon and run_con command, for example. It claims that "domain" and "type" are interchangeable terms for the same concept, then says "Recall that a general type is one not related to a specific domain." Readers are directed to the kernel source (said to be found in the deprecated /usr/src/linux directory) to associate a device name with a major number when a quick look at /proc/devices would do the job. We are told "SELinux is generally stable and free of trouble," which would, by itself, strain many readers' ability to suspend disbelief, but then the author suggests avoiding using X on SELinux systems, or, if that is impractical, learning to love GNOME to avoid problems with KDE. And so on. The reader finds these things often enough that they become a significant distraction from the real content of the book.
The book starts with a general overview of SELinux, including the obligatory set of scary statistics on the frequency of attacks. A number of approaches to security are looked at, including, of course, mandatory access control schemes. The second chapter is a quick overview of SELinux, where the important concepts (roles, types) are introduced. The two mechanisms which can cause type/domain transitions (file creation and exec() calls) are introduced. Everything is fairly vague at this point, but the discussion is enough to let some of the important ideas sink in.
The author then takes a diversion into how to install SELinux on several distributions, with special attention paid to Debian, Fedora, and Gentoo. This information will certainly be useful to some readers, but (especially in the future) most readers are likely to find SELinux on their systems already. If you are trying to figure out how to make your Fedora system work, Chapter 3 will just be a distraction. (Incidentally, the book covers Fedora Core 2).
Chapter 4 gets into high-level SELinux administration: turning enforcement on and off, installing new policies, dealing with file labels, etc. There is useful stuff here, but the presentation leaves a little to be desired. For example, loading policies requires the use of the newrole command (which will remind old-time Unix users of the obnoxious newgrp command made necessary by certain vendors' kernels which could only handle membership in one group at a time). Policy loading is covered before newrole, however, leading to a fair number of forward references in the text. Reordering the discussion would have made things easier to follow. That said, this chapter provides a reasonable start for administrators trying to find their way around their SELinux systems.
The next three chapters form the technical core of the book, with detailed descriptions of the language used to define role-based access control and type enforcement rules. There's lots of cute railroad diagrams for those who want pictures, and a detailed examination of how the policy for the ping utility is put together. If you are trying to make sense of the policy files that come with your SELinux distribution, these chapters provide the information that you will need. The book then winds down with a chapter on ancillary policy statements and one giving some pointers on how to carry out simple policy changes.
A topic which is missing entirely is how one might design a security policy from the beginning. The implicit assumption is that few, if any, readers will have such ambitious goals; they will, instead, be trying to make things work with the policy shipped by their distributor. That is probably a good assumption; designing an SELinux security policy from the beginning is not for the faint of heart. Still, as we'll explore in a companion article, there may be reasons for wanting to take on such a project.
Meanwhile, if SELinux takes off the way many people clearly expect it to, there will be a strong need for developers and administrators who truly understand how it works. For that reason, your editor predicts that this book will become required reading for a lot of people. For all of our quibbles, we must say that Mr. McCarty has succeeded in shedding some much-needed light into a dark and difficult corner of Linux systems administration.
Solaris 10
As the release date for Solaris 10 nears, Sun Microsystems has been powering up the hype machine accordingly, and trying to convince the world that Solaris 10 is the best OS ever. According to Sun, Solaris 10 will offer more than 600 new, "breakthrough" features. That's a few too many for this article, but we'll take a look at some of the most notable features that are slated for inclusion in Solaris 10.
One interesting feature is Solaris Dynamic Tracing (DTrace). DTrace is a system for troubleshooting problems in real time, by allowing admins and developers to observe and tune system behavior.
Another feature that Sun is touting is Solaris Containers. Containers are essentially virtual machines, which allow an admin to create "private execution environments" on a machine, to isolate applications from one another and essentially create multiple hosts on a single server. This is, of course, nothing new to Linux users who have already discovered User-Mode Linux or any of the other virtualization solutions available for Linux.
Solaris 10 also comes with a new file system, ZFS. This is a 128-bit file system that offers far greater capacity than the current UFS, and 64-bit checksums for data stored on the filesystem. ZFS works with "virtual storage pools," and is supposed to greatly reduce the difficulty of administering file systems. According to Sun's website:
The TCP/IP stack gets special attention in Solaris 10. Sun has rewritten its networking stack, and claims that delivers a 50-percent or better speed boost for "many networked applications." Solaris 10 also includes built-in kernel support for the Stream Control Transmission Protocol (SCTP) and Session Initiation Protocol (SIP) in an effort to make Solaris 10 attractive for VoIP deployments.
Despite the slew of new features, Sun has fallen into an unenviable position with Solaris: Having to go to customers with a emulation technology to run their existing programs. When Linux was the underdog, much was made of the ability to run Solaris and other *nix binaries on Linux, as a way to allow companies to move their existing applications to Linux. With Solaris 10, Sun is promising a Linux Application Environment (LAE) to run Linux binaries on Solaris 10 on x86 systems.
Pricing for Solaris 10 has changed as well. Sun is, literally, giving it away. Sun is giving a "right-to-use" (RTU) license and security updates for Solaris 10 at no charge. Customers who want to utilize support or have access to all Solaris 10 updates and fixes start at $120 per year for a 1-4 CPU machine.
The company is also making much of binary compatibility with Solaris 10 -- promising customers that older Solaris applications will be able to run unchanged on Solaris 10.
Perhaps the most interesting feature for Solaris 10 is the licensing, if we ever find out what it is. According to Sun's executives, Solaris 10 will be open source. However, the company has not yet announced a license, whether the license will be OSI-compliant or exactly how much of Solaris 10 will be under this open source license. Further, assuming that the license is open enough to encourage contribution, Sun hasn't set out any information about accepting contributions from the community.
A more ominous possibility exists: Sun could release its code under a license which is not only non-free, but which creates problems for any free software developers who look at that code. If Sun's fortunes continue to decline, there is a definite possibility that the company could look to litigation for its salvation. This possibility should be kept in mind by anybody who contemplates going anywhere near the Solaris code.
Obviously, Sun is trying to regain some of the ground that it has lost with Linux. It seems unlikely, at least to this writer, that Sun will make much headway in regaining lost customers with Solaris 10. While Solaris 10 offers some undeniably useful and interesting features, it's fairly obvious that most organizations do not choose operating systems on features alone.
Sun lacks the momentum that Linux has gained over the past few years. Companies that have already invested time and money into migrating to Linux are less likely to spend additional time and money evaluating Solaris 10 if Linux is meeting their needs. Companies that are already utilizing Linux are unlikely to even bother evaluating Solaris 10 unless Linux does not meet their needs.
Also, Sun's LAE won't be available in the first release of Solaris 10, meaning that organizations that are willing to consider migrating from Linux to Solaris will have to hold off until Sun releases LAE in an update to Solaris 10. This puts Sun even farther in the hole with regards to losing customers to Linux.
If the Solaris 10 license is GPL-compatible, many of Solaris 10's interesting features will no doubt find their way into Linux. It seems unlikely that Sun would choose that path. On the other hand, if Sun chooses a less friendly open source license, it will have a tough time creating a community that will drive Solaris development or adoption in the same way that the GPL has driven Linux. Either way, Sun seems set to lose with its open source ploy.
Solaris 10 looks to be a fine operating system, but it may very well be too little and too late to help Sun regain its market share.
Poland gets cold feet on Europatents
A press release has gone out stating that the Polish government has officially decided that it is unable to support software patents in Europe.
Needless to say, this is an important development. Software patents will probably not be defeated quite this easily, but this is an important step in that direction.
LWN comes early next week
Next week's LWN Weekly Edition will be published on November 24 - one day earlier than usual - so that the LWN staff can prepare themselves for the annual Thanksgiving feast. We'll return to the usual schedule on December 2.
Page editor: Jonathan Corbet
Security
Civilizing SELinux
On its face, SELinux offers a number of attractive capabilities. It enables a Linux system to be partitioned into lots of little realms ("domains" or "types") with fine-grained control over the capabilities of each realm. For example, the named DNS server can be empowered to bind to the DNS ports (but no others), write to its log and cache files (but no others), and read from its configuration files (but from nowhere else). It can read random numbers, but cannot access any other device files. And so on. The end result is that, even if named falls to a remote code exploit, there is very little that exploit can actually do. A vulnerability which, on a current Linux system, could lead to a full system compromise is limited to a denial of service problem, or, at worst, the provision of bogus DNS information.This promise is worth something. Currently, any sort of compromise of any daemon on the system has a good chance of being escalated to full control of the system itself. SELinux cannot prevent security holes in server processes, but it does have the potential to strictly limit the damage which can be done by exploiting those holes. SELinux could be the mechanism which turns Linux into the most secure widely-used operating system on the planet.
The only problem is that getting there could be a challenge, and, along the way, we risk turning Linux into a system we no longer wish to use.
Like all good kernel code, SELinux does not, itself, contain a security policy. That policy, instead, is defined by the system administrator and loaded from user space. Defining that policy, however, is not the easiest thing to do. The book SELinux: NSA's Open Source Security Enhanced Linux, just reviewed by LWN, notes that a typical set of policy files contains some 250,000 lines of code. More to the point:
As an aside, all of this code is written in a language which, as of this writing, probably has no more than a few dozen expert authors. So a couple of questions come immediately to mind: how is it possible for anybody to truly understand a system's security policy, and how can that policy be shown to be correct? Complexity and obscurity are enemies of security, and SELinux has large amounts of both.
There are complications. Installing a new program on a full-blown SELinux system required updating the security policy. There has been talk of a day when applications are routinely shipped with SELinux policy files, just like they currently contain makefiles. But that talk assumes that large numbers of application developers will learn the SELinux policy language well enough to write a secure policy for their code. It assumes that system administrators will understand those files well enough to decide whether they are safe to install. In an SELinux world, malicious policy files may become a required part of any self-respecting trojan horse; vigilance will be required.
Perhaps the biggest problem, though, is the assumption that a single policy file will fit into the security policies running on systems worldwide. If everybody ends up with a single, uniform security policy derived from the SELinux sample policy, that assumption might hold. But how can a single security policy make sense for all situations? The sheer difficulty of creating a radically different policy will likely keep experimentation to a minimum, but there will inevitably be pressure for different policies for different situations. In the future, we may see new offshoot distributions which differ mainly in their SELinux policies. Divergent security policies will be good for user choice, and the diversity may be good for the security of the net in general. But they will make it hard to write a portable application policy file.
SELinux depends on "labels" applied to almost all files on the system. Those labels define the type(s) of the files, and, thus, who can access them, and in which way. These labels are also a crucial part of the domain system which allows the isolation of specific daemons and utilities. Maintaining the integrity of these labels proves to be a challenge, however. Consider this warning from the SELinux book:
Relabeling files is something every SELinux administrator needs to know how to do. The Fedora boot process checks for labeling problems, and, when they are found, it automatically relabels things. Relabeling is a fact of life in the SELinux world.
It turns out that the proper labels are stored in the SELinux policy; what's on the files themselves can be thought of as a sort of cached version. In other words, SELinux has imposed a new file permissions scheme which is maintained outside of the kernel. If the files are manipulated by non-aware applications, or by way of a non-SELinux kernel, those permissions will become unsynchronized. Applications installed by the administrator will have labeling problems of their own.
The end result is that SELinux could lead to systems which are too complex to administer, which have a single security policy created by the distributor, and which are highly resistant to the installation of software not provided by the distributor - or to changes in general. That is not a world which most of us would like to live in; we should think carefully before we run too quickly in that direction.
Of course, that is a worst case scenario, and the Linux community is unlikely to let things get that bad. Some steps have already been taken in the right direction. The Fedora Project's decision to fall back to a "targeted" mode, where SELinux only applies to certain system daemons, is a good start. The targeted mode reduces the complexity of the security policy and makes experimentation easier. Fedora has also introduced "policy booleans" to the mix. These booleans are runtime variables which provide (relatively) high-level control over the system's security policy. Booleans in Fedora Core 3 control whether Apache can run CGI programs or read home directories, whether yellow pages can be used, and more.
The booleans point in an important direction. Perhaps part of the real problem with SELinux is that policies must be written in the equivalent of assembly language. Most programmers do not want to worry about individual register assignments, and most system administrators would rather not deal with domain transitions and access vectors. If, in some future day, a system's security policy can be specified with, at most, a few hundred lines of high-level declarations, that policy may just be manageable. If that can be done, SELinux might just be the answer to a lot of our security worries.
(See also: this just-released, beta Fedora document which describes what is involved in using SELinux to control Apache).
Security news
EFF on mailing lists and spam
The EFF has put out a a lengthy document describing its concerns with contemporary spam filtering techniques. "Blind keyword or phrase blocking is the determination that messages will not be delivered because they contain specific words or phrases. This method is imprecise and unnecessary, especially now that more sophisticated tools are available. Moreover, it can be used to block messages for political reasons. In short, there's no defensible reason to label email as spam based solely on keywords or phrases."
freedesktop.org site compromised
Visitors to freedesktop.org will see a message noting that the site was compromised on November 15. The project does not believe that any code on the site was tampered with, but they are rebuilding everything from the beginning anyway. More info will come as we get it. (Thanks to Thomas Kirby).
New vulnerabilities
BNC: Buffer overflow vulnerability
| Package(s): | bnc | CVE #(s): | |||||||
| Created: | November 16, 2004 | Updated: | December 1, 2004 | ||||||
| Description: | Leon Juranic discovered that BNC fails to do proper bounds checking when checking server response. An attacker could exploit this to cause a Denial of Service and potentially execute arbitrary code with the permissions of the user running BNC. | ||||||||
| Alerts: |
| ||||||||
bogofilter: denial of service
| Package(s): | bogofilter | CVE #(s): | CAN-2004-1007 | |||
| Created: | November 17, 2004 | Updated: | November 17, 2004 | |||
| Description: | Bogofilter has a vulnerability in its quoted-printable processing code which may be exploited to crash the process. | |||||
| Alerts: |
| |||||
ez-ipupdate: format string vulnerability
| Package(s): | ez-ipupdate | CVE #(s): | CAN-2004-0980 | |||||||||
| Created: | November 11, 2004 | Updated: | November 17, 2004 | |||||||||
| Description: | ez-ipupdate, a dynamic DNS file updating utility, has a format string vulnerability that can lead to the execution of arbitrary code. | |||||||||||
| Alerts: |
| |||||||||||
openssl: der_chop script temp file vulnerability
| Package(s): | openssl | CVE #(s): | CAN-2004-0975 | ||||||||||||
| Created: | November 11, 2004 | Updated: | July 19, 2005 | ||||||||||||
| Description: | The der_chop script in openssl has a temp file vulnerability that may allow an attacker to overwrite arbitrary files with the permissions that the script is running under. | ||||||||||||||
| Alerts: |
| ||||||||||||||
SquirrelMail: cross-site scripting
| Package(s): | squirrelmail | CVE #(s): | CAN-2004-1036 | |||||||||||||||
| Created: | November 17, 2004 | Updated: | December 23, 2004 | |||||||||||||||
| Description: | Squirrelmail (through version 1.4.3a-r2) suffers from yet another cross-site scripting vulnerability. | |||||||||||||||||
| Alerts: |
| |||||||||||||||||
sudo: environment variable sanitizing
| Package(s): | sudo | CVE #(s): | CAN-2004-1051 | ||||||||||||||||||
| Created: | November 17, 2004 | Updated: | May 15, 2005 | ||||||||||||||||||
| Description: | Versions of sudo prior to 1.6.8p2 fail to properly sanitize the environment prior to running shell scripts; this failure can be exploited by a sudo user to subvert scripts and obtain shell access. See the 1.6.8p2 announcement for more information. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
unarj: buffer overflow vulnerability
| Package(s): | unarj | CVE #(s): | CAN-2004-0947 | |||||||||||||||
| Created: | November 11, 2004 | Updated: | February 2, 2005 | |||||||||||||||
| Description: | The unarj uncompression utility has a buffer overflow vulnerability from handling long file names in an archive. An attacker can cause unarj to crash or execute arbitrary code. | |||||||||||||||||
| Alerts: |
| |||||||||||||||||
Updated vulnerabilities
Gallery: cross-site scripting vulnerability
| Package(s): | Gallery | CVE #(s): | CAN-2004-1106 | ||||||
| Created: | November 8, 2004 | Updated: | January 17, 2005 | ||||||
| Description: | Jim Paris has discovered a cross-site scripting vulnerability in Gallery. By sending a carefully crafted URL, an attacker can inject and execute script code in the victim's browser window, and potentially compromise the users gallery. | ||||||||
| Alerts: |
| ||||||||
ImageMagick: EXIF buffer overflow
| Package(s): | ImageMagick | CVE #(s): | CAN-2004-0981 | ||||||||||||
| Created: | November 8, 2004 | Updated: | December 8, 2004 | ||||||||||||
| Description: | ImageMagick fails to do proper bounds checking when handling image files with EXIF information. An attacker could use an image file with specially-crafted EXIF information to cause arbitrary code execution with the permissions of the user running ImageMagick. See this advisory for more information. | ||||||||||||||
| Alerts: |
| ||||||||||||||
Kaffeine, gxine: remotely exploitable buffer overflow
| Package(s): | Kaffeine gxine | CVE #(s): | ||||
| Created: | November 8, 2004 | Updated: | November 11, 2004 | |||
| Description: | KF of Secure Network Operations has discovered an overflow that occurs during the Content-Type header processing of Kaffeine. The vulnerable code in Kaffeine is reused from gxine, making gxine vulnerable as well. An attacker could create a specially-crafted Content-type header from a malicious HTTP server, and crash a user's instance of Kaffeine or gxine, potentially allowing the execution of arbitrary code. See this SecurityTracker advisory for details. | |||||
| Alerts: |
| |||||
OpenSSL: denial of service vulnerabilities
| Package(s): | OpenSSL | CVE #(s): | CAN-2004-0081 CAN-2003-0851 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | March 17, 2004 | Updated: | November 2, 2005 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | Versions 0.9.7a-c of the OpenSSL library suffer from two denial of service vulnerabilities; see the version 0.9.7d release announcement for details. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
PostgreSQL: Insecure temporary file use in make_oidjoins_check
| Package(s): | PostgreSQL | CVE #(s): | CAN-2004-0977 | ||||||||||||||||||
| Created: | October 18, 2004 | Updated: | December 20, 2004 | ||||||||||||||||||
| Description: | The make_oidjoins_check script 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 make_oidjoins_check is called, this would result in file overwrite with the rights of the user running the utility, which could be the root user. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
Speedtouch USB driver: Privilege escalation vulnerability
| Package(s): | Speedtouch USB driver | CVE #(s): | |||||||
| Created: | November 2, 2004 | Updated: | November 11, 2004 | ||||||
| Description: | The Speedtouch USB driver contains multiple format string vulnerabilities in modem_run, pppoa2 and pppoa3. This flaw is due to an improperly made syslog() system call. A malicious local user could exploit this vulnerability by causing a buffer overflow, and potentially allowing the execution of arbitrary code with escalated privileges. | ||||||||
| Alerts: |
| ||||||||
apache: arbitrary code execution
| Package(s): | apache | CVE #(s): | CAN-2004-0940 | |||||||||||||||||||||
| Created: | October 29, 2004 | Updated: | December 14, 2004 | |||||||||||||||||||||
| Description: | According to an Apache announcement, a vulnerability exists in the Apache HTTP server, version 1.3. The problem is a potential buffer overflow in the "get_tag" function of Apache's SSI module "mod_include". It allows local users who can create SSI documents to execute arbitrary code as the Apache run-time user via SSI documents that trigger a content length calculation error. | |||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||
apache2: denial of service
| Package(s): | apache | CVE #(s): | CAN-2004-0942 | |||||||||||||||||||||
| Created: | November 10, 2004 | Updated: | November 26, 2004 | |||||||||||||||||||||
| Description: | Versions of Apache 2.0 prior to 2.0.53 contain a bug in the header parsing code which can allow a remote denial of service attack given sufficient bandwidth. | |||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||
aspell: bounds checking problem
| Package(s): | aspell | CVE #(s): | CAN-2004-0548 | |||||||||
| Created: | June 17, 2004 | Updated: | December 20, 2004 | |||||||||
| Description: | Aspell's word-list-compress utility fails to properly check bounds when dealing with words that are more than 256 bytes long. This can lead to arbitrary code execution by an attacker. | |||||||||||
| Alerts: |
| |||||||||||
cdrecord: failure to drop privilege
| Package(s): | cdrecord | CVE #(s): | CAN-2004-0806 | |||||||||||||||
| Created: | September 8, 2004 | Updated: | February 21, 2005 | |||||||||||||||
| Description: | The cdrecord utility, which is installed setuid on some distributions, fails to drop privilege before running a user-specified program. | |||||||||||||||||
| Alerts: |
| |||||||||||||||||
ncompress: Buffer overflow
| Package(s): | compress uncompress ncompress | CVE #(s): | CAN-2001-1413 | ||||||
| Created: | October 11, 2004 | Updated: | December 14, 2004 | ||||||
| Description: | compress and uncompress do not properly check bounds on command line options, including the filename. Large parameters would trigger a buffer overflow. By supplying a carefully crafted filename or other option, an attacker could execute arbitrary code on the system. A local attacker could only execute code with his own rights, but since compress and uncompress are called by various daemon programs, this might also allow a remote attacker to execute code with the rights of the daemon making use of ncompress. | ||||||||
| Alerts: |
| ||||||||
cyrus-sasl: remote buffer overflow
| Package(s): | cyrus-sasl | CVE #(s): | CAN-2004-0884 | |||||||||||||||||||||||||||||||||||||||
| Created: | October 7, 2004 | Updated: | March 16, 2005 | |||||||||||||||||||||||||||||||||||||||
| Description: | cyrus-sasl has a vulnerability involving a buffer overflow in the digestmda5.c file. A remote attacker may be able to compromise the system. Also, a local user may be able to exploit a vulnerability by using the SASL_PATH environment variable. | |||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||||||||||||||||||||
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: |
| |||||||||||
Filename disclosure vulnerability in fam
| Package(s): | fam | CVE #(s): | CAN-2002-0875 | ||||||
| Created: | August 19, 2002 | Updated: | January 5, 2005 | ||||||
| Description: | "fam" (file alteration monitor) watches files and directories for changes and lets interested applications know when something happens. This package has a flaw in its group handling that blocks some legitimate operations while, at the same time, exposing the names of files that should otherwise be invisible. | ||||||||
| Alerts: |
| ||||||||
flim: insecure file creation
| Package(s): | flim | CVE #(s): | CAN-2004-0422 | |||||||||
| Created: | May 5, 2004 | Updated: | December 16, 2004 | |||||||||
| Description: | The emacs "flim" mode creates temporary files in an insecure fashion, possibly allowing a local attacker to overwrite files. | |||||||||||
| Alerts: |
| |||||||||||
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: |
| |||||||||||||||||
freeamp: arbitrary code execution
| Package(s): | freeamp | CVE #(s): | CAN-2004-0964 | |||
| Created: | November 8, 2004 | Updated: | November 10, 2004 | |||
| Description: | Luigi Auriemma discovered a buffer overflow condition in the playlist module of freeamp which could lead to arbitrary code execution. Recent versions of freeamp were renamed into zinf. | |||||
| Alerts: |
| |||||
FreeRADIUS: denial of service
| Package(s): | freeradius | CVE #(s): | CAN-2004-0938 CAN-2004-0960 CAN-2004-0961 | |||||||||
| Created: | September 22, 2004 | Updated: | February 2, 2005 | |||||||||
| Description: | FreeRADIUS (through version 1.0.1) suffers from several denial of service vulnerabilities in its packet reception code. | |||||||||||
| Alerts: |
| |||||||||||
gaim: buffer overflow in MSN protocol
| Package(s): | gaim | CVE #(s): | CAN-2004-0891 | ||||||||||||||||||
| Created: | October 25, 2004 | Updated: | February 11, 2005 | ||||||||||||||||||
| Description: | A buffer overflow in the MSN protocol handler for gaim 0.79 to 1.0.1 allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via an "unexpected sequence of MSNSLP messages" that results in an unbounded copy operation that writes to the wrong buffer. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
gaim: command execution via smiley themes
| Package(s): | gaim | CVE #(s): | CAN-2004-0784 CAN-2004-0785 | |||||||||
| Created: | October 21, 2004 | Updated: | November 12, 2004 | |||||||||
| Description: | gaim may allow arbitrary commands to be executed via shell meta characters in the the tar file name that is dragged to the smiley selector. | |||||||||||
| Alerts: |
| |||||||||||
gtk2, gdk-pixbuf: buffer overflows
| Package(s): | gdk-pixbuf gtk2 | CVE #(s): | CAN-2004-0753 CAN-2004-0782 CAN-2004-0783 CAN-2004-0788 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | September 15, 2004 | Updated: | February 25, 2005 | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | The gdk-pixbuf and gtk2 libraries contain vulnerabilities in their handling of BMP and XPM files which can lead to denial of service and, potentially, code execution attacks. | ||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||
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: |
| ||||||||||||||||||||
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: |
| |||||||||||
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: |
| ||||||||
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: |
| ||||||||||||||||||||||||||
gnats: format string vulnerability
| Package(s): | gnats | CVE #(s): | CAN-2004-0623 | |||
| Created: | November 9, 2004 | Updated: | November 10, 2004 | |||
| Description: | Khan Shirani discovered a format string vulnerability in gnats, the GNU problem report management system. This problem may be exploited to execute arbitrary code. | |||||
| Alerts: |
| |||||
gnome-vfs: backend script vulnerabilities
| Package(s): | gnome-vfs | CVE #(s): | CAN-2004-0494 | |||||||||
| Created: | August 4, 2004 | Updated: | February 21, 2005 | |||||||||
| Description: | Several scripts packaged with gnome-vfs, using its "extfs" capability, have security flaws. These scripts tend not to be used on many systems, but their presence can still be a threat. | |||||||||||
| Alerts: |
| |||||||||||
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: |
| |||||||||||
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: |
| ||||||||||||||||||||
gzip: insecure temporary files
| Package(s): | gzip | CVE #(s): | CAN-2004-0970 | ||||||
| Created: | November 8, 2004 | Updated: | December 7, 2004 | ||||||
| Description: | Trustix developers discovered insecure temporary file creation in supplemental scripts in the gzip package which may allow local users to overwrite files via a symlink attack. | ||||||||
| Alerts: |
| ||||||||
imagemagick: buffer overflow vulnerability
| Package(s): | imagemagick | CVE #(s): | CAN-2004-0827 | ||||||||||||||||||
| Created: | September 16, 2004 | Updated: | November 30, 2004 | ||||||||||||||||||
| Description: | The ImageMagick graphics library has several buffer overflow vulnerabilities that allow an attacker to crash the reading process by creating mal-formed video or image files in the AVI, BMP, or DIB format. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
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: |
| |||||||||||||||||||||||||||||
iproute: local denial of service
| Package(s): | iproute net-tools | CVE #(s): | CAN-2003-0856 | ||||||||||||||||||
| Created: | November 25, 2003 | Updated: | December 14, 2004 | ||||||||||||||||||
| Description: | The iproute utility is susceptible to spoofed netlink messages sent by local users, with the result that denial of service attacks are possible. | ||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||
iptables: missing initialization
| Package(s): | iptables | CVE #(s): | CAN-2004-0986 | ||||||||||||
| Created: | November 1, 2004 | Updated: | February 11, 2005 | ||||||||||||
| Description: | Faheem Mitha noticed that the iptables command, an administration tool for IPv4 packet filtering and NAT, did not always load the required modules on its own as it was supposed to. This could lead to firewall rules not being loaded on system startup. This caused a failure in connection with rules provided by lokkit at least. | ||||||||||||||
| Alerts: |
| ||||||||||||||
kernel-utils: setuid vulnerability
| Package(s): | kernel-utils | CVE #(s): | CAN-2003-0019 | |||
| Created: | February 7, 2003 | Updated: | January 21, 2005 | |||
| Description: | The kernel-utils package contains several utilities that can be used to
control the kernel or machine hardware. In Red Hat Linux 8.0 this package
contains user mode linux (UML) utilities.
The uml_net utility in kernel-utils packages with Red Hat Linux 8.0 was incorrectly shipped setuid root. This could allow local users to control certain network interfaces, add and remove arp entries and routes, and put interfaces in and out of promiscuous mode. All users of the kernel-utils package should update to these packages that contain a version of uml_net that is not setuid root. Alternatively, as a work-around to this vulnerability issue the following command as root: chmod -s /usr/bin/uml_net | |||||
| Alerts: |
| |||||
libgd2: buffer overflows in PNG handling
| Package(s): | libgd2 | CVE #(s): | CAN-2004-0990 CAN-2004-0941 | |||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | October 29, 2004 | Updated: | June 28, 2006 | |||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | Several buffer overflows have been discovered in libgd's PNG handling
functions.
If an attacker tricked a user into loading a malicious PNG image, they could leverage this into executing arbitrary code in the context of the user opening image. Most importantly, this library is commonly used in PHP. One possible target would be a PHP driven photo website that lets users upload images. Therefore this vulnerability might lead to privilege escalation to a web server's privileges. Multiple buffer overflows in the gd graphics library (libgd) 2.0.21 and earlier may allow remote attackers to execute arbitrary code via malformed image files that trigger the overflows due to improper calls to the gdMalloc function. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
libpng: multiple vulnerabilities
| Package(s): | libpng | CVE #(s): | CAN-2002-1363 CAN-2004-0597 CAN-2004-0598 CAN-2004-0599 | |||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | August 4, 2004 | Updated: | February 10, 2005 | |||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | There is yet another set of holes in libpng, versions 1.2.5 and prior, which can be exploited by a malicious image file; see this advisory from Chris Evans or this CERT advisory for details. | |||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||
libxml2: multiple buffer overflows
| Package(s): | libxml2 | CVE #(s): | CAN-2004-0989 | |||||||||||||||||||||||||||||||||
| Created: | October 28, 2004 | Updated: | February 28, 2005 | |||||||||||||||||||||||||||||||||
| Description: | libxml2 prior to version 2.6.14 has multiple buffer overflow vulnerabilities, if a local user passes a specially crafted FTP URL, arbitrary code may be executed. | |||||||||||||||||||||||||||||||||||
| Alerts: |
| |||||||||||||||||||||||||||||||||||
libxpm4: stack and integer overflows
| Package(s): | libxpm4 | CVE #(s): | CAN-2004-0687 CAN-2004-0688 | ||||||||||||||||||||||||||||||||||||||||||
| Created: | September 16, 2004 | Updated: | February 14, 2005 | ||||||||||||||||||||||||||||||||||||||||||
| Description: | There are several stack and integer overflow bugs in the libXpm code of XFree86 that may be used for a denial of service. | ||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||
logcheck: symlink vulnerability
| Package(s): | logcheck | CVE #(s): | CAN-2004-0404 |
| Created: | April 21, 2004 | Updated: | D |