Wind River buys RTLinux
Among many in the real-time community, it is a matter of accepted faith
that a general-purpose kernel (such as the Linux kernel) cannot be expected
to perform properly in a situation where deterministic, real-time response
is required. Things may work most of the time, but one never knows when
such a kernel may get distracted for too long, with disastrous results for
real-time applications. On the other hand, general-purpose kernels do tend
to provide nicer programming environments than hard real-time kernels. So
real-time developers can be faced with a fundamental conflict:
deterministic response or a rich environment?
One longstanding attempt to resolve this conflict is RTLinux. At its core,
RTLinux is a small, real-time kernel without a great deal of
functionality. One of the things RTLinux can do, however, is run a
normal Linux kernel as a low-priority task. The RTLinux kernel responds
to interrupts, passing them through to the real-time code when appropriate;
Linux only gets a chance to run when the real-time code has finished. In
an RTLinux system, a small amount of real-time code can perform data
acquisition or other real-time tasks while leaving much of the more
time-flexible processing to Linux-based code.
One interesting thing to know about RTLinux is that the basic technique is
patented.
This patent - first covered in LWN
in February, 2000 - was a relatively early indication of just how software
patent claims can affect free software users. The core RTLinux code was
licensed under the GPL, but it was not truly free; anybody wanting to use
it was subject to the terms imposed by the patent owner. Those terms were
eventually spelled out in the RTLinux
patent license which allowed royalty-free use provided that either
(1) the "Open RTLinux" distribution was used without modifications, or
(2) the entire application was licensed under the GPL. Not everybody
was happy with this license, but most of the world found ways of living
with it or avoiding the patent, and things got quiet on the RTLinux front
for some years.
On February 20, however, Wind River Systems announced
the acquisition of RTLinux - including the patent. Interestingly, nothing
to be found in Wind River's press release or acquisition FAQ mentions the
patent license in any way. The text of that license, meanwhile, has
disappeared from the FSMLabs site and has yet to reappear on the Wind River
site. LinuxWorld ran an article
on the acquisition with a verbal statement from Wind River that the
license would be maintained, which is a step in the right direction, but it
hardly adds up to a commitment on Wind River's part.
It is entirely possible that Wind River will continue with the current
policy. Perhaps Wind River will even make new "Open RTLinux" releases
allowing licensees to run reasonably contemporary software. At the moment,
however, this code does not appear to be downloadable from anywhere, and
there is no indication of when that situation might change. Along these
lines, it's worth looking at some text from the
acquisition FAQ [PDF]:
There are other real-time Linux products available in open source
today. However, RTLinux is the only commercially supported, hard
real-time product available today. Other open source versions of
RTLinux are based on much older versions of the technology or on
older distributions.
Given that Wind River sees an advantage to having a newer RTLinux than the
"open source" versions, updated free releases of RTLinux from Wind River
seem unlikely.
For anybody who is concerned, there are alternative approaches to real time
and Linux which are worthy of consideration. At the lowest level, there is
Adeos, a "nanokernel" which makes
RTLinux-like functionality available while avoiding the claims of the
RTLinux patent. Rather than run the general-purpose kernel as a task of
the real-time kernel, Adeos runs both as tasks underneath itself. Adeos,
in turn, is used at the base of RTAI, a
longstanding RTLinux competitor. Things have been relatively quiet on the
RTAI front in recent times, but a look at the RTAI-Lab
project suggests that interesting things are happening there still.
Beyond that, work on the real-time preemption project, which aims to make
Linux, itself, a real-time capable kernel, continues, and much of that work
has found its way into the mainline. It will always be harder to prove
that a full Linux kernel can provide deterministic response times, but, for
many applications, the real-time performance of this kernel will be more
than good enough. Some real-time vendors are already shipping products
based on this work.
There may well be an ongoing market for the RTLinux technology that Wind
River has just bought. It would be nice if Wind River could find a way to
exploit that market while, simultaneously, using RTLinux to increase its
contributions back to the community. There are few indications that Wind
River sees RTLinux as anything more than a product, though, so those hoping
for a more community-oriented stance may well be disappointed. The good
news is that the alternatives are plentiful and quickly getting better.
Comments (4 posted)
Notes from the Fedora front
There have been a few events of interest in the Fedora community recently;
this article will attempt to provide a quick overview thereof. For the
purposes of
this page, "events of interest" do not include personalities who have
decided to switch loudly to a different distribution.
The Fedora project has been trying to open itself up to contributions from
the community, with slow (but real) success. The community is not just
made up of developers and packagers, however; it turns out there is a group
of motivated people who would like to help out with the Fedora artwork.
Good design can be as hard as good code, and one would think that this sort
of contribution would be welcome. And, to an extent, it is - to an extent.
There has been a conversation happening on the fedora-art list recently;
some of the themes can be seen in this
posting. It seems, frankly, that the Red Hat-based Fedora folks are
concerned about the quality of artwork contributions and (though they don't
say so in so many words) loss of control over the default look of the
distribution. The end result is that the Fedora board has decided that contributed artwork will not be
part of the default Fedora theme; instead, that work will be done within
Red Hat. The project is trying not to close the door completely:
But the default theme is not all there is to the Artwork project.
There are many things left to do, including the Echo icon set.
Redesign and new art is needed for the Wiki, infrastructure
applications, the "Some Day Soon" Plone site, and so forth. In
addition, Fedora is not limited to just the default release art.
As part of the initiative to give users the ability to spin their
own distributions built on Fedora, we'd like contributor art to be
able to function as a drop-in RPM package replacement for the
default release art.
Nonetheless, there is a fair amount of disappointment in the artwork
community at the moment.
On a related issue, the recent revelation that Dell's customers are asking
for preinstalled Linux systems has created some interested in the Fedora
community. Having a vendor as large as Dell preinstall Fedora would have
clear benefits in helping the project to expand its user base. The Fedora
folks would like to help make that happen, but it seems that there are some potential roadblocks on the
way:
Unless we create the second logo set, I don't think we'll get very
far with pre-installation. Most vendors will want to sweeten the
user experience, and possibly add branding. Any of that will make
it no longer Fedora, and the vendor would be unable to make such
claims under the trademark policy. They'd have to remove all the
Fedora/RH trademarked logos and such too.
Some members of the advisory-board list have pointed out that worrying
about the trademark policy is getting ahead of the game; making the
distribution work seamlessly on, say, Dell laptops should maybe come
first. Still, this issue points out the hazards of mixing trademark
licensing and free software. Sometimes the results are not even in the
trademark holder's interest.
Dell laptops were mentioned because the project knows that a surprisingly
large number of its users are installing Fedora on those systems. How does
Fedora know this? The answer is a tool called "smolt," which gathers
information on the underlying hardware and phones home with it. The
project is quite careful about how this communication is done - no
connection is made until the user explicitly agrees to it happening. Even
so, there have been some complaints on the lists, along with suggestions that it
could be illegal under the privacy laws of some countries, especially in
Europe.
The project is currently working on a
privacy policy to govern its use of data gathered from smolt. It looks
fairly tight; the project really is just interested in the sort of hardware
its distribution is running on, not the people who are running it.
Nonetheless, if anybody has concerns about the use of this information
(which might be expanded to include a list of packages installed on the
system), now would be the time to express them.
During a recent Fedora board meeting, there was discussion of the Fedora 7 release delay,
and, in particular, whether support for Fedora Core 5 and 6 would
be extended to compensate. It came out that, while a number of people
assume that the new 13-month support policy came into effect when it was
adopted, that is not how the project understands it. The Fedora Core
releases are currently expected to be supported under the old way of doing
things: support for Fedora Core 5 will end when the second
Fedora 7 test release (which just went into freeze mode) comes out. Support for
Fedora Core 6 will end during the Fedora 8 development cycle.
The full 13-month (or "2n+1") support mode is only expected to begin with
Fedora 7. There has been some talk of trying to extend security
support for FC5 and FC6, but it is not at all clear that it will happen.
Finally, it has been noted that a number of Fedora tasks seem to be going
more slowly than many people would like. The word that your editor has
heard is that much of this has to do with the impending release of
RHEL 5. Getting that release into final form has been causing some
heavy demands on Red Hat's developers, with the result that less time is
available for working on Fedora. Once the RHEL release is out, things can
be expected to pick up a bit on the Fedora side.
Comments (4 posted)
Who wrote 2.6.20?
Time recently published an article entitled
Getting
rich off those who work for free which, among other things, talked
about free software this way:
Open-source, volunteer-created computer software like the Linux
operating system and the Firefox Web browser have also established
themselves as significant and lasting economic realities.
It is not uncommon to see Linux referred to as a volunteer-created system,
as opposed to the corporate-sponsored, proprietary alternatives. There has
been little research, however, into how much work on Linux is truly
"volunteer" - done on a hacker's spare, unpaid time. In general, the
assumption that Linux is created by volunteers is simply accepted.
Determining the real provenance of free software can be a daunting task.
There is a wealth of information available for those who look, however. In
an attempt to shine some light in this area, your editor hacked up some
scripts to do a lot of digging around in the kernel git repository. The
idea was that, by looking at who is putting changes into the kernel, we can
get a sense for where our source is coming from.
Who got patches into 2.6.20
This study looked at the stream of patches that changed the 2.6.19 kernel
into the current 2.6.20 release. There were, as it turns out 4983
non-merge changesets in this release, contributed by 741 different
developers. (Merge changesets mark where the contents of other
repositories were pulled into the mainline, but they do not carry any code
changes, so the analysis skipped them).
These patches added 286,439 lines of code and removed 159,812
others, for a total growth of 126,627 lines over the 2.6.20 development
cycle.
Your editor's scripts looked over every non-merge commit in 2.6.20. For
each, the developer listed as the "author" was given credit for the patch.
This approach is not entirely fair, since one developer will, in some
cases, be submitting code written by a group of people. In general,
though, there is no easy way of getting around this problem - the true
breakdown of authorship of a joint work simply is not available in the
mainline repository. Your editor believes that this inaccuracy affects the
accounting of a relatively small portion of the patches merged into the
mainline.
Beyond that, how one generates statistics from a patch stream is an
interesting question. How does one measure the productivity of
programmers? One possibility is to look at the number of changesets
merged. By that metric, this is the list of the most prolific contributors
to 2.6.20:
| Developers with the most changesets |
| Al Viro | 241 | 4.8% |
| Andrew Morton | 92 | 1.8% |
| Jiri Slaby | 92 | 1.8% |
| Adrian Bunk | 87 | 1.7% |
| Gerrit Renker | 79 | 1.6% |
| Josef Sipek | 79 | 1.6% |
| Avi Kivity | 68 | 1.4% |
| Tejun Heo | 67 | 1.3% |
| Patrick McHardy | 63 | 1.3% |
| Ralf Baechle | 61 | 1.2% |
| Randy Dunlap | 59 | 1.2% |
| Alan Cox | 58 | 1.2% |
| Mariusz Kozlowski | 57 | 1.1% |
| Andrew Victor | 53 | 1.1% |
| Paul Mundt | 52 | 1.0% |
| Stefan Richter | 49 | 1.0% |
| David S. Miller | 48 | 1.0% |
| Russell King | 44 | 0.9% |
| Benjamin Herrenschmidt | 44 | 0.9% |
| Akinobu Mita | 43 | 0.9% |
Looking at patch counts rewards developers who put in large numbers of
small patches. Al Viro's patches include a vast number of code annotations
(to enable better checking with sparse), include file fixups,
etc. Many of the changes are small - many do not affect the resulting
kernel executable at all - but there are a lot of them. Even so, as the
biggest contributor, Al generated less than 5% of the
total changesets added to the kernel. The top 20 contributors, all
together, generated 28% of the total changesets in 2.6.20.
One could make the argument that a better way to look at the problem is by
the number of lines affected by a patch. In this way, a contributor's
portion of the whole will not depend on whether it has been split into a
long series of small patches or not. On the other hand, simply renaming a
file can make it look like a developer has touched a large amount of code.
Be that as it may, by looking at lines changed (defined
as the greater of the number of lines added or removed by each individual
changeset), one gets a table like this:
| Developers with the most changed lines |
| Jeff Garzik | 20712 | 6.0% |
| Patrick McHardy | 15024 | 4.3% |
| Jiri Slaby | 13917 | 4.0% |
| Avi Kivity | 11726 | 3.4% |
| Andrew Victor | 9710 | 2.8% |
| Amit S. Kale | 9537 | 2.7% |
| Stephen Hemminger | 9120 | 2.6% |
| Geoff Levand | 8396 | 2.4% |
| Michael Chan | 8307 | 2.4% |
| Chris Zankel | 8099 | 2.3% |
| Mauro Carvalho Chehab | 7390 | 2.1% |
| Adrian Bunk | 6138 | 1.8% |
| Yoshinori Sato | 5232 | 1.5% |
| Al Viro | 4981 | 1.4% |
| Benjamin Herrenschmidt | 4588 | 1.3% |
| Thierry MERLE | 4549 | 1.3% |
| Dan Williams | 4516 | 1.3% |
| Jonathan Corbet | 3924 | 1.1% |
| Gerrit Renker | 3857 | 1.1% |
| Jiri Kosina | 3805 | 1.1% |
Jeff Garzik comes out on top of this particular measurement by virtue of
having deleted the long-unmaintained floppy tape subsystem. Patrick
McHardy's work includes a number of additions to the netfilter subsystem,
Jiri Slaby did a great deal of driver cleanup work, Avi Kivity was
the contributor of the KVM
virtualization code, and Andrew Victor contributed a number of
ARM-related patches and the Atmel AT91 i2c driver. (The contributions made
by other authors can be found by searching out their name in the 2.6.20 short-form changelog).
Most of the developers in the above list got there by adding code to the
kernel. It can be said, however, that the true heroes in the development
community are those who remove code and make the kernel smaller. The
developers who were best at removing more code than they added were:
| Developers with the most lines removed |
| Jeff Garzik | 19862 | 12.4% |
| Chris Zankel | 5608 | 3.5% |
| Adrian Bunk | 5528 | 3.5% |
| Arnd Bergmann | 2224 | 1.4% |
| Linus Torvalds | 1739 | 1.1% |
| Atsushi Nemoto | 1425 | 0.9% |
| Thierry MERLE | 911 | 0.6% |
| David Gibson | 878 | 0.5% |
| Dominik Brodowski | 528 | 0.3% |
| Stefan Richter | 509 | 0.3% |
Once again, Jeff Garzik's removal of ftape comes out on top, by far. Chris
Zankel cleaned up the Xtensa architecture, removing a number of files in
the process. Adrian Bunk worked on the ftape removal, got rid of the frame
diverter code, removed an old, broken block driver, and generally performed
cleanups all over the tree. Mr. Bunk is, in fact, the bane of old code;
over the last year (since 2.6.16) he has removed a full 127,000 lines from
the kernel source tree. Arnd Bergman got rid of a bunch of
syscall*() macros. Linus Torvalds removed the broken x86 stack
unwinder code.
Finally, one could look at a different measure entirely: the number of
patches signed off by each developer. A Signed-off-by: line is an
indication that the person involved believes that the code is suitable for
merging into the kernel; it implies that some degree of attention has been
paid to the patch. Authors sign off their code, as do the subsystem
maintainers who pass it up the chain. The top signers-off in 2.6.20 were:
| Developers with the most signoffs |
| Andrew Morton | 1422 | 13.7% |
| Linus Torvalds | 1366 | 13.2% |
| David S. Miller | 483 | 4.7% |
| Jeff Garzik | 331 | 3.2% |
| Greg Kroah-Hartman | 269 | 2.6% |
| Al Viro | 241 | 2.3% |
| Paul Mackerras | 232 | 2.2% |
| Andi Kleen | 177 | 1.7% |
| Mauro Carvalho Chehab | 170 | 1.6% |
| Russell King | 166 | 1.6% |
| Adrian Bunk | 120 | 1.2% |
| Arnaldo Carvalho de Melo | 119 | 1.1% |
| Ralf Baechle | 117 | 1.1% |
| James Bottomley | 109 | 1.1% |
| Patrick McHardy | 96 | 0.9% |
| Jiri Slaby | 94 | 0.9% |
| Avi Kivity | 87 | 0.8% |
| Josef Sipek | 79 | 0.8% |
| Paul Mundt | 78 | 0.8% |
| Gerrit Renker | 78 | 0.8% |
There were a total of 10,354 signoff lines in the 2.6.20 patch stream, so
each changeset, on average, was signed off just over two times. It is interesting that
Linus, who ultimately merges every patch, only signed off 13% of them. It
seems that most patches, these days, go directly into the mainline from
subsystem repositories without a signoff from Linus or Andrew. Most of the
other names on that list, with just a few exceptions, are the maintainers
of subsystem or architecture trees.
Who paid them
So now we have a sense for who got their fingers on the code which went
into 2.6.20. But one interesting question still has not been answered: to
what extent was that code contributed by volunteers (or "hobbyists")?
Finding an answer to that question is somewhat trickier than looking at who
wrote the patches, mostly because very few developers say "I wrote this on
behalf of my employer."
The approach taken by your editor was relatively simplistic, but, perhaps,
the best that is practical. Any patch whose author's given email address
indicates a corporate affiliation is assumed to have been developed by an
employee of that corporation. So any patch posted by somebody with an
ibm.com email address is accounted as having been done by an IBM
employee. Things are complicated by the fact that many people who work for
companies do not use corporate
addresses; it is not unheard-of for companies to have policies explicitly
prohibiting code contributions associated with their domains. Your editor
has coped with this problem by filling in the relevant developer's
affiliation whenever it is known to him; in some cases, the developer was
asked for this information.
This method has the effect of crediting all of an employee's work to
his or her employer. In many cases, the situation is probably more
complicated than that; one assumes, for example, that a certain kernel
hacker's employer has not directed him to hack on
Battle for Wesnoth. When looking only at kernel code, however,
crediting all work to the employer is probably relatively safe.
Using this approach, the top sources of changesets were:
| Top changeset contributors by employer |
| (Unknown) | 1244 | 25.0% |
| Red Hat | 636 | 12.8% |
| (None) | 383 | 7.7% |
| IBM | 368 | 7.4% |
| Novell | 295 | 5.9% |
| Linux Foundation | 261 | 5.2% |
| Intel | 178 | 3.6% |
| Oracle | 126 | 2.5% |
| Google | 97 | 1.9% |
| University of Aberdeen | 79 | 1.6% |
| HP | 78 | 1.6% |
| Qumranet | 71 | 1.4% |
| Nokia | 67 | 1.3% |
| SGI | 64 | 1.3% |
| Astaro | 63 | 1.3% |
| MIPS Technologies | 61 | 1.2% |
| SANPeople | 53 | 1.1% |
| Miracle Linux | 43 | 0.9% |
| MontaVista | 41 | 0.8% |
| Broadcom | 39 | 0.8% |
Looking instead at the number of lines of code changed, the results become:
| Top lines changed by employer |
| (Unknown) | 66154 | 19.0% |
| Red Hat | 44527 | 12.8% |
| (None) | 38099 | 11.0% |
| IBM | 25244 | 7.3% |
| Astaro | 15306 | 4.4% |
| Linux Foundation | 13638 | 3.9% |
| Qumranet | 12108 | 3.5% |
| Novell | 11930 | 3.4% |
| Intel | 11652 | 3.4% |
| SANPeople | 9888 | 2.8% |
| NetXen | 9607 | 2.8% |
| Sony | 8497 | 2.4% |
| Broadcom | 8349 | 2.4% |
| Tensilica | 8195 | 2.4% |
| Nokia | 5581 | 1.6% |
| MontaVista | 4394 | 1.3% |
| University of Aberdeen | 4324 | 1.2% |
| LWN.net | 3975 | 1.1% |
| Secretlab | 3370 | 1.0% |
| HP | 3211 | 0.9% |
[Note that these tables have been updated once since the article was
originally published; the curious can see what the original versions looked like.]
In these tables, the line marked "(Unknown)" is exactly that: patches for
which existence of a supporting employer could not be determined. The line
marked "(None)", instead, indicates the patches from developers
known to be working on their own time.
Either way, the results come out about the same: at least 65% of the code
which went into 2.6.20 was created by people working for companies. If the
entire "unknown" group turns out to be developers working on a volunteer
basis - an unlikely result - then just over 1/3 of the 2.6.20 patch stream
was written by volunteers. The real number will be lower, but it still
shows that a significant portion of the code we run is written by
developers who are donating their time.
One year's worth of changes
Looking at a single kernel release is instructive, but it can also be
deceptive. The relatively short release cycle used by the kernel project
makes it fairly easy for prolific developers to see few of their patches go
into a specific release. In an attempt to gain a longer-term perspective,
your editor forced his suffering system to crank through the entire history
from 2.6.16 (released almost exactly one year ago) to the present. Some
28,000 non-merge changesets have been added to the mainline (by 1,961
developers) over that time,
replacing 1.26 million lines of old code with 2.01 million lines
of new code - the kernel grew by 754,000 lines.
The developers who touched the most lines over that time were:
| Developers with the most changed lines |
| Adrian Bunk | 134021 | 5.3% |
| Jeff Garzik | 87847 | 3.5% |
| Andrew Vasquez | 75195 | 3.0% |
| Mauro Carvalho Chehab | 68568 | 2.7% |
| David Teigland | 46607 | 1.9% |
| Ralf Baechle | 38559 | 1.5% |
| David S. Miller | 35958 | 1.4% |
| Andrew Victor | 35594 | 1.4% |
| Bryan O'Sullivan | 33901 | 1.4% |
| Paul Mundt | 27041 | 1.1% |
| Dave Kleikamp | 26615 | 1.1% |
| Lennert Buytenhek | 25192 | 1.0% |
| Haavard Skinnemoen | 24372 | 1.0% |
| Ben Dooks | 23207 | 0.9% |
| Patrick McHardy | 23175 | 0.9% |
| Ingo Molnar | 22456 | 0.9% |
| James Bottomley | 22205 | 0.9% |
| David Howells | 19168 | 0.8% |
| Jiri Slaby | 18335 | 0.7% |
| Divy Le Ray | 17909 | 0.7% |
The results for employers were:
| Top lines changed by employer |
| (Unknown) | 740990 | 29.5% |
| Red Hat | 361539 | 14.4% |
| (None) | 239888 | 9.6% |
| IBM | 200473 | 8.0% |
| QLogic | 91834 | 3.7% |
| Novell | 91594 | 3.6% |
| Intel | 78041 | 3.1% |
| MIPS Technologies | 58857 | 2.3% |
| Nokia | 39676 | 1.6% |
| SANPeople | 36038 | 1.4% |
| SteelEye | 36021 | 1.4% |
| Freescale | 35034 | 1.4% |
| Linux Foundation | 34163 | 1.4% |
| MontaVista | 30211 | 1.2% |
| Simtec | 26166 | 1.0% |
| Atmel | 25975 | 1.0% |
| HP | 23714 | 0.9% |
| SGI | 22057 | 0.9% |
| Oracle | 21251 | 0.8% |
| Open Grid Computing | 20505 | 0.8% |
The end result of all this is that a number of the widely-expressed
opinions about kernel development turn out to be true. There really are
thousands of developers - at least, almost 2,000 who put in at least one
patch over the course of the last year. Linus Torvalds is directly
responsible for a very small portion of the code which makes it into the
kernel. Contemporary kernel development is spread out among a broad group
of people, most of whom are paid for the work they do. Overall, the
picture is of a broad-based and well-supported development community.
There are many other interesting things to be learned by looking at the
kernel's development history. Expect more articles along these lines as
your editor finds the time to improve his scripts.
Comments (61 posted)
Page editor: Jonathan Corbet
Security
A PostgreSQL flaw
February 21, 2007
This article was contributed by Jake Edge.
An announcement of possibly
insecure practices in user-defined PostgreSQL functions seems at first
blush to be
a fairly straightforward advisory; a deeper look reveals some serious
implications. It is a problem that echoes a textbook security hole in
UNIX setuid programs; it would appear that the developers did
not consider that history when adding a setuid-like capability to PostgreSQL.
Unfortunately, it also appears that the fix that the advisory recommends
is not up to the task of resolving the issue. Anyone using SECURITY DEFINER
functions in PostgreSQL probably has quite a large job ahead of them to
clear up this particular mess.
PostgreSQL functions can be be declared as "SECURITY DEFINER" functions, which
causes them to run with the privileges of the owner rather than those of
the invoker. PostgreSQL binds the operators and functions called at
runtime and searches each element in the schema path to find them.
Unfortunately, the
user invoking the function can control the schema search
path and, by defining operators or other functions that are used by
the SECURITY DEFINER function, the invoker can run any code with the
permissions of the owner.
The once common, now hopefully largely eradicated, UNIX parallel was a
vulnerability in setuid programs that invoked other programs via
exec(). If the
program did not either sanitize its PATH environment variable or fully
specify the path to the executable, it was vulnerable to attackers who
would put their own code in the path, with the same name as the executable,
ahead of the standard program. When the setuid program executed, it would
grab the wrong binary and the attacker could run arbitrary code with
the permissions of the owner of the setuid program. Another important
requirement is that all elements of the sanitized PATH and the directory
of the binary are not writable by non-privileged users.
So, much like the solution to the UNIX issue, the advisory suggests that
SECURITY DEFINER functions specify a sanitized schema path. The
equivalent to a fully specified path is not recommended as it is
"likely to induce mistakes and will furthermore
make the source code harder to read and maintain." Unfortunately, it
turns out that because of the way PostgreSQL processes the function
definitions, the only solution is to schema-qualify each and every function
and operator reference in the function. In addition, setting a schema
search path in a function is not local to the function, it changes the global
search path for the whole program; functions that do this should restore
the original search path on exit.
It turns out that the references in a function are resolved as PostgreSQL
creates an execution plan for the function. This is prior to actually
executing the "set search path" operation in the function and so it will bind to
functions and operators in the user controlled schema path as described
here.
The only alternative is the laborious and error-prone task of
schema-qualifying function and operator references in SECURITY DEFINER
functions.
This is a very unfortunate outcome for a feature that was meant to promote
more secure database usage. The idea is to separate the database privileges
into different users but to still allow users with few privileges to
perform a restricted set of privileged operations. It is surprising that
the UNIX setuid issues from the dawn of time_t were not more
closely studied when this feature was implemented. It would also seem that
the PostgreSQL developers will need to rework how the execution plan and
search path interact to fix this design flaw.
Comments (4 posted)
New vulnerabilities
clamav: directory traversal, denial of service
| Package(s): | clamav |
CVE #(s): | CVE-2007-0897
CVE-2007-0898
|
| Created: | February 20, 2007 |
Updated: | March 7, 2007 |
| Description: |
Clam AntiVirus ClamAV before 0.90 does not close open file descriptors
under certain conditions, which allows remote attackers to cause a denial
of service (file descriptor consumption and failed scans) via CAB archives
with a cabinet header record length of zero, which causes a function to
return without closing a file descriptor. (CVE-2007-0897)
Directory traversal vulnerability in clamd in Clam AntiVirus ClamAV before
0.90 allows remote attackers to overwrite arbitrary files via a .. (dot
dot) in the id MIME header parameter in a multi-part
message. (CVE-2007-0898) |
| Alerts: |
|
Comments (none posted)
ekiga: format string vulnerability
| Package(s): | ekiga |
CVE #(s): | CVE-2007-1006
CVE-2007-0999
|
| Created: | February 21, 2007 |
Updated: | March 30, 2007 |
| Description: |
Ekiga contains a format string vulnerability in the code which processes
control messages from remote peers.
If a user was running Ekiga and listening for incoming calls, a remote
attacker could send a crafted call request, and execute arbitrary code with
the user's privileges. |
| Alerts: |
|
Comments (none posted)
fail2ban: denial of service
| Package(s): | fail2ban |
CVE #(s): | CVE-2006-6302
|
| Created: | February 16, 2007 |
Updated: | July 30, 2007 |
| Description: |
fail2ban 0.7.4 and earlier does not properly parse sshd logs file, which
allows remote attackers to add arbitrary hosts to the /etc/hosts.deny file
and cause a denial of service by adding arbitrary IP addresses to the sshd
log file, as demonstrated by logging in to ssh using a login name
containing certain strings with an IP address. |
| Alerts: |
|
Comments (3 posted)
gnomemeeting: format string flaw
| Package(s): | gnomemeeting |
CVE #(s): | CVE-2007-1007
|
| Created: | February 20, 2007 |
Updated: | March 5, 2007 |
| Description: |
A format string flaw was found in the way GnomeMeeting processes certain
messages. If a user is running GnomeMeeting, a remote attacker who can
connect to GnomeMeeting could trigger this flaw and potentially execute
arbitrary code with the privileges of the user. |
| Alerts: |
|
Comments (none posted)
gnucash: temporary file vulnerability
| Package(s): | gnucash |
CVE #(s): | CVE-2007-0007
|
| Created: | February 21, 2007 |
Updated: | February 27, 2007 |
| Description: |
Gnucash (2.0.4 and prior) suffers from a set of symbolic link vulnerabilities. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-0007
CVE-2007-0006
|
| Created: | February 15, 2007 |
Updated: | November 14, 2007 |
| Description: |
Linux kernel versions from 2.6.9 to 2.6.20 have a denial of service
vulnerability. A remote attacker can cause the key_alloc_serial
function's key serial number collision avoidance code to have a
null dereference, resulting in a crash. |
| Alerts: |
|
Comments (1 posted)
MoinMoin: cross-site scripting and information leak
| Package(s): | moin moinmoin |
CVE #(s): | CVE-2007-0901
CVE-2007-0902
|
| Created: | February 21, 2007 |
Updated: | February 21, 2007 |
| Description: |
MoinMoin suffers from a pair of vulnerabilities. An attacker who tricks a MoinMoin user into viewing a specially-crafted URL can execute arbitrary JavaScript with the user's privileges. There is also an information disclosure vulnerability which can tell an attacker about the versions of software running on the system. |
| Alerts: |
|
Comments (none posted)
php: multiple vulnerabilities
| Package(s): | php |
CVE #(s): | CVE-2007-0906
CVE-2007-0907
CVE-2007-0908
CVE-2007-0909
CVE-2007-0910
CVE-2007-0988
|
| Created: | February 20, 2007 |
Updated: | March 21, 2007 |
| Description: |
A number of buffer overflow flaws were found in the PHP session extension,
the str_replace() function, and the imap_mail_compose() function.
If very long strings under the control of an attacker are passed to the
str_replace() function then an integer overflow could occur in memory
allocation. If a script uses the imap_mail_compose() function to create a
new MIME message based on an input body from an untrusted source, it could
result in a heap overflow. An attacker who is able to access a PHP
application affected by any these issues could trigger these flaws and
possibly execute arbitrary code as the 'apache' user. (CVE-2007-0906)
If unserializing untrusted data on 64-bit platforms, the zend_hash_init()
function can be forced to enter an infinite loop, consuming CPU resources
for a limited length of time, until the script timeout alarm aborts
execution of the script. (CVE-2007-0988)
If the wddx extension is used to import WDDX data from an untrusted source,
certain WDDX input packets may allow a random portion of heap memory to be
exposed. (CVE-2007-0908)
If the odbc_result_all() function is used to display data from a database,
and the contents of the database table are under the control of an
attacker, a format string vulnerability is possible which could lead to the
execution of arbitrary code. (CVE-2007-0909)
A one byte memory read will always occur before the beginning of a buffer,
which could be triggered for example by any use of the header() function in
a script. However it is unlikely that this would have any effect.
(CVE-2007-0907)
Several flaws in PHP could allows attackers to "clobber" certain
super-global variables via unspecified vectors. (CVE-2007-0910) |
| Alerts: |
|
Comments (none posted)
spamassassin: denial of service
| Package(s): | spamassassin |
CVE #(s): | CVE-2007-0451
|
| Created: | February 16, 2007 |
Updated: | March 14, 2007 |
| Description: |
Version 3.1.8 of Spamassassin fixes some bugs and a malformed HTML denial
of service vulnerability. |
| Alerts: |
|
Comments (none posted)
sun-jdk: arbitrary code execution
| Package(s): | sun-jdk |
CVE #(s): | CVE-2007-0243
|
| Created: | February 19, 2007 |
Updated: | April 25, 2007 |
| Description: |
A anonymous researcher discovered that an error in the handling of a GIF
image with a zero width field block leads to a memory corruption flaw. An
attacker could entice a user to run a specially crafted Java applet or
application that would load a crafted GIF image, which could result in
escalation of privileges and unauthorized access to system resources. |
| Alerts: |
|
Comments (1 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)
bind: denial of service
| Package(s): | bind |
CVE #(s): | CVE-2007-0493
CVE-2007-0494
|
| Created: | January 26, 2007 |
Updated: | March 14, 2007 |
| Description: |
The bind package is vulnerable to two remote denial of service attacks in
which attackers can cause the bind daemon to to crash or exit unexpectedly
by providing malformed data to the daemon in a DNS request. |
| Alerts: |
|
Comments (none posted)
bluez-utils: hidd vulnerability
| Package(s): | bluez-utils |
CVE #(s): | CVE-2006-6899
|
| Created: | January 16, 2007 |
Updated: | May 14, 2007 |
| Description: |
hidd in BlueZ (bluez-utils) before 2.25 allows remote attackers to obtain
control of the Mouse and Keyboard Human Interface Device (HID) via a
certain configuration of two HID (PSM) endpoints, operating as a server,
aka HidAttack. |
| Alerts: |
|
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)
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)
dovecot: index cache file handling error
| Package(s): | dovecot |
CVE #(s): | CVE-2006-5973
|
| Created: | November 29, 2006 |
Updated: | May 8, 2007 |
| Description: |
The dovecot IMAP server has an error in its index cache file handling code which could be exploited by an authenticated user to execute arbitrary code. Only servers with the (non-default) mmap_disable=yes option setting are vulnerable. |
| Alerts: |
|
Comments (none posted)
fetchmail: password disclosure and DOS
| Package(s): | fetchmail |
CVE #(s): | CVE-2006-5867
CVE-2006-5974
|
| Created: | January 9, 2007 |
Updated: | March 16, 2007 |
| Description: |
Fetchmail suffers from a password disclosure vulnerability due to a failure to use secure protocols (advisory) and a denial of service vulnerability (advisory). |
| 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)
Mozilla stuff: multiple vulnerabilities
Comments (none 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)
gd: buffer overflow
| Package(s): | gd |
CVE #(s): | CVE-2007-0455
|
| Created: | February 7, 2007 |
Updated: | February 28, 2008 |
| Description: |
The gd graphics library contains a buffer overflow which could enable a remote attacker to execute arbitrary code. Note that various other packages include code from gd and could also be vulnerable. |
| Alerts: |
|
Comments (2 posted)
gdb: buffer overflow
| Package(s): | gdb |
CVE #(s): | CVE-2006-4146
|
| Created: | September 15, 2006 |
Updated: | June 12, 2007 |
| Description: |
A buffer overflow in dwarfread.c and dwarf2read.c debugging code in GNU
Debugger (GDB) 6.5 allows user-assisted attackers, or restricted users, to
execute arbitrary code via a crafted file with a location block
(DW_FORM_block) that contains a large number of operations. |
| Alerts: |
|
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)
gnupg: stack overwrite
| Package(s): | gnupg |
CVE #(s): | CVE-2006-6235
|
| Created: | December 12, 2006 |
Updated: | March 13, 2007 |
| Description: |
A "stack overwrite" vulnerability in GnuPG (gpg) allows attackers to
execute arbitrary code via crafted OpenPGP packets that cause GnuPG to
dereference a function pointer from deallocated stack memory. |
| Alerts: |
|
Comments (3 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)
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)
horde-kronolith: local file inclusion
| Package(s): | horde-kronolith |
CVE #(s): | CVE-2006-6175
|
| Created: | January 17, 2007 |
Updated: | March 7, 2008 |
| Description: |
Kronolith contains a mistake in lib/FBView.php where a raw, unfiltered
string is used instead of a sanitized string to view local files. An
authenticated attacker could craft an HTTP GET request that uses directory
traversal techniques to execute any file on the web server as PHP code,
which could allow information disclosure or arbitrary code execution with
the rights of the user running the PHP application (usually the webserver
user). |
| Alerts: |
|
Comments (none posted)
imagemagick: buffer overflows
| Package(s): | imagemagick |
CVE #(s): | CVE-2006-5868
|
| Created: | November 28, 2006 |
Updated: | February 16, 2007 |
| Description: |
Daniel Kobras discovered multiple buffer overflows in ImageMagick's SGI
file format decoder. By tricking a user or an automated system into
processing a specially crafted SGI image, this could be exploited to
execute arbitrary code with the user's privileges. |
| Alerts: |
|
Comments (1 posted)
ImageMagick: buffer overflow
| Package(s): | imagemagick |
CVE #(s): | CVE-2007-0770
|
| Created: | February 12, 2007 |
Updated: | February 16, 2007 |
| Description: |
Vladimir Nadvornik discovered a buffer overflow in GraphicsMagick and
ImageMagick allows user-assisted attackers to cause a denial of service and
possibly execute execute arbitrary code via a PALM image that is not
properly handled by the ReadPALMImage function in coders/palm.c. |
| Alerts: |
|
Comments (1 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: |
|