The birth of the open source enterprise stack
June 26, 2006
This article was contributed by Glyn Moody
For the first ten years of its life, free software was largely a hacker's tool. All the early programs Emacs, GCC, Perl, Linux were written by coders for coders (usually themselves). It was the rapid uptake of the Internet by business in the mid-1990s that led to free software being used by companies, not just their employees.
The unplanned nature of this move online meant that computer departments were often asked to create a Web presence without being allocated extra funds. Free software was the obvious solution. The ready availability of GNU/Linux and Apache, whose first official release had appeared in December 1995, meant both were soon found in many companies, but generally unofficially. Software engineers knew it was easier simply to install the code than to go through formal approval processes that were bound to be skeptical of this new kind of software. The same was true for Samba, which allowed IT departments to add low-cost file and print servers to Windows networks.
At this stage, then, free software was on the periphery of companies, providing non-critical functions, and often invisibly as far as management was concerned. Gradually, though, word got out about the reliability and attractive price-performance characteristics of free software in general, and GNU/Linux in particular.
Similarly, software suppliers were discovering that their engineers were not only using free software but sometimes had even ported major proprietary software packages to GNU/Linux on their own initiative as happened with Software AG's Adabas D database, which shipped in 1996 as part of the Caldera Solutions CD. This fact, together with the growing use of GNU/Linux within companies, prompted the release in 1998 of official ports of the main enterprise-level databases: those from Oracle and Informix in July, and IBM's in December. It was a significant moment in the rise of open source in companies: free software was now countenanced officially, and started to play a mission-critical role.
At the same time, free software began to provide more complex business solutions through the deployment of what came to be termed the LAMP stack: GNU/Linux, Apache, MySQL and Perl/PHP/Python - the term LAMP was coined in 1998 by Michael Kunze in the German c't magazine. The stack represented a more sophisticated version of the approach based around the earlier Common Gateway Interface, which was used to interface Web servers with external applications like databases.
MySQL had first appeared in 1995. As well as representing an important breakthrough for open source application software in the enterprise, it also brought with it a new business model. In the beginning, the copyright for open source code had either been assigned to the Free Software Foundation to allow more effective enforcement of the GNU GPL, or remained with the various individual coders who had contributed. In the case of the MySQL code, though, it is the software house MySQL AB, which was created around the software, that owns all the copyrights.
Because of this, MySQL AB is able to employ a dual-licensing policy, offering its database under the GNU GPL or a commercial license. Some have seen this development as a threat to the core ethos of the open source world, because it raises the specter of a new, more subtle kind of vendor lock-in. Although the most popular, MySQL is by no means the only free database program: others include Firebird, Ingres and PostgreSQL.
The early years of the 21st century were ones of steady gains for free software within the enterprise. In the wake of the dotcom crash, which saw first-generation open source companies like Linuxcare, TurboLinux and VA Linux scaling back their operations dramatically, there were relatively few venture capitalists or IT start-ups that were willing to take a chance on new areas of free software. But corporate use of GNU/Linux in particular flourished, as the free operating system was increasingly used to save money by allowing companies to move from expensive proprietary hardware running Unix to commodity systems based on Intel processors.
One open source company that did appear during this time was Gluecode. It offered a commercial version of Apache Geronimo, the J2EE server project of the Apache Foundation. This was an important development, because it moved open source closer to the heart of the enterprise. Gluecode received a validation of sorts in 2005, when IBM bought the company, and added the open source product to its WebSphere Application Server line as a Community Edition.
IBM presumably preferred to cannibalize its own sales rather than see another increasingly-popular open source middleware company, JBoss, do the same. The JBoss project began in 1999, and, like MySQL, introduced a novel business approach to working with open source. It effectively commissions code for free software projects by hiring their top coders, thereby adding an element of commercial direction to the open source development process that was hitherto lacking. Also like MySQL, JBoss the company generally retains the copyright in the JBoss code. The JBoss way received its own vote of confidence when the company was acquired in April 2006 for $350 million by Red Hat, after being courted by Oracle, which has been on something of an open source spending spree.
The acquisition of Gluecode and JBoss, and Oracle's interest in the latter, firmly establishes middleware as the new hotspot for enterprise open source. Alongside IBM's WebSphere Application Server Community Edition and JBoss, there are several other free programs, including Enhydra, JOnAS and WSO2 Tungsten. Together, they represent a key piece in the creation of an open source enterprise stack, with GNU/Linux as the foundation.
It is here, rather than on the desktop, that free software's next big gains are likely to take place, and a subsequent feature will explore the surprising richness of the upper layers of the emerging open source enterprise stack, in areas such as systems management, customer relationship management, business intelligence, enterprise content management, enterprise resource planning and communications.
Glyn Moody writes about open source at opendotdotdot.
Comments (31 posted)
Interview: Jim Gettys (Part I)
Jim Gettys has a long history at the interesting edge of computing
development; his past projects include MIT's Project Athena and the X
Window System. Currently, Jim is working on the
One Laptop Per Child project, which seeks to
distribute low-cost, Linux-based systems by the millions to children in the
developing world.
Jim was kind enough to take what must have been a considerable amount of
time to answer our questions on this project. What follows is the first
part of the interview.
LWN: Could you briefly describe your role with the OLPC project?
Vice President of Software: in short, I worry about systems software
from one end of the project to the other and relations with the free and
open source software community.
The educational software and content are the province of others:
Nicholas Negroponte (the OLPC chairman), Walter Bender, Seymour Papert, Alan Kay, and
others, who have decades of experience in education of children with
computers, often in the developing world.
I also don't worry about how the bits get from machine to machine:
Michail Bletsas is our Chief Connectivity Officer.
Mary Lou Jepsen is our CTO, and responsible for our novel display
technology, and Mark Foster is V.P. of Engineering and chief hardware
architect.
Quanta Computers, founded by Barry Lam, who make almost 1/3 of the
laptops of the world, are building the OLPC machine.
It appears that few people appreciate the extent to which this project is
pushing the leading edge of free software development.
Our hardware is novel to meet the needs of children in the developing
world; much of the software we need to build in the short term are
driven by this novelty. We expect many of our innovations will appear in
conventional laptops over the coming years. In this case, Linux will be
leading rather than following the industry.
What are the features one would want for school-aged children, grades K-12?
A large fraction of such children are in parts of the developing
world where electricity is not available at home, or often even at
school, so for many children, a computer with low power consumption,
potentially human-powered, is a necessity, not a convenience.
Teaching may not even be inside, and certainly when children are at
home, they often will not be inside where conventional LCD screens are
usable. Children usually walk to and from school every day; weather is
unpredictable, rain, dirt and dust are commonplace. And cost is a major
consideration, if we are to bring computers and their great power to
help children learn, to children everywhere.
Much more about the hardware can be found in our wiki.
Consider the power
management issues, application slimming, system (non-)management
improvements, mesh networking, application checkpointing, pervasive IPv6,
localization problems, etc. Every one of these goals should benefit users
who will never see an OLPC system. How many of these goals do you think
you will be able to achieve by launch time?
Some of these items are all-or-nothing: others are suitable to
incremental progress. Let's take them one at a time.
Power management: We are doing at least two, if not three, true
innovations in this area:
- The Marvell wireless chip, which has an ARM 9 and 92K of RAM, can
forward packets in the mesh network while the processor is suspended to
RAM. This capability has been demonstrated in the lab, and Michail
Bletsas is confident of the outcome; in fact, it was an actual
demonstration that convinced us to use Marvell. Other wireless vendors
lack this capability. Our current estimate is that in this mode, the
wireless chip can be forwarding packets and the system consuming less
than a half a watt. We want there to be as little incentive to defeat
wireless as possible, so this is a key innovation: if children aren't
confident there will be power when they need it, they might work to
defeat the mesh.
- The display can be on while the processor is suspended, saving
power. In some modes, we expect to be suspending the CPU whenever it is
idle, even for times as low as a second or two. Since our display is
also novel and consumes much less power than conventional LCD's, even
the Geode's low power consumption would have otherwise dominated total
energy use.
- Look around you the next time you sit in a conference room. How
many of you are actively using your machine at any given instant? How
much of the time are you just reading the screen? In many modes of use,
once the screen power consumption has been solved (as it is in our
display), the remaining major power consumption is the processor, power
supply and motherboard components. By making suspend/resume
unnoticeable, we can save most of the remaining power used in the
system.
Mark Foster described his novel extremely fast suspend/resume software
technique at the Linux Power Management Summit this spring. Whether we
will need to implement it on our hardware to reach our goals of < 200ms
suspend/resume cycles awaits some laboratory tests (an iPAQ can already
suspend and resume in a subsecond period), but I expect we may need to
implement this technique. Any performance work *must* be preceded by
measurement to be useful: spending time optimizing the wrong code is a
waste. Of course, the faster suspend/resume can be made to work, the
more aggressive we can about suspending and saving power. This is an
example of an area where incremental improvement (once basic
capabilities) is possible.
We are also planning to dynamically change the refresh rate of the
screen depending on screen activity; as I've seen this capability in
graphics chips for cell phones, I won't claim this as full innovative,
though it will be new for the X Window System or window systems on
laptops.
It is hard to predict how long similar hardware capabilities will take
to reach conventional hardware; but by showing it is possible, we know
it will happen and the software support required be useful to everyone.
There are also a number of places where changes in Linux and the desktop
environment can help. For example, the tickless patches currently being
worked on obviate the need for the CPU to wake up 100 times a second;
the more of the time a processor is fully idle, the more power saved.
Another example are places where the desktop environments are polling
periodically to find out changes in the system: notification systems are
much more efficient, and allow the system to be idle more of the time.
Out of memory behavior needs serious work: the current OOM killer's
policies are by current necessity very poor. Nokia has been
experimenting with more useful policies, exploiting information at the
user environment level, that can improve this behavior by informing the
kernel which processes are the most vital and which can be shot.
Application slimming:
There seems to be a common fallacy among programmers that using memory
is good: on current hardware it is often much faster to recompute values than to
have to reference memory to get a precomputed value. A full cache miss
can be hundreds of cycles, and hundreds of times the power consumption
of an instruction that hits in the first level cache. Making things
smaller almost always makes them faster (and lower power). Similarly, it
can be much faster to redraw an area of the screen than to copy a saved
image from RAM to a screen buffer. Many programmer's presumptions are
now completely incorrect and we need to reeducate ourselves.
Sometimes we may just choose alternative applications. Of course, this
may not be what some application writers would like, and the solution
they can take is obvious. We have a large set of software to choose
from: this is one of open source's great strengths.
Federico Mena-Quintera
and others have
been doing some very
nice work identifying and fixing some of the
gratuitous memory usage.
A large part of this task is raising people's consciousness that we've
become very sloppy on memory usage, and often there is low hanging fruit
making things use less memory (and execute faster and use less power as
a result). Sometimes it is poor design of memory usage, and sometimes it
is out and out bugs leaking memory. On our class of a system, leaks are
of really serious concern: we don't want to be paging to our limited
size flash.
In fact, much of the performance unpredictability of today's free
desktop can be attributed to the fact that several of our major
applications are wasting/leaking memory and driving even systems with
half a gigabyte of memory or more to paging quite quickly. Some of
these applications we care about, and some we don't: OpenOffice is just
not the right tool for someone learning to read and write, and we'll be
perfectly happy to use other tools. Some other major offenders need
fixing (and work has started): e.g. Firefox (Gecko), which, when using
tabs, has been hemorrhaging memory, which can force you to paging quite
quickly. Between evolution-data-server and Firefox alone, many people's
desktops exhibit unpredictable performance soon after boot due to
paging; fixing these problems will benefit all.
Tools:
The memory usage display tools we have today are very misleading to
naive (and even journeyman) programmers, often leading them to massively
wrong conclusions.
My biggest personal frustration (given my history with X) are people
saying: "X is bloated". The reality is: a) X maps all the frame buffer
and/or register space into its address space, so measurement of virtual
address spaced used is completely misleading: X may be actually
consuming only a very small amount of your DRAM, despite a virtual size
of a hundred megabytes, and b) X does what its told: many applications
seem to think that storing pixmaps in the X server (and often forgetting
about them entirely) is a good strategy, whereas retransmitting or
repainting the pixmap may be both faster and use less memory. Once in a
while there is a memory leak in X (generally in the graphics drivers):
but almost always the problem are leaks in applications, which often
forget the pixmaps they were using.
RAM in the X server is just as much RAM of your program, though it is in
a different address space. People forget that the X Window System was
developed on systems with 2 meg of RAM, and works today on 16 megabyte
iPAQ handhelds.
We need better tools; some are beginning to appear. OLPC is sponsoring
a Google Summer of Code student, Eduardo Silva, from Chile, who is
working on a new tool called Memphis to help with this problem.
Work done on memory consumption will benefit everyone: not everyone in
the world has a 2ghz laptop with a gig or two of RAM...
System (non-)management improvements:
I think there are two, mostly separable areas here:
1) the kid's laptop, on which we want to focus primarily on making "easy
to fix", rather than "hard to break", so interested children can learn
computing. And by working hard to automate backup, we'd like the restore
of a laptop to be dead simple if there is some problem. By using
LinuxBIOS, we expect to be able to boot and reinstall via the network
easily. Requiring cables and/or USB keys for restore are costly and
complicate logistics greatly.
2) the school servers need to be "hard to break" as well as "easy to
fix", and remotely manageable, as finding expertise a remote school of
10 children and one teacher is very unlikely. This is one of the
factors driving us to IPv6 (much more below), since NATed IPv4 islands
cannot be easily remotely diagnosed or updated automatically without
expertise on the ground, which will often be rare in our deployment
areas.
I've recently become impressed by technology developed for and by
PlanetLab that Dave Reed brought to my attention. It is worth
everyone's careful look. See (www.planet-lab.org).
Mesh networking:
Pulling wires and having access points are very expensive and requires
expertise, neither of which may be available; and we want kids to be
able to work together anytime they meet up, even under a tree 3
kilometers from nowhere.
MIT Roofnet and other
projects have shown the feasibility of mesh networking, where one
machine forwards packets on behalf of others. Michail Bletsas is OLPC's
expert in this area, and has a lot of first hand experience. In radio
quiet areas, quite long links become feasible; in urban areas much
shorter links are only feasible, but the density of machines is likely
much higher.
Our system is interesting in a number of ways beyond mesh software:
- it has antennae that can be rotated up above the top of the machine
and are more efficient than what you find in a conventional laptop; this
should roughly increase the footprint of each machine by a factor of
four (in area).
- the Marvell wireless chip we are using can operate autonomously. So
it can forward packets in the mesh even if the processor is suspended to
RAM! This should cut power consumption for an unused laptop to well
under one watt (current estimate is about .5 watts), while still
providing support to other machines in the mesh.
One of the challenges that the community can help later this year is to
help learn which techniques work best when the nodes of the mesh are
mobile machines. There are a number of routing protocols possible (some
of which should become power aware; not all machines may need to bother
to forward packets all the time), and which will work best in what
circumstances should be fun to learn.
Application checkpointing:
128 megabytes of memory is enough to run (almost) any open source
application; there are a few exceptions, but few that are of educational
interest for young children. It isn't enough, on a system where paging
needs to be avoided, to run arbitrary numbers of the larger applications
at the same time.
In addition to the community working on dieting our environment (and
making it run faster as a result), application check-pointing could help
the user's experience greatly. When memory runs low, idle applications
not currently in use could save their state and be restarted later at
the same point. We see some of this being done in Maemo on the Nokia
770; the conventions for this need freedesktop codification and
implementation in applications.
Pervasive IPv6:
In the developed world, we do not have a shortage of IPv4 addresses at
this time. We got to the Internet first, and grabbed enough "land" that
we don't yet feel the pain felt in other parts of the world.
We see differently from where we sit.
IPv6 to us is clearly essential on a number of grounds:
- address space, and not wanting a flag day conversion that would be
very difficult. There are good
arguments that we have effectively exhausted the IPv4 address space, and that even
conservation measures cannot change the situation by more than a year or
two. In the developing world the situation is already dire. In some
places, entire universities are hidden behind a single routable IPv4
address, and in others, NAT's are as much as 5 levels deep.
Vint Cerf told us that part of this problem is artificial: some cultures
are so worried about losing face if they were turned down that they have
not been asking for addresses, even though they would have been granted.
And part of it is very real indeed: Brazil is planning a deployment of
100,000,000 IP TV sets, for example; this cannot be done using IPv4. And
we hope to be deploying at such scale within a few years as well. Since
the cliff is already visible and we'd just as soon not fall off it; it
hurts so bad when you hit the bottom.
- it is impossible to diagnose problems if you can't observe them.
Initially, in many parts of the world, we have to presume limited
expertise is available on the ground, so local diagnosis could easily
become the limiting factor for deployment. If the school networks are
fragmented by NAT's, remote diagnosis becomes much more complicated.
- Building collaborative applications (or almost any new network
application) has become extremely difficult due to the extensive
deployment of NATs in the Internet: Skype is one of the few
applications, that by standing on its head in many ways, has succeeded
in (usually) working despite this disaster. Building such applications
becomes radically easier if we go back to the end to end principles
of
the Internet. NAT has made it
very difficult to deploy new applications.
Given tunneling technology (and 6to4, when routable addresses are
available), in concert with the IPv6 deployment that has begun in many
parts of the world, we can again have a clean end-to-end network, in
which kids anywhere can share with their peers all over the world.
So our judgment is that he time has really come, and (almost) all
applications are finally ready.
Localization problems:
According to the Ethnologue
web site,
there are 347 languages
with more than one million speakers in the world, that covers 94% of the world's population.
We already see localization in open source systems for languages with fewer
speakers - one
million speakers. If we continue along the current path of localization, we're going to
find ourselves with a real problem within several years.
While I expect the current mechanisms and processes might get us through the first round of
deployments, the year after, this problem will become more acute. As a community, we
need to recognize this approaching problem and rise to the challenge. I wrote
in more detail in my blog.
Are you getting the needed
level of assistance from the community in reaching these goals?
It has been hard for people to help on the base hardware support, though
as the first few boards were distributed over the last month this has
been changing: this is about to change in a big way with our developer's
program.
We are distributing almost 500 bare mother boards to enable people to
help on drivers, power management, code optimization (which not only
makes things faster, but reduces power consumption), mesh network
experimentation, etc. And there will be further opportunities later in
the program during beta test later this year.
What do
you most urgently need help with at this time?
Power management is one key problem. And it can be subtle and indirect:
slow code, or bloated code, also wastes power.
The memory consumption problems, and how to manage low memory situations
is also key. It would help greatly if applications would bother to be
able to checkpoint their state and restart exactly where they left off.
Let's take one of those goals: paring down applications so that they fit
into the OLPC's memory. This is clearly an activity which benefits
everybody - bloated applications are slow applications. Are you making
progress in putting the needed tools on a diet?
There are only a few things we are doing ourselves at this instant; the
responsibility for these problems is distributed among a myriad of
projects.
We have a simple principle everyone should be aware of: if your
application is bloated, it's much less likely people will be able to use
it on the machine. There are usually alternatives for any particular
piece of software. Given the healthy competition in free software, there
is only a much smaller subset of software that we care about to the
point of fixing it ourselves. If you want your software to be usable,
please make it so: and everyone will benefit with leaner, faster
applications, not only OLPC.
How are the upstream
communities responding to debloating patches?
In most areas, we're still pedal to the metal on basic problems like
device drivers, and finishing up LinuxBIOS + Linux as boot loader so
that we can support installation over the (mesh) network. Ron Minnich
and Ollie Lo of LANL and the LinuxBIOS community are rising to the
challenge.
Often, rather than patches, it is helping people understand there are
problems that need to be fixed. Chris Blizzard, who is on the board of
the Mozilla corporation, now works on OLPC (he's in charge of the Red
Hat team), and the Firefox team are finally aware they have a serious
problem and test cases are being generated. Chris says some progress has
already been made. Much more is needed, and there are viable
alternatives we could use if Firefox does not come through. But we think
they probably will by the time we will ship in volume.
Many thanks to Jim Gettys for taking the time to answer these questions.
The second part of the interview will appear next week.
Comments (27 posted)
LWN schedule for next week
The LWN staff has decided to take some time off for the U.S. Independence
Day holiday on July 4. As a result in the weekly edition will be published
late on July 6. We apologize for any inconvenience.
Comments (2 posted)
Page editor: Rebecca Sobol
Security
Security news
A roundup of other email proposals
June 28, 2006
This article was contributed by Jake Edge.
Over the past two weeks, this page has looked at two of the more widely
known proposals for improving the email infrastructure:
Sender Policy Framework (SPF) and
Domain Keys (DK).
This week will conclude the series by
looking at a few lesser known proposals and describe the kinds of problems
they are meant to solve.
Due to
joe jobs and other
spammer tricks, sites can sometimes be overwhelmed with bounce messages
from emails that they did not send. Two proposals provide ways for
the receivers of bounce messages (i.e. the domain that purportedly sent
the original message) to recognize invalid bounces before accepting the email.
Both
Signed
Envelope Sender (SES) and
Bounce Address Tag Validation (BATV)
are focused on eliminating invalid bounce messages.
Both techniques rely on using a uniquely generated envelope sender
for each outgoing mail, typically with a one-way hash or cryptographic
mechanism that can be verified by the sending Mail Transfer Agent (MTA).
When a bounce message arrives, it will have a null envelope sender
(to prevent loops) and an envelope recipient. If the MTA cannot verify
the envelope recipient as one of the uniquely generated addresses, it can
reject the email before receiving the DATA portion. This protection against
invalid bounce messages is one that can be unilaterally implemented by a
sending domain and will benefit that domain without requiring any
cooperation from other MTAs.
Both SES and BATV have ways to generate envelope sender addresses that
allow intermediary MTAs to verify the sender and determine if the email
was truly sent by the domain that purports to have sent it. In addition,
any hosts that use
SMTP sender address verification will be able to reject forged email
envelope sender addresses in domains that use SES/BATV because the
verification will fail for addresses that are not correctly generated.
Certified Server Validation (CSV)
is a technique that can arguably replace all of the trust evaluation that
SPF provides, but can do it in a more straightforward manner. By using the
hostname given in the SMTP HELO/EHLO command and a SRV record that has been
queried from the DNS, a receiving MTA can determine if the sending host has
correctly identified itself. In addition, the DNS record will indicate
whether the host is authorized to transfer mail for the domain.
All of the proposals and techniques that have been described in these three
articles are incremental changes to thwart one or more deficiencies in the
original design of SMTP. Because it was designed at a time when there were
few, if any, malicious users of the internet, security and authentication
were not major considerations.
More radical, non-incremental, changes to
how email is handled, such as Daniel J. Bernstein's
Internet Mail 2000 (IM2000)
have been proposed, but would require a wholesale shift in MTA and Mail
User Agent (MUA) software to implement them. Instead of email receivers
storing messages, IM2000 requires senders to store the messages and, at
least partially, attempts to burden the sender with
the costs of the email, rather than today's system which really only
burdens the recipient.
A descendant of IM2000
called
Differentiated
Mail Transfer Protocol (DMTP) is currently being worked on as a
potential internet standard.
Even if some SMTP alternative were to become an internet standard, it
remains to be seen how many users and mail servers would make the switch.
SMTP has a huge amount of inertia behind it and any replacement is likely to
be a long time in coming and have an adoption rate reminiscent of
IPv6.
Comments (4 posted)
New vulnerabilities
EnergyMech: denial of service
| Package(s): | emech |
CVE #(s): | |
| Created: | June 27, 2006 |
Updated: | June 28, 2006 |
| Description: |
A bug in EnergyMech fails to handle empty CTCP NOTICEs correctly, and
will cause a crash from a segmentation fault. By sending an empty CTCP
NOTICE, a remote attacker could exploit this vulnerability to cause a
denial of service. |
| Alerts: |
|
Comments (none posted)
Hashcash: possible heap overflow
| Package(s): | hashcash |
CVE #(s): | CVE-2006-3251
|
| Created: | June 27, 2006 |
Updated: | July 21, 2006 |
| Description: |
Andreas Seltenreich has reported a possible heap overflow in the
array_push() function in hashcash.c, as a result of an incorrect amount
of allocated memory for the "ARRAY" structure. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2006-2445
CVE-2006-2448
CVE-2006-3085
|
| Created: | June 23, 2006 |
Updated: | August 11, 2006 |
| Description: |
There is a race condition error in the "posix-cpu-timers.c" script that
does not prevent another CPU from attaching the timer to an exiting
process. This could be exploited by attackers to cause a denial of
service.
A flaw due to errors in "powerpc/kernel/signal_32.c" and
"powerpc/kernel/signal_32.c" could allow userspace to provoke a machine
check on 32-bit kernels.
An infinite loop in "netfilter/xt_sctp.c" could be exploited by attackers
to exhaust all available memory resources, creating a denial of service
condition. |
| Alerts: |
|
Comments (none posted)
mutt: IMAP namespace buffer overflow
| Package(s): | mutt |
CVE #(s): | CVE-2006-3242
|
| Created: | June 28, 2006 |
Updated: | October 24, 2006 |
| Description: |
TAKAHASHI Tamotsu discovered that mutt's IMAP backend did not sufficiently
check the validity of namespace strings. If an user connects to a malicious
IMAP server, that server could exploit this to crash mutt or even execute
arbitrary code with the privileges of the mutt user. See this Secunia advisory for more
information. |
| Alerts: |
|
Comments (none posted)
mysql: denial of service
| Package(s): | mysql |
CVE #(s): | CVE-2006-3081
|
| Created: | June 23, 2006 |
Updated: | July 18, 2006 |
| Description: |
Mysqld in MySQL 4.1.x before 4.1.18, 5.0.x before 5.0.19, and 5.1.x before
5.1.6 allows remote authorized users to cause a denial of service (crash)
via a NULL second argument to the str_to_date function. |
| Alerts: |
|
Comments (none posted)
pinball: privilege escalation
| Package(s): | pinball |
CVE #(s): | CVE-2006-2196
|
| Created: | June 26, 2006 |
Updated: | June 28, 2006 |
| Description: |
Pinball, a pinball game simulator, has a privilege escalation
vulnerability in which the application can be tricked into loading
level plugins from user-controlled directories without dropping
its privileges. |
| Alerts: |
|
Comments (none posted)
png: buffer overflow
| Package(s): | png |
CVE #(s): | |
| Created: | June 28, 2006 |
Updated: | June 28, 2006 |
| Description: |
The Portable Network Graphics (PNG) library contains a vulnerability caused
by a potential sprintf(3) related buffer overflow. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
aRts: privilege escalation
| Package(s): | arts |
CVE #(s): | CVE-2006-2916
|
| Created: | June 16, 2006 |
Updated: | June 28, 2006 |
| Description: |
artswrapper in aRts, when running setuid root on Linux 2.6.0 or later
versions, does not check the return value of the setuid function call,
which allows local users to gain root privileges by causing setuid to fail,
which prevents artsd from dropping privileges. |
| Alerts: |
|
Comments (none posted)
asterisk: buffer overflow
| Package(s): | asterisk |
CVE #(s): | CVE-2006-2898
|
| Created: | June 15, 2006 |
Updated: | July 27, 2006 |
| Description: |
The Asterisk PBX application has a buffer overflow vulnerability in the
IAX2 channel driver that can be used for the remote execution of
arbitrary code.
|
| Alerts: |
|
Comments (none posted)
binutils: buffer overflow
| Package(s): | binutils |
CVE #(s): | CVE-2006-2362
|
| Created: | May 27, 2006 |
Updated: | August 29, 2006 |
| Description: |
The GNU Binutils has a buffer overflow vulnerability in libbfd.
Maliciously crafted Tektronix Hex Format files with improper length
characters can cause a crash and possibly lead to the execution of
arbitrary code. |
| 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)
ktools: buffer overflow
| Package(s): | centericq |
CVE #(s): | CVE-2005-3863
|
| Created: | December 7, 2005 |
Updated: | August 29, 2006 |
| Description: |
From the Debian-Testing alert: Mehdi Oudad "deepfear" and Kevin Fernandez "Siegfried" from the Zone-H
Research Team discovered a buffer overflow in kkstrtext.h of the ktools
library, which is included in (at least) centericq and motor. |
| Alerts: |
|
Comments (none posted)
courier: denial of service
| Package(s): | courier |
CVE #(s): | CVE-2006-2659
|
| Created: | June 9, 2006 |
Updated: | August 4, 2006 |
| Description: |
A denial of service vulnerability has been found in the function for
encoding email addresses. Addresses containing a '=' before the '@'
character caused the Courier to hang in an endless loop, rendering the
service unusable. |
| Alerts: |
|
Comments (none 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)
vixie-cron: privilege escalation
| Package(s): | cron |
CVE #(s): | CVE-2006-2607
|
| Created: | May 31, 2006 |
Updated: | July 13, 2006 |
| Description: |
The Vixie cron daemon does not check the return code from setuid(); if that call can be made to fail, a local attacker may be able to execute commands as root. |
| Alerts: |
|
Comments (1 posted)
curl: heap-based buffer overflow
| Package(s): | curl |
CVE #(s): | CVE-2006-1061
|
| Created: | March 21, 2006 |
Updated: | June 28, 2006 |
| Description: |
Heap-based buffer overflow in cURL and libcURL 7.15.0 through 7.15.2 allows
remote attackers to execute arbitrary commands via a TFTP URL (tftp://)
with a valid hostname and a long path. |
| 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)
dokuwiki: PHP code injection
| Package(s): | dokuwiki |
CVE #(s): | CVE-2006-2878
|
| Created: | June 15, 2006 |
Updated: | June 21, 2006 |
| Description: |
The DokuWiki spell checker has a PHP code injection vulnerability,
arbitrary PHP commands can be executed without proper authentication. |
| 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)
gdb: multiple vulnerabilities
| Package(s): | gdb |
CVE #(s): | CAN-2005-1704
CAN-2005-1705
|
| Created: | May 20, 2005 |
Updated: | August 11, 2006 |
| Description: |
Tavis Ormandy of the Gentoo Linux Security Audit Team discovered an integer
overflow in the BFD library, resulting in a heap overflow. A review also
showed that by default, gdb insecurely sources initialization files from
the working directory. Successful exploitation would result in the
execution of arbitrary code on loading a specially crafted object file or
the execution of arbitrary commands. |
| Alerts: |
|
Comments (5 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: remote denial of service
| Package(s): | gnupg |
CVE #(s): | CVE-2006-3082
|
| Created: | June 21, 2006 |
Updated: | July 28, 2006 |
| Description: |
A vulnerability was discovered in GnuPG 1.4.3 and 1.9.20 (and earlier) that
could allow a remote attacker to cause gpg to crash and possibly overwrite
memory via a message packet with a large length. |
| 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)
horde: missing input sanitizing
| Package(s): | horde |
CVE #(s): | CVE-2006-2195
|
| Created: | June 15, 2006 |
Updated: | June 29, 2006 |
| Description: |
The Horde3 web application framework does not perform sufficient
input sanitizing, allowing the possible injection of web
script code through a cross-site scripting attack. |
| Alerts: |
|
Comments (none posted)
ImageMagick: heap overflow vulnerability
| Package(s): | ImageMagick |
CVE #(s): | CVE-2006-2440
|
| Created: | May 25, 2006 |
Updated: | September 5, 2006 |
| Description: |
The ImageMagick DisplayImageCommand has a heap overflow vulnerability.
If an maliciously created unexpanded glob is passed to ImageMagick,
a heap overflow can result. |
| Alerts: |
|
Comments (none posted)
kdebase: local root vulnerability
| Package(s): | kdebase |
CVE #(s): | CAN-2005-2494
|
| Created: | September 7, 2005 |
Updated: | August 11, 2006 |
| Description: |
The kdebase package (and kcheckpass in particular) found in KDE versions 3.2.0 through 3.4.2 suffers from a lock file handling error which can enable a local attacker to obtain root access. See this advisory for details. |
| Alerts: |
|
Comments (none posted)
kdebase: privilege escalation
| Package(s): | kdebase |
CVE #(s): | CVE-2006-2449
|
| Created: | June 15, 2006 |
Updated: | August 28, 2006 |
| Description: |
The KDE Display Manager(KDM) is vulnerable to a local symlink attack.
A local user can use this to read arbitrary files that they do not
have permission to access. See this KDE
advisory for more information. |
| 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: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2006-2271
CVE-2006-2272
CVE-2006-2274
CVE-2006-2275
CVE-2006-1864
|
| Created: | May 12, 2006 |
Updated: | July 13, 2006 |
| Description: |
Multiple vulnerabilities in the Linux have been found.
- An error in the Stream Control Transmission Protocol (SCTP) code that
uses incorrect state table entries when certain ECNE chunks are received in
CLOSED state, could be exploited by attackers to cause a kernel panic via a
specially crafted packet.
- An error exist when handling incoming IP-fragmented SCTP control
chunks, which could be exploited by attackers to cause a kernel panic via a
specially crafted packet.
- Linux SCTP (lksctp) allows remote attackers to cause a denial of
service (infinite recursion and crash) via a packet that contains two or
more DATA fragments, which causes an skb pointer to refer back to itself
when the full message is reassembled, leading to infinite recursion in the
sctp_skb_pull function
- Linux SCTP (lksctp) allows remote attackers to cause a denial of
service (deadlock) via a large number of small messages to a receiver
application that cannot process the messages quickly enough, which leads to
"spillover of the receive buffer."
- A vulnerability has been identified due to an input validation error
when processing arguments containing backslash ("\\") characters passed to
certain commands (e.g. "cd"), which could be exploited by authenticated
attackers to escape chroot restrictions for a CIFS or SMBFS mounted
filesystem.
|
| Alerts: |
|
Comments (none posted)
kernel: netfilter memory corruption
| Package(s): | kernel |
CVE #(s): | CVE-2006-2444
|
| Created: | May 25, 2006 |
Updated: | July 5, 2006 |
| Description: |
The 2.6.12 kernel has a remote memory corruption vulnerability
that can be remotely triggered by loading the ip_nat_snmp_basic
module and traffic is network-translated on port 161 or 162. |
| Alerts: |
|
Comments (none posted)
kernel: information disclosure
| Package(s): | kernel |
CVE #(s): | CVE-2006-1343
|
| Created: | May 31, 2006 |
Updated: | July 20, 2006 |
| Description: |
The 2.6 kernel netfilter code contains an information leak; this vulnerability has been fixed in the 2.6.16.19 release. |
| 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)
libgd2: buffer overflows in PNG handling
| Package(s): | libgd2 |
CVE #(s): | CAN-2004-0990
CAN-2004-0941
|
| Created: | October 29, 2004 |
Updated: | June 28, 2006 |
| Description: |
Several buffer overflows have been discovered in libgd's PNG handling
functions.
If an attacker tricked a user into loading a malicious PNG image, they
could leverage this into executing arbitrary code in the context of
the user opening image. Most importantly, this library is commonly
used in PHP. One possible target would be a PHP driven photo website
that lets users upload images. Therefore this vulnerability might lead
to privilege escalation to a web server's privileges.
Multiple buffer overflows in the gd graphics library (libgd) 2.0.21 and
earlier may allow remote attackers to execute arbitrary code via malformed
image files that trigger the overflows due to improper calls to the
gdMalloc function. |
| Alerts: |
|
Comments (none posted)
libpam-ldap: authentication bypass
| Package(s): | libpam-ldap |
CVE #(s): | CAN-2005-2641
|
| Created: | August 25, 2005 |
Updated: | October 6, 2006 |
| Description: |
libpam-ldap, the PAM LDAP interface, has a vulnerability in which
it fails to authenticate with an LDAP server which is not configured
properly, allowing an authentication bypass. |
| Alerts: |
|
Comments (none posted)
libtiff: buffer overflow
| Package(s): | libtiff |
CVE #(s): | CVE-2006-2193
|
| Created: | June 15, 2006 |
Updated: | September 1, 2008 |
| Description: |
The t2p_write_pdf_string function in libtiff 3.8.2 and earlier is vulnerable
to a buffer overflow. Attackers can use a TIFF file with UTF-8 characters
in the DocumentName tag to overflow a buffer, causing a denial of service,
and possibly the execution of arbitrary code. |
| Alerts: |
|
Comments (none posted)
mozilla products have multiple vulnerabilities
Comments (none posted)
mpg123: buffer overflows
| Package(s): | mpg123 |
CVE #(s): | CVE-2006-1655
|
| Created: | May 24, 2006 |
Updated: | July 3, 2006 |
| Description: |
mpg123 does not properly validate MPEG 2.0 layer 3 files, leading to a number of buffer overflow vulnerabilities. |
| Alerts: |
|
Comments (none posted)
MySQL: logging bypass
| Package(s): | mysql |
CVE #(s): | CVE-2006-0903
|
| Created: | April 4, 2006 |
Updated: | May 21, 2008 |
| Description: |
MySQL 5.0.18 and earlier allows local users to bypass logging mechanisms
via SQL queries that contain the NULL character, which are not properly
handled by the mysql_real_query function. NOTE: this issue was originally
reported for the mysql_query function, but the vendor states that since
mysql_query expects a null character, this is not an issue for mysql_query. |
| Alerts: |
|
Comments (2 posted)
mysql: information leaks
| Package(s): | mysql mysql-dfsg |
CVE #(s): | CVE-2006-1516
CVE-2006-1517
|
| Created: | May 8, 2006 |
Updated: | June 23, 2006 |
| Description: |
Stefano Di Paola discovered an information leak in the login packet
parser. By sending a specially crafted malformed login packet, a
remote attacker could exploit this to read a random piece of memory,
which could potentially reveal sensitive data. (CVE-2006-1516)
Stefano Di Paola also found a similar information leak in the parser
for the COM_TABLE_DUMP request. (CVE-2006-1517) |
| Alerts: |
|