FOSS.IN: A report
FOSS.IN 2005 has run its course. Your
editor, having returned (sans luggage and with a seriously confused body
clock) to a Colorado cold snap, will now set out to summarize this
impressive event. This article is a companion to
the first-day report already
published.
FOSS.IN attracted something over 2700 attendees to a set of
steel-and-canvas temporary buildings set up on the grounds of the Bangalore
Palace. Speakers - mostly from India, but also coming from Australia,
Brazil, Germany, Malaysia, the US, and beyond - led sessions on a wide
variety of topics. The audience was interested and engaged in a way not
often seen at other events. FOSS.IN was a fun place to be.
This report will not attempt to summarize the individual sessions. Those
who are interested in further information should have a look at the
numerous reports being posted on planet.foss.in. There are also quite a few photos available.
On the last day of the conference, your editor delivered a brutally technical kernel programming
talk to a crowd which nearly filled the 750-seat "Intel Hall." That is
several times the number of people which normally turn up for that sort of
session. These people were not just filling the seats; they asked no end
of detailed questions during the session and after as well. Alan
Cox's technical device driver talk drew an even larger crowd. An
immediate conclusion which might be drawn is that Bangalore contains
hundreds of programmers who are interested in - and capable of - hacking on
the kernel.
Even if only 10% of those attendees were truly active in kernel
development, one would expect to see a significant amount of code from
Bangalore working its way into the mainline kernel. And there are some
Bangalore-based kernel hackers who are active on the mailing lists and who
are contributing code. But their numbers are far smaller than one would
expect after seeing how many people are interested and knowledgeable in
this area. India is, as one developer put it, "the world's biggest
consumer of free software," but it is not a huge contributor. Trying to
reconcile this difference became one of your editor's primary objectives at
FOSS.IN.
It is not possible to claim that this objective was realized in any
complete way. It has become clear, however, that a few forces are at play
here. One of them become evident early on: of the numerous questions asked
privately by attendees, quite a few had to do with binary-only kernel
modules. It seems that the challenges involved in maintaining proprietary
modules - the changing kernel API, GPL-only exports, etc. - are proving
frustrating to deal with. But more to the point: it seems that a significant
percentage of these kernel developers are engaged in the writing of
proprietary code. Your editor was far from the only speaker to sermonize about
the problems inherent in proprietary code and the importance of
contributing back to the community, but, if Indian companies are demanding
the creation of proprietary code, that's what their employees will write.
Another important factor was revealed in a talk given by Neetibodh Agarwal,
and in various discussions which followed. Neeti was called upon to set up
a development team for Novell in Bangalore, and he was struck by just how
difficult that was to do. There are, it seems, a number of reasons why
Indian developers have a difficult time engaging with the free software
development community.
By several accounts, the problem starts with the university system. The
Indian universities are strongly oriented toward the creation of employable
graduates in large numbers; a number of FOSS.IN attendees described them as
"assembly line" operations. There is a strong emphasis on passing tests
and getting through the system on schedule, and, it seems, little interest
in encouraging creativity and curiosity in the students. The universities
were described as a conformist environment with little love of those who
have their own ideas of how things should be done. The end result, as
expressed to your editor, is that most students have had any love of
hacking beaten out of them by the time they graduate.
The fact that the universities are, for the most part, hostile to Linux and
free software does not help either.
Neeti's talk described Indian developers as needing to have their jobs laid
out to them in great detail. They want to know where their boundaries are,
and are uncomfortable if left to determine their own priorities and
approaches. Your editor's initial reaction was that this claim sounded
like classic talk from a pointy-haired boss who does not trust his
employees to make decisions. Subsequent discussions backed up Neeti's
claims, however. A few Indians told me that Indian employees require a
high degree of supervision; perhaps that is why the pizza stand at the site
required two-levels of necktie-wearing bosses who apparently did little to
actually get pizza into the hands of conference attendees. It is not that Indians lack
the intelligence to function without a boss breathing down their neck -
that is clearly not the case - but all of their training tells them to work
in that way.
So if one were to construct a stereotypical picture of an Indian software
developer, it would depict a person who sees programming very much as a
job, and not as an activity which can be interesting or rewarding in its
own right. This developer is most interested in getting - and keeping - a
stable job in a country where an engineering career can be a ticket to a
relatively comfortable middle-class existence. Keeping that job requires
keeping management - and coworkers - happy, and not rocking the boat.
For such a developer, the free software community is not a particularly
attractive or welcoming place. A developer who contributes to a free
software project may earn a strong reputation in the community, but that
reputation is not appreciated by that developer's employer or co-workers,
and is not helpful for his or her career. Criticism from the community -
even routine criticism of a patch by people who appreciate the developer's
contributions in general - can be hurtful to a career in a culture where
open criticism is not the normal way of doing things. Developers who
expect to have their job parameters laid out to them in detail may feel lost
in a project where they are expected to find something useful to do, and
push it forward themselves. And these developers, while being possibly
quite skilled in what they do, often have no real passion for programming,
and leave it all behind when they leave the office each day.
It also does not help that, at this point, would-be contributors have few
role models in India.
In the long term, many of these problems may go away. For now, however,
getting Indian programmers into the community will require some extra
care. Often, it will be necessary to engage (respectfully) with their
supervisors: in most cases, if an Indian is working with the community, it
is because his or her boss is making it happen. Being careful with
criticism and avoiding creating trouble for Indian developers in their work
hierarchies can only help.
And, obviously, an important step will be the creation of a vibrant free software community in
India. This community can provide inspiration, mentoring, and support for
aspiring contributors; it could also provide a pool of free software
programmers from which employers could hire. The seeds of this community
were clearly visible at FOSS.IN - in fact, many FOSS.IN attendees
are poorly described by (and probably somewhat offended by) the caricature
presented above (please accept
your editor's apologies). Dozens of Indian free software hackers
got up on stage and presented their work at this event. Interestingly, the distribution
most in evidence at FOSS.IN was Gentoo, rather than one of the products of
the commercial distributors who are steadily employing more developers in
Bangalore. The Ruby hackers - unlikely to be working at the behest of
their employer at this stage - essentially had their own one-day track at
the event. Harald Welte's session on hacking the Linux-based Motorola a780
phone attracted a very high level of interest.
There is, clearly, a lot going on in India even now; it will be
most interesting to watch the level of activity explode as the local
community develops.
Events like FOSS.IN are crucial for the development of this community. So
it is unfortunate that this event is currently dealing with some serious
financial problems. A sponsorship shortfall led to a reduction in the
conference program, and it leaves the organizers with a financial gap that
they are struggling to close. Given this situation, it is worth noting
that the list of conference sponsors (which includes Intel, Google, Sun,
and HP) is missing the names of a few companies which work with free
software, and which have a presence in Bangalore. In particular, IBM,
Novell, and Red Hat all declined to sponsor FOSS.IN this year, even though
many of their employees were using their vacation time to attend. Local
companies, such as Wipro and InfoSys, were represented in the audience and
among the speakers, but did not sponsor the event. If these
companies see any benefit in having a thriving community to support their
developers, sponsoring an event like FOSS.IN should look like an
inexpensive way to help bring that community about.
Your editor thanks FOSS.IN (and its sponsors) for making it possible for
him to be there. It was a fun and informative event in an interesting and
changing part of the world.
Comments (26 posted)
A look at the Patent Commons Project and OIN
December 7, 2005
By Pamela Jones, Editor of Groklaw
Now that we have both OSDL's
Patent Commons Project and the
Open Invention Network off
and running, the questions that come to mind are: what is the difference,
if any, between them, and are either of them -- or both of them together
-- enough to protect Linux and FOSS development from a US patent system
that appears to have gone bonkers? More specifically, can they protect
Linux from Microsoft, or SCO-like surrogate trolls, should it decide to
press forward in implementing its many hints of bringing patent
infringement claims against Linux?
An obvious first question might be: what are the differences between these
two initiatives?
While they are both designed for protection against patent infringement
litigation, there are differences in approach. A patent commons provides
both a safety zone and a way to barter. Corporations cross-license their
patents all the time. GNU/Linux developers have been shut out of that
club, but,
with some patents and patent pledges in a patent commons, they would have
something to barter with. Consequently, OSDL encourages
individuals, companies, Open Source projects, and universities to obtain
patents and then contribute them to the commons:
The Project also provides a meaningful way for those who oppose software
patents to use the current patent system for the benefit of the open source
community and industry. Patenting ideas reduces the likelihood that
detractors of open source software and open standards will obtain a patent
on that same invention and use it against the community and industry, or
extract royalties for its use. More importantly, patenting ideas and then
pledging the patents in support of The Commons expands and reinforces the
protective environment of The Commons.
OSDL's project is also designed to help developers
keep track of all the patents and the patent pledges, and it is focused on
all of Open Source:
Today's software patent environment is
growing increasingly complex for developers and users of both proprietary
and open source software. This is an intricate problem with many facets,
and most everyone understands the need for a comprehensive, long-term
solution.
It has as a goal to simplify the administrative
process of licensing patents, so the industry finds it easy and pleasant to
work with Open Source and can make their patents available without a lot of
rigmarole. From the Patent Commons
website:
With increasing frequency, institutions, companies, and inventors wish to
signal formally to open source developers, distributors, sellers and users
that software patents they hold are not a threat or inhibitor to the
development, distribution or use of open source software and open
standards. The traditional means of giving permission to use patented
inventions (such as licenses) can be expensive, time consuming, and
logistically difficult to provide. Commitments simplify the process by
which access to patented inventions can be granted.
The Patent Commons is set up to facilitate that process.
The idea is to provide developers with a safer haven, and reassurance via
understanding which patents will not be used against them. Also, enforcing
the patents in the commons is administered by OSDL, which is an important
benefit for patent donors.
"Over the last 12 months, OSDL has been happy to see companies signal to the
community their promises not to enforce patents against open source
developers. We have wanted to ensure these pledges would be accessible to
those who they are intended to support. The OSDL Project and website does
just that," said Diane Peters, general counsel, OSDL. "For the first time,
the pledges are being compiled and then cataloged in a neutral location
where developers can view and analyze each pledge. So, regardless of where
one stands on the value of one patent pledge over another, developers and IT
managers can review the merits of each pledge and determine for themselves
the value they can provide for them or their peers."
As Eben Moglen stated,
there is strength in numbers, and so even though he opposes patents, he
encourages developers to contribute to the project. As Linus Torvalds put it, it's
"one way to try to help developers deal with the threat" of patent
litigation. It's not the complete solution, of course, because the patent
system is dysfunctional in the US. Peters: "We do realize that the Patent
Commons
Project and website is one step of many that will need to take place to
address the flawed patent system and we applaud other efforts that are
taking place and encourage further discussion and actions to chip away at
the current system."
The Open Invention Network approaches the same threat, but in a different
way. First, it's a company that has a patent portfolio, but it isn't using
its patents for profit generation; instead it plans to use them to create
a healthy environment for Linux to develop in safely, to promote safe
innovation and drive advancement of applications for, and components of,
Linux. It's primarily designed to protect Linux but it covers also other
Open Source software.
OIN has the 39 web services patents that Novell, through a
subsidiary, bought from bankrupt CommerceOne in December for $15.5
million, and it will seek to acquire more patents, and then offer them
royalty-free to any company, institution or individual that agrees not to
assert its patents against the Linux operating system or certain
Linux-related applications.
IBM, Novell, Philips, Red Hat, and Sony currently fund OIN.
OIN isn't just about collecting patents and offering them to others on
mutually pleasant terms. A Red Hat SEC filing adds this:
The LLC may also take appropriate, good faith counter-measures within the
scope of its mandate, such as declaratory judgment actions, reexamination
actions, interferences or similar legal or administrative actions initiated
anywhere in the world.
In short, they are "armed and dangerous". I'm kidding, but only a little.
These are some of the largest tech vendors in the world drawing a line in
the sand and saying, if you cross this line and attack Linux, we will
respond, and we have something to respond with effectively. One savvy
editor, Richard Hoffman of Network Computing put
it like this:
This is the first systematic attempt by a
group of large vendors to ensure that Linux and its users are protected
from the threat of legal action. OIN can't hope to acquire even a small
fraction of all applicable patents, but that's not how patent battles
work. All OIN must do is maintain an adequate stable of "defensive"
patents, which can be offered under a cross-licensing arrangement any time
Microsoft or others threaten legal action. In other words: You don't sue
us, we won't sue you.
But do these organizations provide any sort of meaningful protection?
When you consider that Eben Moglen, OSDL, Linus Torvalds, Richard Stallman,
and the lawyers at IBM, Novell, Red Hat, Sony, and Philips all think so, a
better question would be, why would one doubt it? As you may have observed in
the current Blackberry patent anguish, or the Microsoft-Eolas battle, even
one patent can be dangerous, so having hundreds in your arsenal is bound
to make any aggressor stop and think twice before taking you on.
But are the patents any good, some may ask? Do you remember, before the
auction of the CommerceOne patents, how anxious everyone was feeling,
particularly Google, Oracle and Sun Microsystems? What if the patents fell
into the wrong hands? Efforts to pool resources were reported in the
press, including by a nonprofit group, the CommerceNet Consortium. Here
is how the patents were described by
CommerceNet:
CommerceNet asserted that the patents "cover
basic technology for facilitating network transactions by identifying a
transaction in terms of input and output documents. If obtained by an
intellectual property licensing organization, it is expected that the
patents would likely be broadly asserted against companies completing
transactions using web service interface descriptions (WSDL), service
registries (UDDI), and documents composed from XML building blocks."
At the time observers thought the
patents were valuable and dangerous:
"There's a concern that these patents could be used aggressively by a buyer
to shake down the whole Web services industry," said Jason Schultz, an
attorney at technology activist organization the Electronic Frontier
Foundation.
Thanks to Novell, those patents are now
available to the community, having been donated to OIN, and not only do
they not endanger Linux, they protect it. They have the same power today
that they had then. Even Microsoft is impacted by the patents, which is
exactly what you want, if you wish to deter an attack, is it
not? If OIN had nothing but these patents, it would have something
useful in defending Linux.
Here's what Gartner
said about the value of OIN:
Software patents pose the single largest threat to the open-source software
model. Though they protect their owners' IP, they can also create legal
barriers to many open-source efforts. For example, as Linux and Windows
edge onto one another’s turf, the Linux community will have few defenses
against the power of Microsoft, if the software giant should seek to claim
royalties from the use of allegedly misappropriated IP.
A company like OIN that can uphold a strong patent portfolio will create
a counter-offensive against potential patent infringement claims. OIN
expects to accumulate patents by purchase, auction or donation. It will
contractually offer royalty-free usage of its patents to technology
suppliers for use in their own products (as long as the patent user makes
no future patent infringement claim against Linux and associated
software). We believe this collaborative environment is likely to free up
the flow of technology somewhat, by reducing fears of lawsuits from patent
claims.
It frees up the flow by holding evildoers at bay,
pure and simple. Is it the complete solution? No. As far as I'm
concerned, software and patents need to get a divorce on the grounds of
incompatibility. Some feel that is the only goal worth striving for. But
can you do it by next week? If you can, please do and we won't need either
the OSDL Patent Commons Project or OIN. But if you can't, what do you
suggest we do to hold patent attacks at bay? SCO didn't have any
patents. Imagine if they did. How do you plan to protect GNU/Linux from
such a patent infringement claim? If you don't have a plan, then are you
thinking deeply enough?
Something new, innovative, and
powerful is now standing guard over Linux. The lawyers have been busy and
very creative. and yes, it's real. It has deterrent value in the legal
context. And if litigation comes along anyway, it has both defensive and
offensive potential. A year ago, Linux had nothing but threats hanging
over its head, threats of patent litigation heading its way. Now, there is
some protection against that threat, protection which will continue to be
strengthened, I'm sure. No matter what your position on software patents,
how can that be anything but good?
Comments (22 posted)
Obnoxious legislation in Europe
Much fuss has been made over the "DADVSI" law currently under consideration
in France. By some accounts, the French government is trying to ban free
software outright. Getting the real story of what is happening in France
is difficult, especially for one who reads French as slowly as your editor
does. But the truth which is emerging suggests that, while DADVSI is
obnoxious, it isn't quite as bad as some have made it out to be.
DADVSI is the French implementation of the EUCD directive from the European
Union. It can be thought of as the French version of the DMCA; it has the
usual prohibitions on the circumvention of digital restriction mechanisms
and such. An amendment to this bill would appear to ban all software which
does not contain DRM and watermarking capabilities; this provision has led
the EUCD.info
site to conclude that it would affect tools like web servers, ssh, and
FTP.
Such a ban looks impractical at best. What the amendment really appears to
cover is any software which is capable of removing DRM and watermarks from
content. This provision clearly covers some free code, with DeCSS being at
the top of the list. No free software will ever be able to access
restricted content under this law; since the source is available, any
restrictions could be removed by the user. So the amended DADVSI law does
effectively ban free software from certain areas, but it does not affect
free software in general.
This law, like all of its variants worldwide, is certainly worth opposing.
An online
petition has been posted for people to express their opposition to this
law, which is expected to be considered immediately before Christmas.
Signing the petition makes sense, especially for French citizens.
Directly contacting members of the National Assembly is also a very good
idea.
Meanwhile, the European Union appears poised to adopt a new data retention
directive. This law would require communications providers (telephone
companies, ISPs) to record information on telephone calls, Internet use,
email traffic, etc., and to retain it for 6-24 months. It is already
impossible in some parts of Europe to sit down at an Internet cafe without
showing identity papers; the data retention directive would force Internet
providers across Europe to record identities and activities. Access to
this data would be relatively unrestricted; the entertainment industry is
lobbying to be able to use it for tracking down file sharers.
While not directly related to free software, this directive is clearly
hostile to the rights and privacy of all Europeans. Unfortunately, its
passage in the European Parliament on December 12 appears to be an
almost foregone conclusion. More
information can be found in this EDRI-gram
newsletter.
Comments (6 posted)
Page editor: Jonathan Corbet
Security
The SANS top-20 list
SANS has posted a new version of its
20 most critical Internet security
vulnerabilities list. As always, this list is a good starting point
for those looking for potential security problems on their networks. Here
are some highlights from the current version:
- Five of the twenty items concern Windows and other Microsoft
software.
- There are ten vulnerabilities in "cross-platform applications"
listed. Some of these (commercial DNS servers, for example) do not
apply to most Linux systems. But others do, including anti-virus
software (ClamAV in particular), PHP-based applications (several
vulnerabilities), database managers, file-sharing applications, media
players, and Mozilla-based browsers.
- There are only two Unix-specific vulnerabilities, and one of those is
a general item on Mac OS X. The other vulnerability is
"configuration weaknesses," with an emphasis on SSH attacks.
Once upon a time, this list was evenly divided between Windows and Unix
vulnerabilities. A casual reading of the current list suggests that things
have shifted in favor of Unix-based systems. While it may be true that
Unix-based systems are easier to keep secure on the net, there is still no
reason to be overly complacent. A system compromised by way of a Firefox
or PHP vulnerability is still compromised.
Comments (3 posted)
New vulnerabilities
apache2: memory leak
| Package(s): | apache2 |
CVE #(s): | CVE-2005-2970
|
| Created: | December 6, 2005 |
Updated: | December 19, 2005 |
| Description: |
A memory leak was found in the Apache 2 'worker' module in the
handling of aborted TCP connections. By repeatedly triggering this
situation, a remote attacker could drain all available memory, which
eventually led to a Denial of Service. |
| Alerts: |
|
Comments (none 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)
helix-player: integer overflow
| Package(s): | helix-player |
CVE #(s): | CVE-2005-2629
|
| Created: | December 2, 2005 |
Updated: | December 7, 2005 |
| Description: |
An integer overflow has been discovered in helix-player, the helix
audio and video player. This flaw could allow a remote attacker to
run arbitrary code on a victims computer by supplying a specially
crafted network resource. |
| Alerts: |
|
Comments (none posted)
inkscape: insecure temp files
| Package(s): | inkscape |
CVE #(s): | CVE-2005-3885
|
| Created: | December 5, 2005 |
Updated: | December 7, 2005 |
| Description: |
Javier Fernández-Sanguino Peña discovered that Inkscape's ps2epsi.sh
script, which converts PostScript files to Encapsulated PostScript
format, creates a temporary file in an insecure way. A local attacker
could exploit this with a symlink attack to create or overwrite
arbitrary files with the privileges of the user running Inkscape. |
| Alerts: |
|
Comments (1 posted)
ipsec-tools: denial of service
| Package(s): | ipsec-tools |
CVE #(s): | CVE-2005-3732
|
| Created: | December 1, 2005 |
Updated: | June 8, 2006 |
| Description: |
ipsec-tools has a remote
denial of service vulnerability in the racoon daemon.
If racoon is running in aggressive mode, it fails to check all peer
payloads during
When the daemon the IKE negotiation phase, allowing a malicious peer
to crash the daemon. One should always be careful around aggressive racoons. |
| Alerts: |
|
Comments (none posted)
mailman: denial of service
| Package(s): | mailman |
CVE #(s): | CVE-2005-3573
|
| Created: | December 2, 2005 |
Updated: | March 8, 2006 |
| Description: |
Scrubber.py in Mailman 2.1.4 - 2.1.6 does not properly handle UTF8
character encodings in filenames of e-mail attachments, which allows
remote attackers to cause a denial of service. |
| Alerts: |
|
Comments (none posted)
perl: integer overflow
| Package(s): | perl |
CVE #(s): | CVE-2005-3962
CVE-2005-3912
|
| Created: | December 1, 2005 |
Updated: | February 27, 2006 |
| Description: |
Perl has an sprintf integer overflow vulnerability
that may be used for a denial of service, remote code
execution and information leakage. |
| Alerts: |
|
Comments (none posted)
trackballs: symlink vulnerability
| Package(s): | trackballs |
CVE #(s): | |
| Created: | December 7, 2005 |
Updated: | December 7, 2005 |
| Description: |
Trackballs follows symbolic links, possibly allowing unprivileged users to access and modify files accessible by the games group. |
| Alerts: |
|
Comments (none posted)
xpdf: arbitrary code execution
| Package(s): | xpdf |
CVE #(s): | CVE-2005-3193
|
| Created: | December 6, 2005 |
Updated: | January 11, 2006 |
| Description: |
Several flaws were discovered in Xpdf. An
attacker could construct a carefully crafted PDF file that could cause Xpdf
to crash or possibly execute arbitrary code when opened. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
a2ps: input validation error
| Package(s): | a2ps |
CVE #(s): | CAN-2004-1170
CAN-2004-1377
|
| Created: | November 26, 2004 |
Updated: | December 19, 2005 |
| Description: |
The GNU a2ps utility fails to properly sanitize filenames, which can be
abused by a malicious user to execute arbitrary commands with the
privileges of the user running the vulnerable application. More
information at Security
Focus. |
| Alerts: |
|
Comments (none 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)
centericq: denial of service
| Package(s): | centericq |
CVE #(s): | CVE-2005-3694
|
| Created: | November 30, 2005 |
Updated: | November 30, 2005 |
| Description: |
Wernfried Haas discovered that centericq, a text-mode multi-protocol
instant messenger client, can crash when it receives certain zero
length packets and is directly connected to the Internet. |
| Alerts: |
|
Comments (none posted)
cpio: directory traversal
| Package(s): | cpio |
CVE #(s): | CAN-2005-1111
|
| Created: | June 20, 2005 |
Updated: | December 26, 2005 |
| Description: |
There is a vulnerability in
cpio (2.6 and previous) that allows a malicious cpio file to
extract to an arbitrary directory of the attackers choice. cpio will
extract to the path specified in the cpio file, this path can be absolute. |
| Alerts: |
|
Comments (1 posted)
cyrus-imapd: buffer overflows
| Package(s): | cyrus-imapd |
CVE #(s): | CAN-2005-0546
|
| Created: | February 23, 2005 |
Updated: | April 9, 2006 |
| Description: |
Cyrus-imapd, prior to version 2.2.12, contains several buffer overflows which could be exploited by an (authenticated) attacker to run code on the server system. |
| Alerts: |
|
Comments (none posted)
dia: missing input sanitizing
| Package(s): | dia |
CVE #(s): | CAN-2005-2966
|
| Created: | October 4, 2005 |
Updated: | April 6, 2006 |
| Description: |
Joxean Koret discovered that the SVG import plugin did not properly
sanitize data read from an SVG file. By tricking an user into opening
a specially crafted SVG file, an attacker could exploit this to
execute arbitrary code with the privileges of the user. |
| Alerts: |
|
Comments (none posted)
egroupware: multiple vulnerabilities
| Package(s): | egroupware |
CVE #(s): | CVE-2005-0870
CVE-2005-2600
CVE-2005-3347
CVE-2005-3348
|
| Created: | November 17, 2005 |
Updated: | December 9, 2005 |
| Description: |
A number of vulnerabilities have been found in egroupware,
a web-based groupware suite.
Phpsysinfo has several cross-site scripting vulnerabilities,
The the tree view of FUD Forum Bulletin Board Software has
a cross-site scripting problem, phpsyinfo has a local variable
overwrite problem, and phpsyinfo has an input sanitizing
issue. |
| Alerts: |
|
Comments (none posted)
eix: insecure temp file
| Package(s): | eix |
CVE #(s): | |
| Created: | November 23, 2005 |
Updated: | November 30, 2005 |
| Description: |
eix can create an insecure temporary file. A local user can
use this to overwrite arbitrary files. |
| Alerts: |
|
Comments (none posted)
emacs21: format string vulnerability in "movemail"
| Package(s): | emacs21 |
CVE #(s): | CAN-2005-0100
|
| Created: | February 7, 2005 |
Updated: | May 15, 2006 |
| Description: |
Max Vozeler discovered a format string vulnerability in the "movemail"
utility of Emacs. By sending specially crafted packets, a malicious
POP3 server could cause a buffer overflow, which could be exploited to
execute arbitrary code with the privileges of the user and the "mail"
group. |
| Alerts: |
|
Comments (none posted)
enigmail: information disclosure
| Package(s): | enigmail |
CVE #(s): | CVE-2005-3256
|
| Created: | October 20, 2005 |
Updated: | December 13, 2005 |
| Description: |
The key selection dialog from the Mozilla Thunderbird enigmail plugin
has an information disclosure vulnerability.
A key with an empty user id from a user's keyring will be used by
default, allowing a message to be decrypted. This can lead to an
unauthorized information disclosure. |
| Alerts: |
|
Comments (none posted)
enscript: arbitrary code execution
| Package(s): | enscript |
CVE #(s): | CAN-2004-1184
CAN-2004-1185
CAN-2004-1186
|
| Created: | January 21, 2005 |
Updated: | May 27, 2006 |
| Description: |
Erik Sjölund has discovered several security relevant problems in enscript,
a program to convert ASCII text into Postscript and other formats.
Unsanitized input can cause the execution of arbitrary commands via EPSF
pipe support. Due to missing sanitizing of filenames it is possible that a
specially crafted filename can cause arbitrary commands to be executed.
Multiple buffer overflows can cause the program to crash. |
| Alerts: |
|
Comments (none posted)
ethereal: multiple vulnerabilities
Comments (none posted)
evolution: format string issues
Comments (2 posted)
firefox: multiple vulnerabilities
Comments (none posted)
Foomatic: Arbitrary command execution in foomatic-rip
| Package(s): | foomatic |
CVE #(s): | CAN-2004-0801
|
| Created: | September 20, 2004 |
Updated: | May 31, 2006 |
| Description: |
There is a vulnerability in the foomatic-filters package. This
vulnerability is due to insufficient checking of command-line parameters
and environment variables in the foomatic-rip filter. This vulnerability
may allow both local and remote attackers to execute arbitrary commands on
the print server with the permissions of the spooler. |
| Alerts: |
|
Comments (none posted)
FUSE: mtab corruption through fusermount
| Package(s): | fuse |
CVE #(s): | CVE-2005-3531
|
| Created: | November 22, 2005 |
Updated: | January 24, 2006 |
| Description: |
Thomas Biege discovered that fusermount fails to securely handle
special characters specified in mount points. A local attacker could corrupt the contents of the /etc/mtab file by mounting over a maliciously-named directory using fusermount, potentially allowing the attacker to set unauthorized mount options. |
| Alerts: |
|
Comments (none posted)
gaim: buffer overflow
| Package(s): | gaim |
CVE #(s): | CAN-2005-2103
|
| Created: | August 10, 2005 |
Updated: | February 27, 2006 |
| Description: |
Gaim suffers from a heap-based buffer overflow which can be exploited via a hostile "away message" to execute arbitrary code. |
| 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)
gtk-pixbuf, gtk2: denial of service
| Package(s): | gdk-pixbuf gtk2 |
CVE #(s): | CAN-2005-0891
|
| Created: | March 30, 2005 |
Updated: | December 19, 2005 |
| Description: |
The BMP image processing code in gdk-pixbuf and gtk2 contains a denial of service vulnerability exploitable via a specially crafted image file.
|
| Alerts: |
|
Comments (none posted)
gdk-pixbuf: multiple vulnerabilities
| Package(s): | gdk-pixbuf gtk2 |
CVE #(s): | CVE-2005-3186
CVE-2005-2976
CVE-2005-2975
|
| Created: | November 15, 2005 |
Updated: | March 20, 2006 |
| Description: |
The gdk-pixbuf package contains an image loading library used with the
GNOME GUI desktop environment. A bug was found in the way gdk-pixbuf
processes XPM images. An attacker could create a carefully crafted XPM file
in such a way that it could cause an application linked with gdk-pixbuf to
execute arbitrary code when the file was opened by a victim.
Ludwig Nussel discovered an integer overflow bug in the way gdk-pixbuf
processes XPM images. An attacker could create a carefully crafted XPM
file in such a way that it could cause an application linked with
gdk-pixbuf to execute arbitrary code or crash when the file was opened by a
victim.
Ludwig Nussel also discovered an infinite-loop denial of service bug in the
way gdk-pixbuf processes XPM images. An attacker could create a carefully
crafted XPM file in such a way that it could cause an application linked
with gdk-pixbuf to stop responding when the file was opened by a victim. |
| Alerts: |
|
Comments (none posted)
gettext: Insecure temporary file handling
| Package(s): | gettext |
CVE #(s): | CAN-2004-0966
|
| Created: | October 11, 2004 |
Updated: | March 1, 2006 |
| Description: |
gettext insecurely creates temporary files in world-writeable directories
with predictable names. A local attacker could create symbolic links in
the temporary files directory, pointing to a valid file somewhere on the
filesystem. When gettext is called, this would result in file access with
the rights of the user running the utility, which could be the root user. |
| Alerts: |
|
Comments (1 posted)
groff: insecure temporary directory
| Package(s): | groff |
CVE #(s): | CAN-2004-0969
|
| Created: | November 1, 2004 |
Updated: | February 9, 2006 |
| Description: |
Recently, Trustix Secure Linux discovered a vulnerability in the groff
package. The utility "groffer" created a temporary directory in an
insecure way, which allowed exploitation of a race condition to create
or overwrite files with the privileges of the user invoking the
program. |
| Alerts: |
|
Comments (none 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: cross site scripting vulnerability
| Package(s): | horde |
CVE #(s): | CVE-2005-3570
|
| Created: | November 23, 2005 |
Updated: | December 1, 2005 |
| Description: |
Horde has a potential cross site scripting vulnerability.
Error messages are not properly escaped. A user can be tricked
into executing arbitrary scripts by reading specially crafted
email messages, or using a maliciously created URL. |
| Alerts: |
|
Comments (none posted)
horde3: missing input sanitizing
| Package(s): | horde3 |
CVE #(s): | CVE-2005-3759
|
| Created: | November 23, 2005 |
Updated: | November 30, 2005 |
| Description: |
The MIME viewer in the horde3 web
application suite has an input sanitizing vulnerability.
It is possible for a remote attacker to use this to execute
arbitrary code. |
| Alerts: |
|
Comments (none posted)
htdig: cross site scripting
| Package(s): | htdig |
CVE #(s): | CAN-2005-0085
|
| Created: | February 14, 2005 |
Updated: | January 10, 2006 |
| Description: |
Michael Krax discovered that ht://Dig fails to validate the 'config'
parameter before displaying an error message containing the parameter.
This flaw could allow an attacker to conduct cross-site scripting
attacks. |
| Alerts: |
|
Comments (none posted)
imap: buffer overflow in c-client
| Package(s): | imap |
CVE #(s): | CAN-2003-0297
|
| Created: | February 18, 2005 |
Updated: | April 9, 2006 |
| Description: |
A buffer overflow flaw was found in the c-client IMAP client. An attacker
could create a malicious IMAP server that if connected to by a victim could
execute arbitrary code on the client machine. |
| Alerts: |
|
Comments (none posted)
inkscape: arbitrary code execution
| Package(s): | inkscape |
CVE #(s): | CVE-2005-3737
|
| Created: | November 21, 2005 |
Updated: | December 7, 2005 |
| Description: |
A buffer overflow has been discovered in the SVG importer of Inkscape.
By tricking an user into opening a specially crafted SVG image this
could be exploited to execute arbitrary code with the privileges of
the Inkscape user. |
| Alerts: |
|
Comments (none posted)
ipmenu: insecure temp file
| Package(s): | ipmenu |
CVE #(s): | CVE-2004-2569
|
| Created: | November 23, 2005 |
Updated: | November 30, 2005 |
| Description: |
The cursel iptables/iproute2 GUI ipmenu has a vulnerability
involving the creation of an insecure temporary file.
A local attacker can overwrite arbitrary files by performing
a symlink attack. |
| 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)
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
Comments (none posted)
kernel: multiple vulnerabilities