How Sun's Java got into Debian
One of the comments posted on
last week's article about the Java
license change asked: how can Debian distribute Sun's Java under the
new license? A number of clauses, including the requirement that Java be
distributed with the operating system and the restrictions on shipping Java
"in conjunction with" alternative implementations, would seem to rule out a
Debian Java package. It turns out that a number of Debian developers are
wondering the same thing; in addition, there are questions about the
process that was involved. Sun's Java was fast-tracked into non-free, with
the traditional extended debate on debian-legal having been shorted out
entirely. Since Debian does very few things without enduring a public
brawl first, the addition of Java without discussion raised some eyebrows.
Various people have tried to answer the resulting questions. The
definitive word, perhaps, comes from Debian
Project Leader Anthony Towns:
There are three factors that are particularly relevant: the first
is Sun's intentions and ability and interest to work with us as a
proxy for the broader free software community -- this is an
important issue because it ensures that we can resolve any problems
with the license, and reduces the concern that Sun will try to
screw us over, as it would become a PR problem rather than just a
quiet argument on the lists;
There is a point here: Sun has been very public about how happy it is about
Debian's inclusion of Java. For the company to suddenly say that it isn't
happy after all would be a big, public turnaround and would invite a fair
amount of criticism. There would have to be a big reason for Sun to make
such a move.
Anthony continues:
the second is that both the legal principle of estoppel and the
general common sense principle of not going back on your word if
you want people to work with you prevents Sun from realistically
saying "the FAQ is completely wrong and should be ignored";
The DLJ FAQ
does, indeed, make a lot of encouraging noises about what the license terms
really mean. It says, for example, that there is no problem with shipping
other Java implementations. The FAQ leads off with this rather less
encouraging text, however:
Note: This FAQ is provided to help explain the Operating System
Distributor License for Java; nothing in this FAQ is intended to
amend the license, so please consult the license itself for the
precise terms and conditions that actually apply.
This is the text that makes many Debian developers say that the FAQ is
irrelevant and should be ignored. It may well be that Sun has, by way of
estoppel, blocked itself from a rigorous enforcement of the license terms
by publishing this FAQ, but that is a question which cannot be definitively
answered outside of a courtroom - and, even then, the answer only applies
to one jurisdiction.
Finally:
and the third aspect, which is probably most important, is that
should any of these problems actually happen, we can fairly simply
just drop Sun Java from non-free if we can't come to a better
conclusion.
So, if things go wrong, Debian can just stop distributing Java and the
problems go away.
These arguments all make sense, but there is something important which
should be noted about them: they are arguments of convenience. They could
be loosely paraphrased as "it looks like we can get away with it, and, if
that turns out not to be true, we'll just stop." Debian, however, has
never been about convenience - the project is far more concerned with
freedom and doing the right thing. Distributing software in a way which
does not comply with its license is very much counter to the way the Debian
Project works - even if it looks like the act would go unpunished. But
there is little in Anthony's response saying that Debian is truly compliant
with the Distributor License for Java.
Sun employee Tom Marble has argued that
there is no conflict between Debian and the DLJ. Like Anthony, he refers
to the FAQ, but without addressing the text in the FAQ itself directing
people to the license for the "precise terms and conditions." With regard
to alternative technologies, Tom says:
From FAQ #8, "there is nothing in the DLJ intended to prevent you
from shipping alternative technologies with your OS distribution."
When I say mix and match I mean please don't take bits from the
alternate technologies (see above) and put them into use with the
Java platform (e.g. replace rt.jar which is part of the platform
with an alternate rt.jar). In a similar way please don't take bits
from the Java platform and use them as part of or to complete
alternate technologies (e.g. plugin.jar).
This could be a reasonable interpretation of the license, though it would
be much nicer if the license expressed these terms directly. Anybody who finds this
argument to be a suitably convincing and binding statement of the intent of
the license can, perhaps, conclude that Debian's distribution of Java in
non-free is compliant with that license. Of course, some of the other
terms, having to do with choice of venue for legal disputes, export
restrictions, and indemnification of Sun, may still be problematic for a
number of Debian developers.
Regardless of whether one believes that Debian's distribution of Java is
compliant, there is still the question of process: why was the Debian
community not involved in the decision? The answer is straightforward: all
of the relevant information was under embargo until Sun made its
announcement at JavaOne. The only way for Debian to have a Java package
when Sun announced - and for Sun to announce that said package existed -
was for the process to happen in secret. So the new license was examined
privately by Anthony Towns, James Troup, and Jeroen van Wolffalaar, and all
three pronounced it to be acceptable.
Michael Banck had an interesting take on
this process:
I think this was somewhat similar to the embargoed security
releases our security team handles for us. Sure we could just have
disclosed the license to -legal beforehand, but then Sun probably
would never talk to us about doing things like this one again and
just tend to OpenSUSE or some other community distribution next
time to collaborate with when they might open source Java.
So Debian, by cooperating with Sun on the disclosure of information, was
able to be a part of the initial PR splash. A question which has not been
asked - in public, at least - is: just how does Debian benefit from
participating in Sun's PR experience, and is it worth the cost of bypassing
the usual public discussion?
Comments (39 posted)
Toward a free Java
May 24, 2006
This article was contributed by Mark Wielaard
Every year around JavaOne there is a lot
talk about Java and whether we will ever see a free alternative
for it. Since 2000, various projects aiming to provide a free
alternative for the Java platform have been working together toward
this goal. This cooperation became much stronger when in 2003 various
developers from GNU Classpath, Kaffe, GCJ, JamVM, IKVM/Mono and others
met each other in person during some informal meetings at
Linux Kongress, FOSDEM and LinuxTag in Europe. What had before been
competing projects became projects that would cooperate wherever
technically possible, especially around the core class libraries as
provided by GNU Classpath. The competition turned into something
positive and playful. The GNU project even sponsored the Fast Free Eclipse contest
which was ultimately won by GCJ in August 2003 (with JikesRVM and
IKVM/Mono close behind).
At the end of 2004 Red Hat brought all these groups together again
during the Alternative Runtime Summit at the MIT campus in
Boston. They invited a large and diverse group of people to talk about
their projects and also invited representatives of the traditional
Gnome, GCC/GDB/GNU toolchain and Mono groups, plus representatives
of the Apache and Eclipse groups, to discuss various ways to build
bridges between the various communities. Richard Stallman gave a
lecture on the
Java trap and a Sun representative was also invited. Sun decided
to not join the fun at that time, but we did establish that our
goals were not that different.
Although none of us knew how the future would look, it was clear
that everybody was very positive about sharing their experiences and
working ever more together. Everybody left the Alternative Runtime
Summit feeling our goals united us much more than the different
technical paths we were taking to reach them divided us. There was
also a definite feeling that we would be able to provide a full free
alternative to the Java platform. And that the alternative(s) would be
much more then Java and that it would go beyond and extend the
traditional GNU platform.
The realization that we were in this together and that a free
alternative for Java should be integrated as much as possible with the
rest of the free platform had some important results. Our next meeting
at FOSDEM 2005 was all about building
bridges. We focused on alternative execution mechanisms like GCJ
and Mono, hooking into Gnome with java-gnome and doing continuous
integration tests against the Apache Java code base through Gump.
Another way to cooperate and, at the same time, help our users to try out
our work more easily was done by collaborating with the various
GNU/Linux distributions to package traditional Java programs and
libraries so they could be easily used with the various free
alternatives. During the Oldenburg DevJam Meeting
various packagers, compiler and runtime hackers came together to
define standards for interoperability and packaging conventions. Users
can now easily try out various compilers, libraries and the
alternative execution strategies for their code. This effort was so
successful that even Sun is now adopting the JPackage alternative
ideas for their own (proprietary) packages aimed at the GNU/Linux
platform (although their current license seems to
disallow any mixing and matching with the various free
subcomponents).
One of our success stories is the packaging of
Eclipse for the various GNU/Linux distributions. Although Eclipse
traditionally emphasizes the proprietary Windows platform,
the Eclipse developers have been extremely supportive of our efforts
and have helped find alternatives whenever the free toolchain didn't
have a particular language or library feature yet.
After setting up Gump integration
tests with Kaffe and seeing that we were almost there, the Apache
group became very enthusiastic about joining in. Since a lot of the
packages that are bundled by the free distributions were actually based on code by
the Apache group, that seemed like a very cool idea. After a couple
of conference calls between the FSF, ASF and various project members
we launched the Harmony!
project.
Unfortunately, from the start the project seemed plagued by
miscommunication and confusion about intentions. The original announcement
hadn't been proofread by some of the participants which lead to corrections
by the Kaffe team, clarifications
by the GCJ team and updates from
the GNU Classpath team about the original intent of the
project. Sadly, these first impressions were hard to shake off.
And
soon a lot more miscommunication and confusion started. Some people
joined that were very vocal about the project being Apache (and not
GNU!), some people said that their company regulations didn't allow
them to study anything on gnu.org, including the GNU
Classpath VM Integration Guide. Others said that using anything
that used the "gnu." Java package namespace would be impossible
to clear with their legal departments. IBM wanted to donate code,
but suggested using an alternative runtime interface which would be
suitable for their proprietary J9 VM (but not for any of the 30
projects currently based on GNU Classpath).
After 9 months of
trying to cooperate we organized a new meeting during FOSDEM
2006 to get all players together again. And, although 60 people
attended, including core GNU Classpath, GCJ, Kaffe, Cacao, JamVM and
IKVM hackers, only one Harmony person showed up, and none of the
people from the backing companies. All this means that, despite the
fact that there is now some code available donated by Intel, there is
no practical cooperation between the original free software projects
backing Harmony and the project now known as Apache Harmony. All this
made some people think of Harmony as a company consortium in the guise
of an ASF project and not a full community project. But there is still
some hope that the final result will be merged with the existing
projects at some point and that there will be more community
involvement in the future.
One thing we had completely overlooked in our Harmony effort was
the fear
uncertainty and doubt in the Apache Java world about the GPL, the LGPL,
and the GPL exception statements used by GNU Classpath and other GCC
runtime libraries. At the Alternative Runtime Summit we had discussed
The
Free Software Community, the GPL, Compromising and Control. And
David Turner from the FSF was present to explain LGPL and
Java. We (the Classpath developers) had naively assumed that in turn
for using an explicit GPL +
linking exception for GNU Classpath, so it could be used with code
distributed under the ASL, we would get back an exception to the ASL
for larger works distributed under the GPL.
Sadly that did not
happen. Partly because the Apache group doesn't hold the copyright on
code contributions so cannot change any of the terms of the code it
distributes (the FSF had offered to track down all contributors, but
this proved to be too large a number to be practical) and partly
because it doesn't want to make any exception for its code base
since it fears that would confuse its users. But most Apache people
did agree that it would be nice if code distributed under the ASL
would be reusable in larger GPLed works, just like it is reusable for
proprietary code. And the FSF agreed that none of the extra
requirements in the ASL were inhibiting the freedom of users.
As a result, you
will see various improvements in the GPLv3 draft based on our
discussions. The GPLv3 clarifies the system library exception,
explicitly states people can grant exceptions to the GPL, like the FSF
has done for the various GCC runtime libraries, and adds compatibility
clauses for certain requirements found in the ASL and EPL licenses. We
hope that when GPLv3 is finalized we will see more code flow between
the projects and reuse of various Apache and Eclipse technologies in
the GNU, Gnome and KDE worlds.
One of the efforts that does seem to pay off is our cooperation on
the Mauve Completeness,
Correctness and Compatibility testsuite. Mauve contains more than
45.000 core library tests and has various modules for testing core
class library implementations, byte code verifiers, source to byte
code and native code compiler tests. It also contains the Wonka visual
test suite and the Jacks Compiler Killer Suite. Every release of GNU
Classpath comes with a little overview of how well we do on the
tests. This is especially important because we have so many different
compiler and execution mechanisms available. It also enables us to
measure compatibility despite the fact that we don't have access to
the TCK suite that Sun uses to determine whether something is Java
compatible.
Now that Sun is again thinking about whether and how to open up
more we have even been in contact with some Sun engineers who would
like to start some cooperation by combining
out testsuites. For Sun compatibility has always been a very
touchy point. So some hope this will be the start of a better
cooperation of the Sun Java group with the rest of the free software
community. It seems that our continuous progress and nice integration
with the GNU/Linux desktop at least got their attention.
Comments (6 posted)
Coming soon: GnuCash 2.0
Back in September, 2005,
the
Grumpy Editor's Guide to Personal Finance Managers concluded that the
development energy and momentum seemed to belong to the KMyMoney project.
GnuCash, instead, seemed dispirited with little activity on its mailing
list and little visible progress toward its long-awaited 2.0 release.
Some distributors, hoping to be done with GTK1, were making noises about
dropping GnuCash altogether. At that time, KMyMoney looked like the
application with the brightest future.
Since then, there has been a significant surge in activity on the GnuCash
side while KMyMoney, to an outside observer, appears to have slowed down.
Clear goals for the GnuCash 2.0 release have been set, a series of pre-2.0
test releases has come out, and 2.0 final is currently planned for
June 11. GnuCash, it seems, is back. Your editor, whose desperate
attempts to balance the family budget are made on a system running the
Fedora development tree, got a rather unplanned opportunity to try out
GnuCash 1.9 (the pre-2.0 test release) when the Fedora hackers quietly
slipped it in as a replacement for the stable version. A few months of
financial firefighting later, it's time for a quick review.
Those who are expecting a lot of flashy new features from GnuCash 2.0
may be disappointed. The big change in this release is not the
heavily-requested animated pie chart feature. Instead, GnuCash has made
the (rather delayed) jump to the GTK2 toolkit. This change was a major bit
of work for the GnuCash developers, who had to drop some discontinued
libraries altogether and reimplement various features (graphical reports,
for example) in a completely different environment. So what 2.0 brings is
not a whole lot of new features, but a new platform which is ready for the
creation of tomorrow's new features.
One thing seasoned GnuCash users will notice early on is the tabbed
interface on the main window. In the stable 1.x releases, opening an
account results in the creation of a new register window; in 2.0, a new tab
is created instead. This behavior is arguably more consistent - even in
1.x, reports showed up in that version's form of tabs rather than in their
own window; now everything works that way. But, for users who are used to
being able to have more than one register on the screen simultaneously, the
new behavior can be a little annoying. Fortunately, there is an option to
move a tab into a new window, so users who like their screen cluttered
should still be happy.
Other than the new tabs, the GnuCash user experience is little changed from
the 1.x release. Things generally work and look as they did before. From
your editor's experience, it all appears to be quite stable (though your
editor has not spent any real time playing with the business features).
Except for a couple of minor keyboard focus issues, the transition appears
to have been completed successfully. For those interested in testing the
development releases, it's worth noting that the file format does not
appear to have changed, making it possible to make changes with a
development release, then go back to 1.8.x without trouble. It is worth
noting that the PostgreSQL backend is not yet working properly, but that is
consistent with the earlier GnuCash releases as well.
Of course, no major release can be completely without new features. The
GnuCash developers have found time to implement the use of UTF-8 for better
handling of non-western characters
and the ability to import the "MT940" files available from some banks. But the
most interesting (for users) developments in the 2.x series are likely to
show up in 2.1 and later releases. Now that the painful transition to a
contemporary toolkit has been made, the developers will have the time to do
fun stuff again, and the project should be more accessible for new
developers as well.
The free software community has been surprisingly slow to push the state of
the art in the personal finance area. One would think this particular itch
would afflict a great many developers - even the hungriest of starving
hackers has some financial management to do, and we can't all push
the work off onto our Windows-using spouses. Be that as it may, the
situation is slowly changing. Between KMyMoney and the new, refurbished
GnuCash, the community now has two high-quality platforms suitable for the
creation of tomorrow's personal financial software. Your editor is looking
forward to seeing where things go from here.
Comments (9 posted)
Page editor: Jonathan Corbet
Security
Holes in the Linux random number generator?
May 24, 2006
This article was contributed by Jake Edge.
Eye catching headlines are seen every day on the web, but one needs to
be careful not to distort the contents of the article. A recent SecuriTeam
article
is headlined "Holes in the Linux Random Number Generator" but that title
overstates the actual contents of the
paper (PDF) it is announcing.
The three authors of the paper provide a nice detailed description of the
Linux random number generator (RNG) and the algorithms that it uses, while
also reporting a very theoretical attack. The basic attack is against the
"forward security" of the RNG via a single compromise of the contents of
the entropy pool. This value can be used to run the RNG algorithm in reverse
and recover previous states of the entropy pool. Doing this enough times
can recover keys that have been previously generated.
There are a number of reasons why this attack is considered to have little
impact on real world systems. The most obvious is that if an attacker can
access the state of the entropy pool, they have already broken the security
of the system and can, as root, do any number of different things to the
system. If recovering previously generated keys is the object of the attack,
the paper outlines ways to do that, but the processing requirements are
enormous as Ted Ts'o points out:
To put this in
perspective, generating a 1024 bit RSA key will require approximately
14 turns of the crank, so if you are lucky with the positioning of the
index *and* you penetrate the machine and capture the state of the
pool (which as I mentioned, probably means you've rooted the box and
the system will probably have to be reinstalled from trusted media
anyway), *and* a 1024-bit RSA key had just been generated, you would
be able to determine that 1024-bit RSA key with a work factor of
approximately O(2**68) if you are lucky (probability 1 in 8), and
O(2**96) if you are not.
The paper also describes a well known feature of the Linux RNG implementation
as if it were a newly discovered denial of service issue. The
/dev/random device
was specifically designed to block when the entropy pool had insufficient
entropy to satisfy the request. The /dev/urandom device is
provided as an alternative that generates very good random numbers and
does not block (and is therefore not
vulnerable to a denial of service).
For any but the most sensitive applications (key generation being an
obvious choice), /dev/urandom is the recommended source for random
numbers. Alan Cox sums up the situation nicely:
The denial of service when no true entropy exists is intentional and
long discussed. User consumption of entropy can be controlled by
conventional file permissions, acls and SELinux already, or by a policy
daemon or combinations thereof. It is clearly better to refuse to give
out entropy to people than to give false entropy.
The paper has sparked an interesting
discussion
on the linux kernel mailing list and has lead to some concrete suggestions
for improving the algorithm, but it would be an exaggeration to conclude that
the paper describes real world Linux security concerns. An administrator
or security professional reading the SecuriTeam headline might easily
be led astray.
Comments (6 posted)
New vulnerabilities
awstats: missing input sanitizing
| Package(s): | awstats |
CVE #(s): | CVE-2006-2237
|
| Created: | May 19, 2006 |
Updated: | June 20, 2006 |
| Description: |
Hendrik Weimer discovered that specially crafted web requests can
cause awstats, a powerful and featureful web server log analyzer, to
execute arbitrary commands. |
| Alerts: |
|
Comments (none posted)
cscope: buffer overflows
| Package(s): | cscope |
CVE #(s): | CVE-2004-2541
|
| Created: | May 22, 2006 |
Updated: | June 12, 2006 |
| Description: |
A buffer overflow in Cscope 15.5, and possibly multiple overflows, allows
remote attackers to execute arbitrary code via a C file with a long
#include line that is later browsed by the target. |
| Alerts: |
|
Comments (1 posted)
dia: format string vulnerabilities
| Package(s): | dia |
CVE #(s): | CVE-2006-2453
CVE-2006-2480
|
| Created: | May 24, 2006 |
Updated: | June 8, 2006 |
| Description: |
The dia drawing utility suffers from several format string vulnerabilities exploitable via a maliciously crafted dia file - or a file with a well-chosen name. |
| Alerts: |
|
Comments (none posted)
hostapd: insufficient boundary checks
| Package(s): | hostapd |
CVE #(s): | CVE-2006-2213
|
| Created: | May 22, 2006 |
Updated: | May 25, 2006 |
| Description: |
Matteo Rosi and Leonardo Maccari discovered that hostapd, a wifi network
authenticator daemon, performs insufficient boundary checks on a key length
value, which might be exploited to crash the service. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-1859
CVE-2006-1860
|
| Created: | May 19, 2006 |
Updated: | May 24, 2006 |
| Description: |
Memory leak in __setlease in fs/locks.c in Linux kernel before 2.6.16.16
allows attackers to cause a denial of service (memory consumption) via
unspecified actions related to an "uninitialized return value," aka "slab
leak."
lease_init in fs/locks.c in Linux kernel before 2.6.16.16 allows attackers
to cause a denial of service (fcntl_setlease lockup) via actions that cause
lease_init to free a lock that might not have been allocated on the stack. |
| Alerts: |
|
Comments (none posted)
kernel-patch-vserver: privilege escalation
| Package(s): | kernel-patch-vserver |
CVE #(s): | CVE-2006-2110
|
| Created: | May 22, 2006 |
Updated: | May 24, 2006 |
| Description: |
Jan Rekorajski discovered that the kernel patch for virtual private servers
does not limit context capabilities to the root user within the virtual
server, which might lead to privilege escalation for some virtual server
specific operations. |
| Alerts: |
|
Comments (none posted)
kphone: insecure file creation
| Package(s): | kphone |
CVE #(s): | CVE-2006-2442
|
| Created: | May 22, 2006 |
Updated: | May 25, 2006 |
| Description: |
Sven Dreyer discovered that KPhone, a Voice over IP client for KDE,
creates a configuration file world-readable, which could leak sensitive
information like SIP passwords. |
| Alerts: |
|
Comments (none posted)
libextractor: heap-based buffer overflows
| Package(s): | libextractor |
CVE #(s): | CVE-2006-2458
|
| Created: | May 22, 2006 |
Updated: | May 31, 2006 |
| Description: |
Luigi Auriemma has found two heap-based buffer overflows in libextractor
0.5.13 and earlier: one of them occurs in the asf_read_header function in
the ASF plugin, and the other occurs in the parse_trak_atom function in the
Qt plugin. |
| Alerts: |
|
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)
OpenLDAP: boundary error
| Package(s): | openldap |
CVE #(s): | |
| Created: | May 23, 2006 |
Updated: | May 24, 2006 |
| Description: |
According to this Secunia
advisory, a weakness exists in OpenLDAP which is caused due to a
boundary error in slurpd within the handling of the status file. This can
be exploited to cause a stack-based buffer overflow via an overly long
hostname read from the status file. The weakness has been reported to be in
OpenLDAP version 2.3.21 and earlier. |
| Alerts: |
|
Comments (none posted)
phpbb2: missing input sanitizing
| Package(s): | phpbb2 |
CVE #(s): | CVE-2006-1896
|
| Created: | May 22, 2006 |
Updated: | February 11, 2008 |
| Description: |
It was discovered that phpbb2, a web based bulletin board, insufficiently
sanitizes values passed to the "Font Color 3" setting, which might lead to
the execution of injected code by admin users. |
| Alerts: |
|
Comments (none posted)
phpgroupware: missing input sanitizing
| Package(s): | phpgroupware |
CVE #(s): | CVE-2005-2781
|
| Created: | May 22, 2006 |
Updated: | May 24, 2006 |
| Description: |
It was discovered that the Avatar upload feature of FUD Forum, a component
of the web based groupware system phpgroupware, does not sufficiently
validate uploaded files, which might lead to the execution of injected web
script code. |
| Alerts: |
|
Comments (none posted)
popfile: missing input sanitizing
| Package(s): | popfile |
CVE #(s): | CVE-2006-0876
|
| Created: | May 22, 2006 |
Updated: | May 24, 2006 |
| Description: |
It has been discovered that popfile, a bayesian mail classifier, can
be forced into a crash through malformed character sets within email
messages, which allows denial of service. |
| Alerts: |
|
Comments (none posted)
postgresql: SQL injection
| Package(s): | postgresql |
CVE #(s): | CVE-2006-2313
CVE-2006-2314
|
| Created: | May 24, 2006 |
Updated: | June 6, 2007 |
| Description: |
The PostgreSQL team has put out a set of "urgent updates" (in the form of the 7.3.15, 7.4.13, 8.0.8, and 8.1.4 releases) closing a
newly-discovered set of SQL injection issues. Details about the problem
can be found on the
technical information page; in short: multi-byte encodings can be used
to defeat normal string sanitizing techniques. The update fixes one problem
related to invalid multi-byte characters, but punts on another by simply
disallowing the old, unsafe technique of escaping single quotes with a
backslash. |
| Alerts: |
|
Comments (1 posted)
zoo: archive problem
| Package(s): | bin |
CVE #(s): | |
| Created: | May 23, 2006 |
Updated: | May 24, 2006 |
| Description: |
A security problem
is zoo's fullpath() function could cause problems if zoo was run in an
automated way, or if a user were to open a malicious zoo archive manually. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
apache: denial of service
| Package(s): | apache |
CVE #(s): | |
| Created: | May 11, 2006 |
Updated: | May 17, 2006 |
| Description: |
There a bug involving Apache 1.3.35 and glib concerning
wildcards in Include directives. If an Include statement
is issued in an already included file, Apache can be caused to
crash. |
| Alerts: |
|
Comments (1 posted)
blender: integer overflow
| Package(s): | blender |
CVE #(s): | CVE-2005-4470
|
| Created: | January 6, 2006 |
Updated: | June 15, 2006 |
| Description: |
Damian Put discovered that Blender did not properly validate a 'length'
value in .blend files. Negative values led to an insufficiently sized
memory allocation. By tricking a user into opening a specially crafted
.blend file, this could be exploited to execute arbitrary code with the
privileges of the Blender user. |
| 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)
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)
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)
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)
fbida: insecure temporary file creation
| Package(s): | fbida |
CVE #(s): | CVE-2006-1695
|
| Created: | April 24, 2006 |
Updated: | May 22, 2006 |
| Description: |
The fbgs script in the fbi package 2.01-1.4, when the TMPDIR environment
variable is not defined, allows local users to overwrite arbitrary files
via a symlink attack on temporary files in /var/tmp/fbps-[PID]. |
| Alerts: |
|
Comments (none posted)
fetchmail: multidrop bug
| Package(s): | fetchmail |
CVE #(s): | CVE-2005-4348
|
| Created: | December 20, 2005 |
Updated: | May 27, 2006 |
| Description: |
Fetchmail contains a bug which allows a malicious mail server to crash the
client by sending a message without headers. This occurs when running in
multidrop mode. |
| Alerts: |
|
Comments (none posted)
firefox: multiple vulnerabilities
Comments (1 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)
freeradius: authentication bypass
| Package(s): | freeradius |
CVE #(s): | CVE-2006-1354
|
| Created: | March 24, 2006 |
Updated: | June 5, 2006 |
| Description: |
An unspecified vulnerability in FreeRADIUS 1.0.0 up to 1.1.0 allows remote
attackers to bypass authentication or cause a denial of service (server
crash) via "Insufficient input validation" in the EAP-MSCHAPv2 state
machine module. |
| 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)
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)
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)
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
| 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: multiple vulnerabilities
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: 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: denial of service
| Package(s): | libtiff |
CVE #(s): | CVE-2006-2024
|
| Created: | April 28, 2006 |
Updated: | May 31, 2006 |
| Description: |
Multiple vulnerabilities in libtiff before 3.8.1 allow context-dependent
attackers to cause a denial of service via a TIFF image that triggers
errors in (1) the TIFFFetchAnyArray function in (a) tif_dirread.c; (2)
certain "codec cleanup methods" in (b) tif_lzw.c, (c) tif_pixarlog.c, and
(d) tif_zip.c; (3) and improper restoration of setfield and getfield
methods in cleanup functions within (e) tif_jpeg.c, tif_pixarlog.c, (f)
tif_fax3.c, and tif_zip.c. |
| Alerts: |
|
Comments (none posted)
mailman: denial of service
| Package(s): | mailman |
CVE #(s): | CVE-2006-0052
|
| Created: | March 30, 2006 |
Updated: | June 9, 2006 |
| Description: |
Mailman 2.1.5 and below have a denial of service vulnerability
in the Scrubber.py script. If a maliciously created message
with a mime multi part format is received, mailman delivery
can be stopped. |
| 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: |
|