Novell, buyer's remorse, and the patent threat
One cannot help but wonder if Novell's executives aren't having second
thoughts about that company's recent deal with Microsoft. Since the
announcement, there has been quite a bit of hostile commentary in the
community, and there are signs of increasing levels of unhappiness within
the ranks of Novell's free software developers. The increase in Novell's
stock price turned out to be short-lived. And Microsoft CEO Steve Ballmer
has used this deal as his excuse to embark on a FUD campaign which brings
back memories of Darl McBride's heyday.
For an example, consider this
widely-distributed bit of fun:
And we agreed on a, we call it an IP bridge, essentially an
arrangement under which they pay us some money for the right to
tell the customer that anybody who uses Suse Linux is appropriately
covered. There will be no patent issues. They've appropriately
compensated Microsoft for our intellectual property, which is
important to us. In a sense you could say anybody who has got Linux
in their data center today sort of has an undisclosed balance sheet
liability, because it's not just Microsoft patents. Because of the
way open-source works, there's nobody who's been able to do patent
coverage or patent indemnification behind that.
Mr. Ballmer is clearly claiming that Linux infringes upon Microsoft's
patents, and that Linux users owe money to Microsoft. Novell is fairly
clearly seen as having agreed with and validated that claim - otherwise,
what, exactly, is Novell paying for? In an attempt to change that
perception, Novell has sent out an
open letter to the community, saying:
Since our announcement, some parties have spoken about this patent
agreement in a damaging way, and with a perspective that we do not
share. We strongly challenge those statements here.
We disagree with the recent statements made by Microsoft on the
topic of Linux and patents. Importantly, our agreement with
Microsoft is in no way an acknowledgment that Linux infringes upon
any Microsoft intellectual property. When we entered the patent
cooperation agreement with Microsoft, Novell did not agree or admit
that Linux or any other Novell offering violates Microsoft
patents.
Microsoft has responded with a
letter of its own.
It seems that, perhaps, Novell got a slightly different deal than it was
expecting at the outset. Presumably Novell's management is smart enough to
understand that, if it throws away its community goodwill and runs into
problems with the GPL, Novell's Linux business will have a dark future.
Presumably, Novell's managers did not want to see their company be the
enabler for a new flood of anti-Linux FUD and attempts to divide the
community. Seemingly, however, those managers did not think through the
consequences of signing this non-license with Microsoft. Thus the open
letter and the IRC meeting about
the deal, scheduled for November 27.
Microsoft's claims have been met with a "show us the patents" response in
parts of the community. Novell's open letter, which refuses to acknowledge
the existence of patent issues, is a very similar sort of response. This
approach worked well in the SCO case, for a simple reason: there was no
substance to that company's wild claims. It is natural to think that the
same sort of challenge will work this time around, but that thinking may be
a mistake.
The SCO case was, at least in certain phases, based on copyright.
Avoidance of copyright problems is relatively easy for a free software
project; all that is required is to not accept code of uncertain origin.
Truly original work cannot have copyright issues.
Microsoft, however, is talking about patents. Anybody who thinks that
Microsoft holds no patents which can be applied to Linux has, perhaps,
failed to understand the scope of the software patent problem. There is no
clear way for a free software project to avoid software patent issues - at
least, in parts of the world where such patents are recognized.
An incredible number of patents have been issued covering trivial
techniques. One of your editor's favorites is #6,732,359,
the primary claim of which is:
A computer system having a memory, an operating system, a computer
application instantiated in a work space in the memory as managed
by the operating system, the application including a plurality of
application processes running in the work space, and an application
monitor monitoring whether each of the plurality of application
processes is in fact running and automatically attempting to remedy
an occurrence where any of the plurality of application processes
is not in fact running.
This ground-breaking, innovative work was patented in 2004; presumably,
nobody ever thought of such a technique before 1999, when the patent was
originally filed.
In the real world, anybody trying to enforce a patent like this would be
immediately buried in prior art. But there is little comfort to be found
there. Even a relatively large company like Novell can only afford to
defend so many patent suits, and there are a lot of patents like
this one out there. Even if Microsoft does not currently own any patents
which could be applied to Linux, there is no doubt that it could acquire
some without great difficulty. Unlike SCO's claims, the patent problem is
real, whether Novell publicly acknowledges it or not.
If Microsoft had wanted to mount a patent attack against Linux, it could
have easily done so by now. There's plenty of reasons which may explain
why this has not happened so far. The fact that software patents are not
recognized worldwide could well be part of the equation; that is why
continued resistance to their imposition in Europe is so important. An
attack against Linux certainly would not help Microsoft's position with
antitrust authorities. Chances are that almost any company which is buying
Linux support services is also a Microsoft customer, and Microsoft might
just be smart enough to want to avoid upsetting its own customers. A legal
campaign against Linux might well bring together a fearsome coalition of
large companies with an interest in defending Linux and blood in its eyes.
There is also the simple fact
that Microsoft has not, to date, acted much like a patent troll; it has,
instead, spent more time on the defendant's side of the courtroom.
None of this gives any sort of real assurance that Linux is safe from such
attacks by Microsoft, certainly. One should never underestimate corporate
unpredictability - or stupidity. But it does suggest that the risk of a
patent attack has not really changed as a result of Novell's arrangement.
That risk existed before, and it still does. And, as Mr. Ballmer pointed
out, it's not just Microsoft's patents. When the patent attack comes, it
will likely originate from a small litigation company which has no
customers to offend and no assets to countersue for. Novell (and its
customers) will be no safer than the rest of us when this attack happens.
So one might, indeed wonder what Novell thought it was buying. The answer,
perhaps, lies in the fact that the net cash flow is very much in Novell's
direction. Hundreds of millions of dollars can be hard to turn down. One
can hope that this money ends up benefiting both Novell and
the free software community that Novell depends on. At the moment,
however, it looks like Novell has put itself into a bit of an uncomfortable
position.
Comments (42 posted)
Notes from the leading edge
Much of your editor's work has, for the last couple of years, been done on
an x86-64 system running the Fedora Development ("Rawhide") distribution.
Running Rawhide - just like running any other development distribution -
has certainly provided sufficient experience to keep your editor grumpy for
some time. Even so, the current state of post-FC6 rawhide is, perhaps,
exceptional.
The gnome-terminal package picked up some interesting behavior where it
seemingly grows without bound - a 350MB virtual address space on your
editor's system, with 76MB resident. It easily outweighs lean-and-mean
applications like emacs and liferea - though it remains outclassed by
firefox. The cursor does not respond to focus events; your editor has
learned to type at terminals even if they look like they are not listening.
Occasionally a terminal will get into a mode where it refuses to respond to
input until it receives a mouse click or two. And, occasionally, the whole
thing just crashes, taking down every terminal window and every associated
ssh session.
Your editor's longstanding appreciation for xterm is on the rise again.
In the hope of picking up a fix in a timely manner, your editor has been
tracking the Rawhide repository a bit more closely than usual. Or, at
least, attempting to do so. It can be quite discouraging to type
"yum update" and have yum simply go off forever. Among other
things, one must wait a great long time to distinguish this behavior from
yum's normal mode of operation. Other times, it comes back very quickly
with a message saying, for all practical purposes, "RPM crashed, you lose,
sorry."
That is the sort of message that can chill a system administrator's blood.
There's no end of system problems which can be addressed by reinstalling a
package, perhaps moving to an older version. That is especially true for
systems which are following a leading-edge development repository; one
simply expects to install an ill-fated package occasionally. But if the
package management system itself fails, this important tool goes away and
one's ability to restore a sick system is severely compromised. It's about
at this point that one begins to think it would have been good to check the
system's backups a little more frequently.
Some digging around turns up the fact that these problems are well known
and well documented in the bug-tracking system. Also found was a magic
command, previously unknown to your editor, which evidently needs to be
part of every system administrator's toolkit (at least, those who work with
RPM-based systems):
rm /var/lib/rpm/__db*
Sure enough, every time your editor's system goes nonlinear (i.e. after
every "yum update"), removing those
cache files makes the problem go away. It would be awfully nice if RPM
could figure out for itself that its cache is corrupt and not depend on people to
clean up its messes for it. But that, evidently, is more than we should
feel entitled to expect.
Still, one could consider taking this issue - perhaps with a patch - to the
RPM maintainer. Except that, for the purposes of most distributions, there
still is no RPM maintainer. Your editor asked who maintains RPM? back in
August, but no distributor has since announced a plan for moving to the
current "upstream" version of RPM or establishing a formal fork. The
November 20 Fedora Board
meeting talked about an upcoming "RPM
announcement," but it remains unannounced as of this writing. Getting a
handle on the status of that crucial package would be most beneficial for
users of RPM-based distributions, whether or not they do silly things like
track development repositories.
Comments (38 posted)
Embedded Linux: Small Root Filesystems
November 17, 2006
This article was contributed by Michael J. Hammel
In
the first part of this
series I looked at the TinyLinux project, a set
of patches aimed at helping developers reduce both the size of their kernel
images and the amount of memory they use at runtime. But if you're working
to build a working small system you'll need more than a kernel. You need
something for the kernel to manage. You need user space applications and an
environment in which they can run on top of your tiny kernel. And like
your tiny kernel, you need your environment and applications to be as small
as possible.
The Root Filesystem
The Linux kernel works hand in hand with what is called the root
filesystem. This is the filesystem upon which the root directory
can be mounted and which contains the files necessary to bring the system
to a state where other filesystems can be mounted and user space daemons and
applications started. Most desktop and server distributions make use of
two kinds of root filesystems: the initial root filesystem and the real
root filesystem. The former is used to mount and run the latter.
The directory structure for a root filesystem can be extremely minimal, as
we'll see in a moment, or it can contain the usual set of directories
including /dev, /bin, /etc, and /sbin, among others that you see in any
desktop Linux distribution.
The kernel boot process concludes with the init code (see init/main.c)
whose primary purpose is to create and populate an initial root filesystem
with a set of directories and files. It then tries to launch the first user
mode process to run an executable file found on this initial
filesystem. This first process ("init") is always given process ID 1.
There are three ways for the kernel to find the file that will be run by the
init process. The first method is to use a file specified at boot time
with the init= kernel parameter. If this parameter is not set,
the kernel tries a series of locations
to find a file named "init". These include /sbin/init, /etc/init, and
/bin/init. If all these fail, the kernel tries to run any shell it finds at
/bin/sh. If this last fallback is not found, the kernel will print an
error saying that no init could be found.
Once the init process is started it typically begins to launch other user
space programs. On a desktop or server system this is known as the
sysvinit process and includes the set of scripts found (typically) under
/etc/rc.d. The name sysvinit comes from the mechanism used in System V
Unix, which defined the naming scheme used for directories and files.
On embedded and small footprint systems the init process may be a set of
custom designed scripts or even a single application. Some desktop
distributions are also beginning to replace sysvinit with alternatives
designed with faster booting in mind.
The early root filesystem: Initial Ramdisks
The initial root filesystem is known as the initial ramdisk because the
filesystem lives in a disk image created by the kernel in RAM. In a
desktop or server system, the initial ramdisk is used to load drivers and
initialize an environment so that an external storage system (disk or
network attached storage) can be mounted. The switch from the initial root
filesystem to the real root filesystem is called a pivot. The pivot causes
the real root filesystem to be mounted over the initial root filesystem.
When that happens, a new init process from the real root filesystem is
launched and takes over the process id of 1. At that point the initial
ramdisk is no longer needed and the memory can be freed.
In an embedded system the initial ramdisk might be the only filesystem ever
mounted, since it contains all the user mode applications required.
Alternatively, the initial ramdisk might mount a flash drive or other local
storage yet still not pivot. Instead the mounted storage might be used as
a source for user space applications. In these cases the initial ramdisk
is never cleared because the pivot never happens.
In the 2.4 kernel, the initial ramdisk was referred to as the initrd image.
It was created as a filesystem inside a file. The file was mounted and a
filesystem created inside of it. A directory structure for the initial
ramdisk was copied into this filesystem. The file was then unmounted,
compressed and provided to the kernel via the initrd= kernel parameter at
boot time.
The initrd file could only be loaded at boot time from an external
source (except for the MIPS kernel, which allowed you to embed the image
into the kernel). The original ram disk mechanism for the 2.4 kernel
created a synthetic fixed sized block device that needed the filesystem
driver used when the initrd was created, such as ext2, in order to work
with file data. At the end of the boot process the initrd image had to be
unmounted in order to clean up memory usage before switching to a more
complete root filesystem.
In the 2.6 kernel the process of creating and using the initial ramdisk has
been somewhat simplified. First, the files are simply collected together
in an compressed CPIO file, now referred to as the initramfs instead of
initrd. The initramfs file is always embedded in the kernel (for all hardware
platforms) even if you don't create one yourself. If you don't, a default
CPIO archive is created automatically by the kernel build process.
Second, there is no external filesystem required at boot time for the
initramfs. Instead, the initramfs is unpacked in a special ramfs-based
filesystem called the rootfs. The ramfs filesystem support is built into
the kernel and cannot be disabled, so it's always available. Because
it doesn't use backing store, it's a simpler system than the mechanism used
in the 2.4 kernel. And when the boot process is done with the initramfs, a
more complete root filesystem (such as one found on disk) can be directly
mounted over it without worrying about wasting a lot of memory.
Why use the initramfs?
It would be ideal if the kernel could boot into a minimal state that knew
just enough to bring the system to a useful state for the user or
environment it will run in. This minimal state would allow the kernel to
be as small as possible with as few options compiled in as possible. This
is exactly why you use an initramfs.
On any system, and most especially on resource limited systems, you want to
keep the kernel itself small and dynamically load only those driver modules
that are required to make the system finish booting. Most desktop systems
use the initramfs to determine what kind of hard drive or other storage is
available with a complete root filesystem. In this case the initramfs
contains boot scripts and driver modules relevant to bringing up the
system. These files are only kept around temporarily while the real root
filesystem is mounted and the real init process is started. Because the
variety of desktop hardware is large, the initramfs can end up being large
and fairly sophisticated as it tries to guess what kind of hardware is
about to be mounted.
On small systems the situation can be much different. There may not be any
additional storage available to hold another, more complete root
filesystem. In that case the initramfs becomes the real root filesystem.
Because the initramfs is running out of RAM, it will contain only those
files and directories absolutely necessary to run the system.
Alternatively, a small system might use a dedicated flash drive with read
only access to prevent accidental destruction of the bootable system. In
that case the initramfs will contain boot scripts that mount the flash
device and perform a little trickery to simulate writeable partitions so
the system can operate normally.
Creating an initramfs
It's possible to recreate an initial ramdisk that mirrors your running
desktop using the mkinitrd script. The problem with using this script is
that you're recreating your desktop environment. That's not likely what
you're looking for in your embedded system or even a live CD. So we need to
look at creating the initramfs manually.
The kernel source includes the text file ramfs-rootfs-initramfs.txt under
Documentation/filesystems. In this file, under the section titled
"Populating initramfs" are instructions for creating a very minimal
initramfs. This includes a minimal set of device files, the /proc, /sys
and /mnt directories, an init script and a BusyBox binary. We'll get to
BusyBox in a moment.
Start by creating a directory called "myinitfs":
mkdir myinitfs
Add some basic directories:
mkdir -p myinitfs/{boot,proc,sys,mnt,sbin,dev,lib,usr/bin}
Not all of these are required but you'll want them around to populate with
useful tools in your initramfs anyway. Next, add the required device
files. If your kernel and user space processes need to be able to
output messages then the minimal root filesystem will need a console
device. This is created with the mknod command.
mknod -m 644 myinitfs/dev/console c 5 1
If your system is booting from a CD and the root filesystem is in a
compressed filesystem image on the CD then you'll also need a loop device.
mknod -m 644 myinitfs/dev/loop0 b 7 0
Of course, your embedded system doesn't have to output messages to a
console and it certainly doesn't have to mount any filesystems, so neither
of these are required. But if you're creating a live CD you'll want them.
After creating the directory structure and adding these two devices, we
copy in a shell script for our init program and a compiled copy of the
BusyBox binary. The content of the shell script and the makeup of the
BusyBox binary are the keys to getting your small system running.
Starting Small: BusyBox
BusyBox is the workhorse of embedded systems. It is a collection of
commonly used Unix utilities rolled together into a single binary. The
command line utilities usually have fewer options than their standalone
counterparts but tend to be functionality similar. The primary goal of
BusyBox is to provide a full featured set of utilities for resource limited
systems.
BusyBox is a well designed package that is extremely easy to use. A
graphical configuration utility similar in style to the curses-based kernel
configuration utility allows you to choose the utilities you need. The
Unix utilities are referred to as applets and the configuration utility
lets you pick which applets to include in the binary. The choice of which
applets to include depends entirely on the system you're trying to create.
For a live CD that mounts a compressed file system from the CD as the real
root filesystem (over the initramfs) you would include utilities like
losetup, mount and umount, gzip, and tar, along with the basic ls, ash, grep,
mkdir, mknod and so forth.
The build process for BusyBox is simple. Unpack the BusyBox archive in the
current directory (where myinitfs is located). This creates a BusyBox
directory. In that directory, create your configuration:
make menuconfig
You'll be prompted to save the configuration, which you should do. In the
configuration you should be certain to specify the directory where the
build should be installed. While not absolutely required, it saves a copying
step later. In the latest version of BusyBox, 1.2.1, look under the
BusyBox Settings->Installation Options menu and set the install directory
to "../myinitfs".
After configuration, you simply build and install the binary:
make
make install
Getting Bigger: LFS
Before looking at the init script I want to mention that, although BusyBox
can provide just about everything you need to get the system booted and
even provide a runtime environment on its own, you might need far more user
space support. If you're looking to extend your system to a full
distribution, be sure to look at the LinuxFromScratch.org web site, known
more commonly as LFS. Here you'll find step by step instructions on how to
build a complete distribution.
The LFS is often used in live CD distributions as the runtime system that is
loaded from a compressed filesystem off a CD by a BusyBox-based initramfs.
Building a live CD from scratch in this manner is a great way to learn what
a Linux distribution is all about, from the kernel on up through KDE and
GNOME.
A live CD init script
At this point you've created a minimal set of utilities and a directory
structure suitable for booting (sans the kernel, of course). But you still
need the all important init script that kicks things off for the user space
environment.
I've worked with this init script for some
time, which is based on
the init script found in an older version of the LFS live CD. It assumes
the use of UnionFS and SquashFS for mounting and using compressed
filesystem image files from the CD.
In my next article in this series I'll look at how and why you would use
compressed filesystems like SquashFS along with UnionFS to boot your
system.
Comments (21 posted)
Page editor: Jonathan Corbet
Security
Virtual Machines and Memory Protections
November 20, 2006
This article was contributed by John Richard Moser
The IT industry and the open source community both currently enjoy a
healthy want for security, a growing passion that has brought about new
security tools and even some new programming languages. It isn't always easy
to get all of these things working together; virtual machines such as Mono, for example, have
difficulty with the memory space policies enforced by PaX or SELinux. Some
implementations of the CLI virtual machine may have difficulty functioning
with these security protections, and may be exposed to native code called
from C# programs or the virtual machine itself.
The C# programming language is gaining popularity, and has been used to
write programs such as Beagle, F-Spot, and Banshee. It is also a supported
language for development in the GNOME environment. C# has strong type
checking, array bounds checking, detection of attempts to use uninitialized
variables, and automatic
garbage collection, making it both type-safe and memory-safe; these
aspects make it an attractive language for developers who want to sidestep
manual memory management and just get their programs working.
C# programs are typically compiled to Common Instruction Language (CIL), a
bytecode language designed to be run inside a virtual machine implementing
the Common
Language Infrastructure (CLI). Bytecode languages are similar to
machine-level instructions, except they're not hosted on a physical CPU;
effectively they are CPU architectures that are only run on emulators.
Another familiar example of this is the Java platform, the typical target of
the Java programming language.
The most naive approach to bytecode execution is to use an interpreter.
Interpreters read each instruction in the program as executed; determine what
the instruction is; and then modify the state of the virtual machine as
needed, changing memory values or the program execution point. Interpreters
execute dozens of instructions each time they process a bytecode instruction;
programs execute very slowly, with all but the simplest being irritatingly
sluggish.
Virtual machines often use a technique called Just-in-Time compilation
(JIT) to improve performance. Rather than interpret, JIT compilers generate
equivalent native code from the bytecode they encounter; in essence, they
translate the parts of the program being run to run natively as encountered.
Because of this, the continuous interpreter cost becomes a series of short
one-time compilation costs, which in most cases goes unnoticed.
The first time I wrote for LWN, I authored a small article on security improving technologies which
could be deployed now. Since then, these and other technologies have
become more prevalent; ProPolice is part of gcc, and some of the concepts behind PaX and grsecurity are now integrated into products
such as Exec Shield and SELinux. SELinux has policy elements
that can be applied to almost exactly mimic the behavior of
mprotect() under PaX.
Briefly put, both PaX and SELinux supply a set of protections that prevent
programs from executing any memory that could have ever been directly altered
by the program itself. A typical exploit technique is to use a flaw in a
program to cause it to execute an area of memory an attacker loaded with
code; with these restrictions, this attack is no longer possible. The attackers are
forced then to resort to executing existing code out of order, which is a
blind shot at a moving target due to address space
randomization.
These protections are highly significant; however, they interfere in an
unfortunate way with the execution of programs on Just-in-Time (JIT)
mechanisms such as those used in Mono. The JIT needs to write code into
memory and execute it; and the security system won't allow code generated at
runtime to run. Since the interpreter is far too slow to be useful, the only
real option is to disable the security mechanisms that interfere with the
JIT.
The Common
Language Infrastructure (CLI) allows for managed code to access unmanaged
code; in other words, C# code can call plain old C libraries, making the
program as a whole vulnerable to flaws that can't exist in C#. The
implementation of the virtual machine is also a factor: Mono implements Web browser features using
Mozilla's Gecko rendering engine; and Java implementations can, for example,
use libpng bindings to supply PNG image handling rather than
full managed rewrites.
Below are listed a couple popular Mono applications—C# and other
CLI applications that run on Mono—using native libraries; as well as
some of those libraries that have had significant security holes allowing
remote runtime code execution.
- Banshee, a music
player that handles a variety of formats.
- F-Spot, a personal photo
management application for GNOME.
- libpng is used in F-Spot as well, for much more
than just album covers.
- zlib is also used in F-Spot.
- libxml2 was the subject of CVE-2004-0989
and CVE-2004-0110.
With this potential for vulnerability, it would be attractive to find a
solution for executing Mono without using the JIT. To execute CLI
applications without a JIT, Mono would have to provide a method of executing
assemblies without rewriting them into native code at runtime. This method
would have to function both for typical CIL code and for dynamic
assembly. Dynamic assembly is used to generate CIL bytecode at runtime,
which is then executed by Mono with the help of the JIT. The Cecil debugger; IronPython; and the IKVM Java runtime are examples of
programs that use dynamic assembly to execute whole programs.
The most naive method would be to switch back to the interpreter.
Unfortunately we've already established that the interpreter is extremely
slow, requiring dozens of cycles to complete even the simplest addition or
variable assignment. Even if the interpreter didn't have such prohibitive
performance issues, it's not really
supported anywhere the JIT works, and isn't actively maintained.
Another possibility is to use the Ahead-of-Time (AOT) compiler to run Mono
programs. The AOT compiles Mono assemblies to native code and stores them as
shared libraries. AOT modules can be cached, verified, and updated as needed.
This allows Mono to dlopen() the generated code and execute it like
any other library. This not only eliminates runtime code generation; but also
also increases code sharing between applications, reducing overall system
memory usage. Unfortunately, dynamic assembly doesn't work with AOT, because
it cannot be cached and verified later.
Ulrich Drepper described method of
double-mapping a
file, in which the same memory is available in two different places under
two different permission sets. The file is created, opened, and unlinked so
no other program can alter it; and then
mmap() is used to make two
shared mappings, one writable and one executable. This would work; but it
would also increase disk access and use more of the task's virtual address
space. It would also still allow a very obscure, unlikely, but possible
method for directly introducing code into a program's address space and
executing it successfully.
Currently there doesn't seem to be an obvious great solution to get Mono
to run without runtime code generation. The interpreter is too slow; AOT
doesn't cover dynamic assembly; and Drepper's method of double-mapping a file
creates more disk access. Hybrid methods such as AOT with double-mapping for
dynamic assemblies are also possible, reducing the severity of some of the
drawbacks. By combining these methods, varying degrees of immunity to remote
code execution are afforded with corresponding cost trade-offs.
Of interesting note is that double-mapping a file would prevent policy
from being used to restrict the program to mapping only system libraries and
a global AOT cache. Apart from the unlikely special case with double-mapping,
enhanced memory protections will guarantee that an attacker cannot directly
introduce code into a running program; however, attacks that use
return-to-libc chains can still create, mmap(), and execute a file.
To prevent this, one could restrict executable file-backed mappings to
directories only the system administrator can write to, such as system
libraries and a global AOT cache; of course, this would break
double-mapping.
I cannot predict the implications of these facts for trusted systems and
the applications of C# and Mono in high-security environments. For my own
purposes, I would prohibit the use of Mono programs in environments with
strong security requirements. In my perspective, the cost and potential for
error involved in manually auditing all native code in both the Mono virtual
machine and any native code used by Mono applications simply does not supply
enough value; it is much easier to utilize protections against classes of
vulnerabilities than to prove that applications do not need said protections.
Your mileage may vary.
Comments (50 posted)
New vulnerabilities
elinks: arbitrary file access
| Package(s): | elinks |
CVE #(s): | CVE-2006-5925
|
| Created: | November 16, 2006 |
Updated: | February 1, 2007 |
| Description: |
The elinks text-mode browser has an arbitrary file access vulnerability
in the Elinks SMB protocol handler. If a user can be tricked into
visiting a specially crafted web page, arbitrary files may be read or
written with the user's permissions. |
| Alerts: |
|
Comments (none posted)
flexbackup: insecure temporary file
| Package(s): | flexbackup |
CVE #(s): | CVE-2006-4802
|
| Created: | November 21, 2006 |
Updated: | November 21, 2006 |
| Description: |
Eric Romang discovered that the flexbackup backup tool creates temporary
files in an insecure manner, which allows denial of service through a
symlink attack. |
| Alerts: |
|
Comments (none posted)
gv: stack-based buffer overflow
| Package(s): | gv |
CVE #(s): | CVE-2006-5864
|
| Created: | November 20, 2006 |
Updated: | April 9, 2007 |
| Description: |
Stack-based buffer overflow in the ps_gettext function in ps.c for GNU gv
3.6.2, and possibly earlier versions, allows user-assisted attackers to
execute arbitrary code via a PostScript (PS) file with certain headers that
contain long comments, as demonstrated using the DocumentMedia header. |
| Alerts: |
|
Comments (none posted)
libpng: denial of service
| Package(s): | libpng |
CVE #(s): | CVE-2006-5793
|
| Created: | November 16, 2006 |
Updated: | December 4, 2006 |
| Description: |
Applications that use libpng are vulnerable to a denial of service attack
that may be brought about by the decoding of malformed PNG files. |
| Alerts: |
|
Comments (none posted)
proftpd: denial of service
| Package(s): | proftpd |
CVE #(s): | CVE-2006-5815
|
| Created: | November 17, 2006 |
Updated: | January 24, 2007 |
| Description: |
A denial of service (DoS) vulnerability exists in the FTP server ProFTPD, up
to and including version 1.3.0. The flaw is due to both a potential bus
error and a definitive buffer overflow in the code which determines the FTP
command buffer size limit. The vulnerability can be exploited only if the
"CommandBufferSize" directive is explicitly used in the server
configuration. |
| Alerts: |
|
Comments (none posted)
qmailadmin: buffer overflow
| Package(s): | qmailadmin |
CVE #(s): | CVE-2006-1141
|
| Created: | November 21, 2006 |
Updated: | November 21, 2006 |
| Description: |
qmailAdmin fails to properly handle the "PATH_INFO" variable in
qmailadmin.c. The PATH_INFO is a standard CGI environment variable
filled with user supplied data. |
| Alerts: |
|
Comments (none posted)
tikiwiki: multiple vulnerabilities
| Package(s): | tikiwiki |
CVE #(s): | CVE-2006-5702
CVE-2006-5703
|
| Created: | November 21, 2006 |
Updated: | November 21, 2006 |
| Description: |
In numerous files TikiWiki provides an empty sort_mode parameter, causing
TikiWiki to display additional information, including database
authentication credentials, in certain error messages. TikiWiki also
improperly sanitizes the "url" request variable sent to
tiki-featured_link.php. |
| Alerts: |
|
Comments (none posted)
torque: insecure temporary file creation
| Package(s): | torque |
CVE #(s): | CVE-2006-5677
|
| Created: | November 21, 2006 |
Updated: | November 21, 2006 |
| Description: |
TORQUE creates temporary files with predictable names. The TORQUE package
shipped in Gentoo Portage is not vulnerable in the default configuration.
Only systems with more permissive access rights to the spool directory are
vulnerable. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
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: |
|
Comments (none posted)
asterisk: arbitrary code execution
| Package(s): | asterisk |
CVE #(s): | CVE-2006-5444
|
| Created: | October 19, 2006 |
Updated: | December 6, 2006 |
| Description: |
The Asterisk telephony PBX application has a heap overflow vulnerability
in the skinny channel driver. A remote attacker can use this to
arbitrarily execute code with the privileges of the Asterisk user.
See this
vulnerability report
for more information. |
| Alerts: |
|
Comments (none posted)
avahi: sender id check
| Package(s): | avahi |
CVE #(s): | CVE-2006-5461
|
| Created: | November 13, 2006 |
Updated: | December 20, 2006 |
| Description: |
Steve Grubb discovered that netlink messages were not being checked for
their sender identity. This could lead to local users manipulating the
Avahi service. |
| Alerts: |
|
Comments (1 posted)
bind: denial of service
| Package(s): | bind |
CVE #(s): | CVE-2006-4095
CVE-2006-4096
|
| Created: | September 7, 2006 |
Updated: | February 1, 2007 |
| Description: |
Bind has two denial of service vulnerabilities.
Recursive servers queries for SIG records will trigger an assertion
failure if more than one RR set is returned.
An INSIST failure can be triggered by sending a large number of
recursive queries. |
| Alerts: |
|
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: |
|
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: |
|
Comments (2 posted)
bzip2: race condition and infinite loop
| Package(s): | bzip2 |
CVE #(s): | CAN-2005-0953
CAN-2005-1260
|
| Created: | May 17, 2005 |
Updated: | January 10, 2007 |
| Description: |
A race condition in bzip2 1.0.2 and earlier allows local users to modify
permissions of arbitrary files via a hard link attack on a file while it is
being decompressed, whose permissions are changed by bzip2 after the
decompression is complete. Also specially crafted bzip2 archives may cause
an infinite loop in the decompressor. |
| Alerts: |
|
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: |
|
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: |
|
Comments (none 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: |
|
Comments (2 posted)
freeradius: several vulnerabilities
| Package(s): | freeradius |
CVE #(s): | CVE-2005-4745
CVE-2005-4746
|
| Created: | August 8, 2006 |
Updated: | April 24, 2007 |
| Description: |
Several remote vulnerabilities have been discovered in freeradius, a
high-performance RADIUS server, which may lead to SQL injection or denial
of service. |
| Alerts: |
|
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: |
|
Comments (none posted)
ftpd: privilege escalation
| Package(s): | ftpd |
CVE #(s): | CVE-2006-5778
|
| Created: | November 10, 2006 |
Updated: | February 14, 2007 |
| Description: |
Ftpd is vulnerable to a privilege escalation attack,
an incorrect seteuid() call can be used by an FTP user to gain
unauthorized access to files or directories. |
| Alerts: |
|
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: |
|
Comments (none 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: |
|
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: |
|
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: |
|
Comments (1 posted)
gzip: arbitrary command execution
| Package(s): | gzip |
CVE #(s): | CAN-2005-0758
|
| Created: | August 1, 2005 |
Updated: | January 9, 2007 |
| Description: |
zgrep in gzip before 1.3.5 does not handle shell metacharacters like '|'
and '&' properly when they occurred in input file names. This could be
exploited to execute arbitrary commands with user privileges if zgrep is
run in an untrusted directory with specially crafted file names. |
| Alerts: |
|
Comments (2 posted)
ImageMagick: buffer overflows
| Package(s): | ImageMagick |
CVE #(s): | CVE-2006-5456
|
| Created: | October 31, 2006 |
Updated: | March 8, 2007 |
| Description: |
Multiple buffer overflows in GraphicsMagick before 1.1.7 and ImageMagick
6.0.7 allow user-assisted attackers to cause a denial of service and
possibly execute execute arbitrary code via (1) a DCM image that is not
properly handled by the ReadDCMImage function in coders/dcm.c, or (2) a
PALM image that is not properly handled by the ReadPALMImage function in
coders/palm.c. |
| Alerts: |
|
Comments (2 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: |
|
Comments (none posted)
ingo1: missing input sanitizing
| Package(s): | ingo1 |
CVE #(s): | CVE-2006-5449
|
| Created: | November 3, 2006 |
Updated: | November 27, 2006 |
| Description: |
It was discovered that the Ingo email filter rules manager performs
insufficient escaping of user-provided data in created procmail rules
files, which allows the execution of arbitrary shell commands. |
| Alerts: |
|
Comments (none posted)
kdelibs: integer overflow
| Package(s): | kdelibs |
CVE #(s): | CVE-2006-4811
|
| Created: | October 18, 2006 |
Updated: | March 5, 2007 |
| Description: |
The KDE khtml library can pass untrusted parameters into Qt, allowing a hostile user to trigger an integer overflow there and execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
kdelibs: kate backup file permission leak
| Package(s): | kdelibs kate kwrite |
CVE #(s): | CAN-2005-1920
|
| Created: | July 19, 2005 |
Updated: | November 27, 2006 |
| Description: |
Kate / Kwrite, as shipped with KDE 3.2.x up to including 3.4.0, creates a file backup before saving a modified file. These backup files are created with default permissions, even if the original file had more strict permissions set. See this advisory for more information. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-4623
|
| Created: | October 18, 2006 |
Updated: | November 14, 2007 |
| Description: |
The kernel DVB layer can be caused to crash with maliciously-formatted unidirectional lightweight encapsulation (ULE) data. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-4535
CVE-2006-4538
|
| Created: | September 18, 2006 |
Updated: | December 3, 2007 |
| Description: |
Sridhar Samudrala discovered a local denial of service vulnerability
in the handling of SCTP sockets. By opening such a socket with a
special SO_LINGER value, a local attacker could exploit this to crash
the kernel. (CVE-2006-4535)
Kirill Korotaev discovered that the ELF loader on the ia64 and sparc
platforms did not sufficiently verify the memory layout. By attempting
to execute a specially crafted executable, a local user could exploit
this to crash the kernel. (CVE-2006-4538) |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-4572
CVE-2006-4997
|
| Created: | November 6, 2006 |
Updated: | January 17, 2007 |
| Description: |
Some vulnerabilities were discovered in the Linux 2.6 kernel:
There are possibly exploitable bugs in the netfilter for IPv6 code.
(CVE-2006-4572)
The ATM subsystem of the Linux kernel could allow a remote attacker to
cause a Denial of Service (panic) via unknown vectors that cause the ATM
subsystem to access the memory of socket buffers after they are freed.
(CVE-2006-4997) |
| Alerts: |
|
Comments (none posted)
kernel: denial of service by memory consumption
| Package(s): | kernel |
CVE #(s): | CVE-2006-2936
|
| Created: | July 17, 2006 |
Updated: | November 14, 2007 |
| Description: |
The ftdi_sio driver (usb/serial/ftdi_sio.c) in Linux kernel 2.6.x up to
2.6.17, and possibly later versions, allows local users to cause a denial
of service (memory consumption) by writing more data to the serial port
than the driver can handle, which causes the data to be queued. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-5757
|
| Created: | November 13, 2006 |
Updated: | November 14, 2007 |
| Description: |
From the MOKB-05-11-2006
advisory: "The ISO9660 filesystem handling code of the Linux
2.6.x kernel fails to properly handle corrupted data structures, leading to
an exploitable denial of service condition. This particular vulnerability
seems to be caused by a race condition and a signedness issue. When
performing a read operation on a corrupted ISO9660 fs stream, the
isofs_get_blocks() function will enter an infinite loop when
__find_get_block_slow() callback from sb_getblk() fails ("due to various
races between file io on the block device and getblk")." |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-2935
CVE-2006-4145
CVE-2006-3745
|
| Created: | September 1, 2006 |
Updated: | July 30, 2008 |
| Description: |
Previous versions of the kernel package are subject to several
vulnerabilities. Certain malformed UDF filesystems can cause the system to
crash (denial of service). Malformed CDROM firmware or USB storage devices
(such as USB keys) could cause system crash (denial of service), and if
they were intentionally malformed, can cause arbitrary code to run with
elevated privileges. In addition, the SCTP protocol is subject to a remote
system crash (denial of service) attack. |
| Alerts: |
|
Comments (none posted)
libgadu: memory alignment bug
| Package(s): | libgadu |
CVE #(s): | CAN-2005-2370
|
| Created: | July 29, 2005 |
Updated: | June 25, 2007 |
| Description: |
Szymon Zygmunt and Michal Bartoszkiewicz discovered a memory alignment
error in libgadu (from ekg, console Gadu Gadu client, an instant
messaging program) which is included in gaim, a multi-protocol instant
messaging client, as well. This can not be exploited on the x86
architecture but on others, e.g. on Sparc and lead to a bus error,
in other words a denial of service.
|
| Alerts: |
|
Comments (none posted)
libgd2: denial of service
| Package(s): | libgd2 |
CVE #(s): | CVE-2006-2906
|
| Created: | June 14, 2006 |
Updated: | January 16, 2007 |
| Description: |
Certain GIF images can cause libgd2 to go into an infinite loop, adversely affecting the performance of image processing applications. |
| Alerts: |
|
Comments (none posted)
libmms: buffer overflows