The third GPLv3 draft
The original plans had called for the third draft of the GNU General Public
License update to come out late last year. Needless to say, things didn't
happen that way. Between trying to address concerns raised from various
directions and responding to the Microsoft/Novell deal, the Free Software
Foundation ended up having to slip its schedule; as a result, eight months
have passed since
the second
draft was released. One could well argue that
a major license update should not be made in a hurry, and thus the delays
are not problematic. In any case, the wait is over: the
new
GPLv3 draft is available. In many ways, the draft resembles its
predecessors; in others, it has changed significantly. This article will
focus on the differences.
One area of conflict has been the anti-DRM provisions. The relatively
uncontroversial language stating that GPLv3-licensed works are not
"technological measures" has been reworked slightly to give it a more
international focus:
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under
article 11 of the WIPO copyright treaty adopted on 20 December
1996, or similar laws prohibiting or restricting circumvention of
such measures.
The previous draft had been specific to the DMCA, but anti-circumvention
laws are a global issue, so this change makes sense.
The "anti-tivoization" provisions have been the source of much of the
disagreement over this license. The new draft changes those sections
significantly - though the intent remains the same, and people who did not
like the previous versions are unlikely to feel better about the new
language. In previous drafts, signing keys required to convince hardware
to run a given binary were deemed to be part of the source code, and thus a
required part of the (required) source distribution. The drafters decided
that extending the definition of "source code" in this way was not the best
idea. So, instead, we now have "installation information":
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to
install and execute modified versions of a covered work in that
User Product from a modified version of its Corresponding Source.
The information must suffice to ensure that the continued
functioning of the modified object code is in no case prevented or
interfered with solely because modification has been made.
The license goes on to say that, if GPLv3-licensed code is shipped as part
of a product, the installation instructions must be made available as well.
Actually, it's not anywhere near that simple, for a couple of reasons. The
first is this concept of a "user product," which is new in this draft:
A "User Product" is either (1) a "consumer product", which means
any tangible personal property which is normally used for personal,
family, or household purposes, or (2) anything designed or
sold for incorporation into a dwelling.
The actual requirement for the shipping of installation information is:
If you convey an object code work under this section in, or with,
or specifically for use in, a User Product, and the conveying
occurs as part of a transaction in which the right of possession
and use of the User Product is transferred to the recipient in
perpetuity or for a fixed term (regardless of how the transaction
is characterized), the Corresponding Source conveyed under this
section must be accompanied by the Installation Information.
One might well wonder what is going on here. In the explanation materials
sent to LWN with the license draft, the FSF states:
After some discussion with committees, we discovered that the
proposals in the second discussion draft would interfere with a
number of existing business models that don't seem to be dangerous.
We believe that this compromise will achieve the greatest success
in preventing tivoization.
The nature of these innocuous business models is not spelled out. What it
comes down to, though, is that gadgets intended to be sold to businesses
will be exempt from the "installation instructions" requirements. This
seems strange; it may well be businesses which would have the most use for
the ability to change the code running in devices they purchase. The FSF
has been saying that the right to replace the software in a device is
required for true software freedom; why is that right now less important
for devices which are not "user products"?
This exemption could prove to be a big loophole.
Many years ago, your editor bought a digital audio tape deck. The rules
for DAT decks in those days specified that they must implement the "serial
copy management system" - a couple of bits in the digital audio data stream which
indicated whether another deck was allowed to record that stream or not. It turned
out that decks intended for "professional use" were exempt, however -
musicians, after all, might actually want to make copies of their work. As
far as your editor could tell, the difference between "professional" and
"consumer" decks (at the low end, anyway) consisted of a pair of rack-mount
ears; "professional" decks were available at the local guitar shop.
Anybody could get a SCMS-free deck with little trouble. The exemption for
devices which are not "user products" looks similar; with
this language, the FSF may well be setting us up for a flood of "business
use" gadgets which happen to available at the local big-box technology
store.
The "additional terms" section has been simplified a bit. The second draft
included the optional requirement that, if the covered code is used to
implement a web service, the users should be able to get the source via
that service. This requirement, intended to close the "web services
loophole," is absent from the third draft.
The termination rules still allow any copyright holder to terminate the
license if it is violated. There is a new escape clause, though:
However, if this is your first violation of this License with
respect to a given copyright holder, and you cure the violation
within 30 days following your receipt of the notice, then your
license is automatically reinstated.
An opportunity to fix a GPL violation is consistent with how the license
has been enforced so far.
The patent language has changed significantly as well. The second draft
included a covenant not to enforce any relevant patents against recipients of
the software; in the third draft, instead, an explicit patent license is
granted. This change is apparently intended to make the patent grant
language look more like that found in other licenses.
The change which will attract the most attention, though, is the
language aimed at the Microsoft/Novell deal; it does not look like
anything found elsewhere. It starts by broadening the definition of a
"patent license" to include things like covenants not to sue, thus covering
the Novell non-license. There is a clause saying that if you distribute
covered code under the protection of such a license, you must arrange for
all recipients - anywhere - to have the same protection. Then there's this
part:
You may not convey a covered work if you are a party to an
arrangement with a third party that is in the business of
distributing software, under which you make payment to the third
party based on the extent of your activity of conveying the work,
and under which the third party grants, to any of the parties who
would receive the covered work from you, a patent license (a) in
connection with copies of the covered work conveyed by you, and/or
copies made from those, or (b) primarily for and in connection with
specific products or compilations that contain the covered work,
which license does not cover, prohibits the exercise of, or is
conditioned on the non-exercise of any of the rights that are
specifically granted to recipients of the covered work under this
License.
The FSF is still considering whether it should grandfather in deals made
before this draft was released.
The restriction to deals involving software companies is strange; it will
just cause the next deal to be done by way of a patent-troll
corporation. The prohibition only applies if the payments are based on the
number of copies distributed, meaning that the next such deal will look
like a fixed-sum payment - we will never know how that sum was calculated.
There are enough loopholes in this section that
it seems unlikely to slow down the next patent shakedown in any significant
way. If the grandfather clause is added, it will not even affect Novell,
the target of this whole thing.
There is an interesting new exception in this draft:
Notwithstanding any other provision of this License, you have
permission to link any covered work with a work licensed under
version 2 of the Affero General Public License, and to convey the
resulting combination. The terms of this License will continue to
apply to your covered work but will not apply to the work with
which it is linked, which will remain governed by the Affero
General Public License.
The posted version of the Affero
GPL is version 1; your editor was not able to find any mention of
a second version anywhere. The FSF must know something the rest of us are
not yet privy to.
Finally, there is explicit support for signing away the right to decide on
future license changes to others:
If the Program specifies that a proxy can decide whether future
versions of the GNU General Public License shall apply, that
proxy's public statement of acceptance of any version is permanent
authorization for you to choose that version for the Program.
There are various other tweaks - providing source by way of a network
server is now officially allowed, for example. In many ways, GPLv3 is
shaping up exactly as it was supposed to: it is bringing the license up
to contemporary, worldwide standards and is evolving in response to input
from the community. Your editor anticipates that the new anti-DRM and
anti-Novell language will be the subject of significant criticism,
however. They are developing the complex, baroque nature of code which has
been repeatedly patched far beyond its original design. That language may
require some work yet.
The current plan calls for the FSF to accept comments on this draft for the
next 60 days, after which the final draft will be released. One month
later - around the end of June - the GPLv3 will become official. The FSF
claims to be actively looking for comments, so now is the time for anybody
who has remaining concerns to speak up. Regardless of whether certain
high-profile projects move to GPLv3, we all will be working with code
covered by this new license. It's important that we help the FSF get it
right.
Comments (55 posted)
Beryl and Compiz: back together again?
Once upon a time, just over one year ago, the
Compiz window
manager
hit
the net. Compiz, which features fancy 3D effects, was the result of
some months' worth of behind-closed-doors work at Novell. There was an
enthusiastic reception, and others began to hack on the code. It didn't
take long, however, before some of those others found that it was hard to
get their changes back into the Compiz mainline. Eventually one of those
developers, Quinn Storm, got tired of carrying an increasing collection of
external patches. The result was a fork, and the
Beryl project was created.
These events can be acrimonious, and the Compiz/Beryl fork was no
exception. Beryl developers complained that Compiz was run as a Novell
fiefdom which was uninterested in patches from the outside. On the Compiz
side, Beryl's decision to relicense the code from the MIT license to the
GPL meant that code could flow from Compiz to Beryl, but not in the other
direction. In early 2007, a Compiz site administrator vandalized Beryl's site, an
act which must surely mark a low point in relations between the two
projects.
During this time, development on both sides continued, with Beryl quickly
developing a reputation for bells, whistles, and an unbelievable number of
configuration options. Compiz took a more conservative course, working on
getting the core functionality working in a way which seemed, to its core
developers, to be right. Despite all of this, the differences between the
two code bases are apparently less than one might think. No major
architectural change have happened; instead, most of Beryl's additions come
in the form of plugins.
Recently, though, the Beryl developers started to ponder some more
sweeping changes. According to Robert
Carr, the conversation went like this:
Around a month and a half ago some of us were discussing some
rather radical changes to the design of beryl-core which we
inherited from Compiz, this inevitably led to "We should talk to
Compiz about this to keep things synced", which even more
inevitably leads to "If we are going to talk to Compiz to keep our
designs similar, so on, so forth, are our differences really so
large that we need to be two seperate projects?".
The result was that the two projects started talking again. As of this
writing, it would appear that Beryl and Compiz have come to an agreement to
end the fork and join back into a single project. Should things happen
this way, the results for eye-candy fans should be good. There are a few
details which need to be worked out first, though.
One of those is licensing. The fact that Beryl's work is licensed under
the GPL means that, for the two projects to merge, one of them must be
relicensed. It looks like Beryl will be the one to give here,
moving its core back to the MIT license. The number of contributors is
evidently sufficiently small that this sort of change is still feasible.
Then there is the issue of how to merge the changes in the code. According
to Mr. Carr, agreement has been reached on most points, at least with
regard to the core changes. In the past, Compiz leader David Reveman has
not been receptive to Beryl code:
With a few notable exceptions, most of the code I've seen going
into what is now beryl is not high quality code that would be
considered for compiz.
It seems that the situation is different
now:
The technical part of the merge seems pretty straight forward from
my point of view and I've got the understanding that so is also the
case for the main contributors to the core of beryl.
The merge is probably helped by the Compiz
project's plan to split the code into "core" and "extra" modules.
Much of what is currently in Beryl will, it seems, slip into compiz-extra
with little trouble.
So if licensing and code are not problems, what are the potential sticking
points in this merger? It seems that there are two of them: naming and
leadership. The Beryl side is pushing for a new name and structure which
would enable a clean start for the entire project. Without that, they
fear, one side or the other will probably get the short end of the stick.
Mr. Reveman responds:
The merge is done by moving changes made to beryl into compiz or by
adding alternative solutions to compiz. No changes are made to the
design of compiz and 99% of the code is still code being written as
part of the compiz project so I'm having a hard time to justify a
name change of the core and I know that most people in the compiz
community are firmly against such a name change.
From reading the discussion, one gets the sense that the leadership issues
have not yet been the subject of serious discussion. Some sort of project
management model will have to be worked out, or the newly merged project
will run a risk of falling victim to the same tensions and forking again.
There should be an answer, though.
It would be a sad day if these two projects could come together, resolve
their technical and licensing differences, then drop the whole thing
because they cannot agree on the name. Some great progress has been made
on reunifying one of the most unpleasant forks in our community; it seems
like the remaining issues must somehow be amenable to a solution.
Comments (8 posted)
Working with raw images on Linux
Your editor's
exploration of high
dynamic range (HDR) techniques inspired one
comment suggesting that
photographic topics should be avoided in the future if your editor wishes
to avoid looking foolish. As it happens, fear of looking foolish would
make this particular job almost impossible to do; when one writes for an
audience that knows more than the author, occasional foolishness will
inevitably result. Even for authors who are not so inherently foolish as
your editor. So, foolish or not, here is a followup to the HDR article;
this week's topic is working with raw files.
Most digital cameras are set to produce JPEG files; for many applications,
such files are more than good enough. But most decent cameras support
other formats, and a vendor-specific raw format in particular. The raw
format contains something close to what was measured by the sensor, with a
minimum of processing in the camera. These files are large, unwieldy, and
in a proprietary format, which argues against their use in many
situations. But, by virtue of holding the original image data, raw files
give the photographer a much wider range of options later on. Much of the
processing normally done in the camera (white balance, histogram
adjustment, etc.) can be tweaked later on. For this reason, people who do
photography for a living often prefer to record in the raw format.
Even for the rest of us, who have no hope of earning a living that way, raw
files can keep creative options open. For people who like to play with HDR
techniques there is an additional advantage: the camera typically record 12
to 16 bits of data for each channel - rather more than fits into a JPEG
file. That, in turn, means that the dynamic range of raw files is
significantly higher - assuming, of course, that the camera has a sensor
which can meaningfully record data at that resolution. The extra range can
be used to increase detail in images in a number of ways, including the use
of tone mapping techniques.
Raw file formats are created by camera manufacturers, who generally feel no
need to document their work. They will usually sell you a tool for
decrypting their raw files - but, strangely enough, Linux support is
usually missing from the feature list. Fortunately, the free software
world benefits from the work of Dave Coffin, who has set a task for
himself:
So here is my mission: Write and maintain an ANSI C program that
decodes any raw image from any digital camera on any computer
running any operating system.
The result is dcraw,
which comes awfully close to meeting that goal. It supports a huge list of
cameras, and it does so at a high level of quality - arguably better than the vendor's
tools. It is a command-line tool, aimed at batch operation or
invocation from other programs; dcraw can be run from a gimp plugin, for
example. Just about anything one wants to do with a
raw image file is supported by dcraw.
The only downside is that processing raw images can be an interactive
process. If one wants to make adjustments, a command-line tool can get
tiresome after a while. The answer to that complaint is the UFRaw tool, which is built on
dcraw. UFRaw allows adjustment of the white and black points, gamma curve,
white balance and more - all with immediate visual feedback. When the
desired result is achieved, it can be saved in a number of formats.
UFRaw is not perfect. It's one of those applications that thinks it's
clever to remember where the last image was stored and put the next one in
the same directory. Your editor, instead, expects programs to default to the
directory they were started in, or, failing that, to the directory where
the source file was found. It's aggravating to save a file then have to
figure out where the application decided to put it. UFRaw is doubly
obnoxious in this regard because it immediately exits after saving the
file. The non-resizeable window is also annoying.
One assumes these little difficulties can be dealt with eventually;
meanwhile, the core functionality is good stuff.
What sort of results can one expect? Here are three versions of the window
view photo featured in the HDR article:
| Original | UFRaw edited |
Tone mapped |
![[Original]](/images/ns/grumpy/hdr/window-orig-sm.jpg) |
![[UFRaw]](/images/ns/grumpy/hdr/window-ufr-edited-sm.jpg) |
![[ToneMapped]](/images/ns/grumpy/hdr/window-ufr-tm-sm.png) |
(See this page for larger versions of the
pictures).
Some quick editing with UFRaw was sufficient to bring out a fair amount of
detail in the plant in the foreground - though the background lost some
contrast as a result. The tone-mapped photo does better at maintaining
contrast throughout the frame. The end result is not as complete as the
full HDR image (visible here), but it does show that raw
files contain information which can be recovered later on to improve the
picture. Taking a single raw image is much easier than the full bracketed
HDR technique, and it allows tone mapping techniques to be used on subjects
which stubbornly refuse to stand still for a few minutes while several
shots are taken.
One thing worth noting in conclusion: we should not take our ability to
work with raw images for granted. Vendors like Nikon and Sony are known
for encrypting their raw formats. The language they use to justify
themselves will look most familiar; consider this
advisory from Nikon regarding its NEF format:
As a proprietary format, Nikon secures NEF's structure and
processing through various technologies. Securing this structure is
intended for the photographer's benefit, and dedicated to ensuring
faithful reproduction of the photographer's creative intentions
through consistent performance and rendition of the images.
In other words, photographers are being locked out of their own images for
their own benefit. All of the usual counterarguments apply here;
photographers might just have their own idea of where there benefit lies.
And what happens to those raw images a decade or two from now, when the
vendor has long since ceased to support the format and, even if one can
find one's single legal backup copy of the software, it refuses to run on
currently available systems? Fortunately, we have dcraw, which will
document the reading of these formats indefinitely.
So far, vendors' attempts to encrypt raw files have been broken in short
order. Chances are that trend will continue. But there is little
difference between breaking into a raw image file and turning off the copy
protection bits inside a PDF file. The stage is clearly set for an ugly
battle, probably involving the DMCA, when some vendor decides to turn
nasty.
Photographers have been worried about this issue for a few years now;
efforts like the OpenRAW project have
been working, with little success, to get camera manufacturers to open up
their formats. Adobe has been pushing its Digital Negative format as a
standard; it would be a step in the right direction, but this format still
has mechanisms for the embedding of vendor "private" information. At this
time, there does not seem to be a clear solution in sight. We must deal
with cameras just like we deal with many other types of hardware: we have
to figure out how it works ourselves.
Comments (13 posted)
Page editor: Jonathan Corbet
Security
Metasploit 3.0
March 28, 2007
This article was contributed by Jake Edge.
The
Metasploit Framework,
a popular open source framework for penetration testing and security tool
development, has just
released its 3.0 version that
provides many new features. The framework has been completely rewritten
from version 2, moving from Perl to Ruby in the process.
In many ways, Metasploit 3 seeks to be the swiss army knife of network
vulnerability research and testing, providing a wealth of tools for
security researchers.
At its core, Metasploit provides a means to launch an exploit at a particular
host, execute the payload and provide a shell that communicates with the
payload. The exploits provided with the framework are known vulnerabilities
for various operating systems and the payloads are different ways to execute
a shell on the exploited machine. This allows
users to probe hosts for susceptibility to known attacks and to combine
those attacks with different ways of getting a shell in an attempt to
avoid firewall and intrusion detection rules. In addition, Metasploit
makes it easy to add new payloads and exploits so that a researcher
can develop or work with entirely new vulnerabilities using the
familiar framework interface.
Once Metasploit has connected to an exploited system, an irb
(interactive ruby) shell from within the framework can be used to script
access to any accessible process on the remote system. Because it
provides a means to read and write the memory of those processes,
credentials like passwords could be grabbed or processes could be backdoored
in various ways. Another interesting feature allows an attacker to route all
Metasploit traffic through a compromised host, potentially bypassing
firewalls and routers. This is just a small sample of the tools that are
provided; this is a very potent toolkit.
There are two main interfaces to Metasploit, a console interface as well
as an AJAX-enabled web interface that is driven with
Ruby on Rails. Both provide
tab-completion of commands and arguments and are very convenient to use.
The web interface, however, feels rather sluggish, even running on the local
machine; it is mostly provided to allow demonstrations of using the tool.
There is also a command-line interface that can be used from scripts and the
like, but the console is the main interface workhorse.
The release comes with both a user and a developer guide and both are quite
readable and useful. The developer guide lays out the rationale behind
the switch to Ruby which makes for an interesting read. It notes
that Windows compatibility was one of the major reasons for the
switch, which makes it rather surprising that deficiencies in either Ruby
for Windows or Windows itself make some features (the entire console
interface for instance) usable only on Linux or other UNIX systems.
Metasploit was already an incredibly useful tool and it would appear that
version 3 takes a big step forward. As with all security tools, it can
be used for good or ill, but it is most certainly an essential arrow in
the quiver of anyone tasked with or interested in computer security.
Comments (3 posted)
New vulnerabilities
cups: denial of service
| Package(s): | cups |
CVE #(s): | CVE-2007-0720
|
| Created: | March 26, 2007 |
Updated: | February 7, 2008 |
| Description: |
Previous versions of the cups package could be forced to hang via a client
"partially negotiating" an ssl connection. In this state, cups would not
allow other connections to be made, a denial of service. |
| Alerts: |
|
Comments (none posted)
evolution: format string error
| Package(s): | evolution |
CVE #(s): | CVE-2007-1002
|
| Created: | March 27, 2007 |
Updated: | February 27, 2008 |
| Description: |
A format string error in the "write_html()" function in calendar/gui/
e-cal-component-memo-preview.c when displaying a memo's categories can
potentially be exploited to execute arbitrary code via a specially crafted
shared memo containing format specifiers. |
| Alerts: |
|
Comments (1 posted)
file: arbitrary code execution
| Package(s): | file |
CVE #(s): | CVE-2007-1536
|
| Created: | March 22, 2007 |
Updated: | May 30, 2007 |
| Description: |
The "file" utility incorrectly checks the allocated heap memory size.
If a remote attacker can trick a user into looking at specially crafted
files with file, arbitrary code can be executed with the user's privileges. |
| Alerts: |
|
Comments (1 posted)
firefox: FTP PASV port-scanning
| Package(s): | firefox seamonkey |
CVE #(s): | CVE-2007-1562
|
| Created: | March 23, 2007 |
Updated: | June 4, 2007 |
| Description: |
According to this
advisory, the FTP protocol includes the PASV (passive) command which is
used by Firefox to request an alternate data port. The specification of the
FTP protocol allows the server response to include an alternate server
address as well, although this is rarely used in practice. |
| Alerts: |
|
Comments (1 posted)
mysql: denial of service
| Package(s): | mysql |
CVE #(s): | CVE-2007-1420
|
| Created: | March 22, 2007 |
Updated: | May 21, 2008 |
| Description: |
MySQL subselect queries using "ORDER BY" can be used by an attacker with
access to a MySQL instance in order to create an intermittent denial
of service. |
| Alerts: |
|
Comments (none posted)
squid: denial of service
| Package(s): | squid |
CVE #(s): | CVE-2007-1560
|
| Created: | March 23, 2007 |
Updated: | April 3, 2007 |
| Description: |
Due to an internal error Squid-2.6 is vulnerable to a denial of service
attack when processing the TRACE request method. This problem allows any
client trusted to use the service to perform a denial of service attack on
the Squid service. |
| Alerts: |
|
Comments (none posted)
xmms: BMP handling vulnerability
| Package(s): | xmms |
CVE #(s): | CVE-2007-0653
CVE-2007-0654
|
| Created: | March 28, 2007 |
Updated: | April 5, 2007 |
| Description: |
xmms suffers from vulnerabilities in its handling of BMP images. Should a hostile image be included in an xmms skin, it could lead to code execution on the user's system. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
apache: cross-site scripting
| Package(s): | apache |
CVE #(s): | CVE-2006-3918
|
| Created: | August 9, 2006 |
Updated: | April 4, 2008 |
| Description: |
From the Red Hat advisory: "A bug was found in Apache where an invalid Expect header sent to the server
was returned to the user in an unescaped error message. This could
allow an attacker to perform a cross-site scripting attack if a victim was
tricked into connecting to a site and sending a carefully crafted Expect
header." |
| Alerts: |
|
Comments (none posted)
asterisk: SIP denial of service
| Package(s): | asterisk |
CVE #(s): | CVE-2007-1306
|
| Created: | March 19, 2007 |
Updated: | March 21, 2007 |
| Description: |
The MU Security Research Team discovered that Asterisk contains a
NULL-pointer dereferencing error in the SIP channel when handling request
messages. A remote attacker could cause an Asterisk server listening for
SIP messages to crash by sending a specially crafted SIP request message. |
| Alerts: |
|
Comments (2 posted)
bluez-utils: hidd vulnerability
| Package(s): | bluez-utils |
CVE #(s): | CVE-2006-6899
|
| Created: | January 16, 2007 |
Updated: | May 14, 2007 |
| Description: |
hidd in BlueZ (bluez-utils) before 2.25 allows remote attackers to obtain
control of the Mouse and Keyboard Human Interface Device (HID) via a
certain configuration of two HID (PSM) endpoints, operating as a server,
aka HidAttack. |
| Alerts: |
|
Comments (none posted)
bugzilla: multiple vulnerabilities
| Package(s): | bugzilla |
CVE #(s): | CVE-2006-5453
CVE-2006-5454
CVE-2006-5455
|
| Created: | November 10, 2006 |
Updated: | August 28, 2007 |
| Description: |
Bugzilla has the following vulnerabilities:
Input data passed to various fields is not properly sanitized before
being passed back to users.
Users can gain unauthorized access to read attachment
descriptions while using diff mode.
HTTP GET and HTTP POST requests can be used to perform unauthorized
actions due to improper verification.
Input that is passed to showdependencygraph.cgi is not properly
sanitized before being returned to users. |
| Alerts: |
|
Comments (none posted)
busybox: insecure password generation
| Package(s): | busybox |
CVE #(s): | CVE-2006-1058
|
| Created: | May 5, 2006 |
Updated: | May 2, 2007 |
| Description: |
The BusyBox 1.1.1 passwd command does not use a proper salt when generating
passwords. This would create an instance where a brute force attack could
take very little time. |
| Alerts: |
|
Comments (2 posted)
cpio: arbitrary code execution
| Package(s): | cpio |
CVE #(s): | CVE-2005-4268
|
| Created: | January 2, 2006 |
Updated: | May 8, 2007 |
| Description: |
Richard Harms discovered that cpio did not sufficiently validate file
properties when creating archives. Files with e. g. a very large size
caused a buffer overflow. By tricking a user or an automatic backup
system into putting a specially crafted file into a cpio archive, a
local attacker could probably exploit this to execute arbitrary code
with the privileges of the target user (which is likely root in an
automatic backup system). |
| Alerts: |
|
Comments (none posted)
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
| Package(s): | cyrus-sasl |
CVE #(s): | CVE-2006-1721
|
| Created: | April 21, 2006 |
Updated: | September 4, 2007 |
| Description: |
Cyrus-SASL contains an unspecified vulnerability in the DIGEST-MD5
process that could lead to a Denial of Service. An attacker could possibly
exploit this vulnerability by sending specially crafted data stream to the
Cyrus-SASL server, resulting in a Denial of Service even if the attacker is
not able to authenticate. |
| Alerts: |
|
Comments (none posted)
dovecot: index cache file handling error
| Package(s): | dovecot |
CVE #(s): | CVE-2006-5973
|
| Created: | November 29, 2006 |
Updated: | May 8, 2007 |
| Description: |
The dovecot IMAP server has an error in its index cache file handling code which could be exploited by an authenticated user to execute arbitrary code. Only servers with the (non-default) mmap_disable=yes option setting are vulnerable. |
| Alerts: |
|
Comments (none posted)
ekiga: format string vulnerability
| Package(s): | ekiga |
CVE #(s): | CVE-2007-1006
CVE-2007-0999
|
| Created: | February 21, 2007 |
Updated: | March 30, 2007 |
| Description: |
Ekiga contains a format string vulnerability in the code which processes
control messages from remote peers.
If a user was running Ekiga and listening for incoming calls, a remote
attacker could send a crafted call request, and execute arbitrary code with
the user's privileges. |
| Alerts: |
|
Comments (none posted)
fail2ban: denial of service
| Package(s): | fail2ban |
CVE #(s): | CVE-2006-6302
|
| Created: | February 16, 2007 |
Updated: | July 30, 2007 |
| Description: |
fail2ban 0.7.4 and earlier does not properly parse sshd logs file, which
allows remote attackers to add arbitrary hosts to the /etc/hosts.deny file
and cause a denial of service by adding arbitrary IP addresses to the sshd
log file, as demonstrated by logging in to ssh using a login name
containing certain strings with an IP address. |
| Alerts: |
|
Comments (3 posted)
ffmpeg: buffer overflows
| Package(s): | ffmpeg |
CVE #(s): | CVE-2006-4799
CVE-2006-4800
|
| Created: | September 14, 2006 |
Updated: | May 28, 2007 |
| Description: |
the AVI processing code in FFmpeg has a number of buffer overflow
vulnerabilities.
If an attacker can trick a user into loading a specially crafted
crafted AVI, arbitrary code can be executed with the user's privileges. |
| Alerts: |
|
Comments (2 posted)
freeradius: several vulnerabilities
| Package(s): | freeradius |
CVE #(s): | CVE-2005-4745
CVE-2005-4746
|
| Created: | August 8, 2006 |
Updated: | April 24, 2007 |
| Description: |
Several remote vulnerabilities have been discovered in freeradius, a
high-performance RADIUS server, which may lead to SQL injection or denial
of service. |
| Alerts: |
|
Comments (none posted)
freetype: integer overflows
| Package(s): | freetype |
CVE #(s): | CVE-2006-0747
CVE-2006-1861
CVE-2006-2493
CVE-2006-2661
CVE-2006-3467
|
| Created: | June 8, 2006 |
Updated: | October 10, 2007 |
| Description: |
The FreeType library has several integer overflow vulnerabilities.
If a user can be tricked into installing a specially
crafted font file, arbitrary code can be executed with the privilege
of the user. |
| Alerts: |
|
Comments (none posted)
gcc: file overwrite vulnerability
| Package(s): | gcc |
CVE #(s): | CVE-2006-3619
|
| Created: | September 6, 2006 |
Updated: | March 14, 2008 |
| Description: |
The fastjar utility found in the GNU compiler collection does not perform adequate file path checking, allowing the creation or overwriting of files outside of the current directory tree. |
| Alerts: |
|
Comments (none posted)
gd: buffer overflow
| Package(s): | gd |
CVE #(s): | CVE-2007-0455
|
| Created: | February 7, 2007 |
Updated: | February 28, 2008 |
| Description: |
The gd graphics library contains a buffer overflow which could enable a remote attacker to execute arbitrary code. Note that various other packages include code from gd and could also be vulnerable. |
| Alerts: |
|
Comments (2 posted)
gdb: buffer overflow
| Package(s): | gdb |
CVE #(s): | CVE-2006-4146
|
| Created: | September 15, 2006 |
Updated: | June 12, 2007 |
| Description: |
A buffer overflow in dwarfread.c and dwarf2read.c debugging code in GNU
Debugger (GDB) 6.5 allows user-assisted attackers, or restricted users, to
execute arbitrary code via a crafted file with a location block
(DW_FORM_block) that contains a large number of operations. |
| Alerts: |
|
Comments (none posted)
gdm: improper file permissions
| Package(s): | gdm |
CVE #(s): | CVE-2006-1057
|
| Created: | April 19, 2006 |
Updated: | May 2, 2007 |
| Description: |
The .ICEauthority file may be created with the wrong ownership and permissions; gdm 2.14.2 fixes the problem. |
| Alerts: |
|
Comments (none posted)
GnuPG: unsigned data injection vulnerability
| Package(s): | gnupg |
CVE #(s): | CVE-2007-1263
|
| Created: | March 6, 2007 |
Updated: | March 30, 2007 |
| Description: |
Core Security Technologies has reported
that GnuPG and GnuPG clients are vulnerable to an unsigned data injection
vulnerability. |
| Alerts: |
|
Comments (none posted)
gv: stack-based buffer overflow
| Package(s): | gv |
CVE #(s): | CVE-2006-5864
|
| Created: | November 20, 2006 |
Updated: | April 9, 2007 |
| Description: |
Stack-based buffer overflow in the ps_gettext function in ps.c for GNU gv
3.6.2, and possibly earlier versions, allows user-assisted attackers to
execute arbitrary code via a PostScript (PS) file with certain headers that
contain long comments, as demonstrated using the DocumentMedia header. |
| Alerts: |
|
Comments (none posted)
gzip: multiple vulnerabilities
| Package(s): | gzip |
CVE #(s): | CVE-2006-4334
CVE-2006-4335
CVE-2006-4336
CVE-2006-4337
CVE-2006-4338
|
| Created: | September 19, 2006 |
Updated: | June 1, 2007 |
| Description: |
Tavis Ormandy of the Google Security Team discovered two denial of service
flaws in the way gzip expanded archive files. If a victim expanded a
specially crafted archive, it could cause the gzip executable to hang or
crash.
Tavis Ormandy of the Google Security Team discovered several code execution
flaws in the way gzip expanded archive files. If a victim expanded a
specially crafted archive, it could cause the gzip executable to crash or
execute arbitrary code. |
| Alerts: |
|
Comments (1 posted)
horde-kronolith: local file inclusion
| Package(s): | horde-kronolith |
CVE #(s): | CVE-2006-6175
|
| Created: | January 17, 2007 |
Updated: | March 7, 2008 |
| Description: |
Kronolith contains a mistake in lib/FBView.php where a raw, unfiltered
string is used instead of a sanitized string to view local files. An
authenticated attacker could craft an HTTP GET request that uses directory
traversal techniques to execute any file on the web server as PHP code,
which could allow information disclosure or arbitrary code execution with
the rights of the user running the PHP application (usually the webserver
user). |
| Alerts: |
|
Comments (none posted)
imlib2: arbitrary code execution
| Package(s): | imlib2 |
CVE #(s): | CVE-2006-4806
CVE-2006-4807
CVE-2006-4808
CVE-2006-4809
|
| Created: | November 6, 2006 |
Updated: | August 13, 2007 |
| Description: |
M. Joonas Pihlaja discovered that imlib2 did not sufficiently verify the
validity of ARGB, JPG, LBM, PNG, PNM, TGA, and TIFF images. If a user
were tricked into viewing or processing a specially crafted image with
an application that uses imlib2, the flaws could be exploited to execute
arbitrary code with the user's privileges. |
| Alerts: |
|
Comments (none posted)
inkscape: format string vulnerabilities
| Package(s): | inkscape |
CVE #(s): | CVE-2007-1463
CVE-2007-1464
|
| Created: | March 21, 2007 |
Updated: | April 16, 2007 |
| Description: |
Inkscape has a format string vulnerability in its URI handling, possibly
allowing an attacker to execute code with user privileges via a specially
crafted file.
Format string vulnerability in the whiteboard Jabber protocol in Inkscape
before 0.45.1 allows user-assisted remote attackers to execute arbitrary
code via unspecified vectors. |
| Alerts: |
|
Comments (none posted)
java: multiple vulnerabilities
| Package(s): | java |
CVE #(s): | CVE-2006-4339
CVE-2006-4790
CVE-2006-6731
CVE-2006-6736
CVE-2006-6737
CVE-2006-6745
|
| Created: | January 18, 2007 |
Updated: | June 8, 2007 |
| Description: |
java has multiple vulnerabilities, these include:
an RSA exponent padding attack vulnerability, two vulnerabilities
which allow untrusted applets to access data in other applets,
vulnerabilities that involve applets gaining privileges due to
serialization bugs in the JRE and buffer overflows in the java image
handling routines that can give attackers read/write/execute capabilities
for local files. |
| Alerts: |
|
Comments (1 posted)
kdelibs: denial of service
| Package(s): | kdelibs |
CVE #(s): | CVE-2007-1308
|
| Created: | March 8, 2007 |
Updated: | March 29, 2007 |
| Description: |
Kdelibs has a denial of service vulnerability that can be triggered in
Konqueror's use of KDE JavaScript. A null pointer dereference caused
by accessing the content of an iframe with an ftp:// URI in the src
attribute can be used to trigger the DOS. |
| Alerts: |
|
Comments (none posted)
kdelibs: cross-site scripting
| Package(s): | kdelibs konqeror |
CVE #(s): | CVE-2007-0537
|
| Created: | February 5, 2007 |
Updated: | August 13, 2007 |
| Description: |
Konqueror 3.5.5 does not properly parse HTML comments, which allows remote
attackers to conduct cross-site scripting (XSS) attacks and bypass some XSS
protection schemes by embedding certain HTML tags within a comment, a
related issue to CVE-2007-0478. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2006-5749
CVE-2006-4814
CVE-2006-6106
|
| Created: | January 5, 2007 |
Updated: | May 7, 2008 |
| Description: |
A security issue has been reported in Linux kernel due to an error in
drivers/isdn/i4l/isdn_ppp.c as the "isdn_ppp_ccp_reset_alloc_state()"
function never initializes an event timer before scheduling it with the
"add_timer()" function.
The mincore function in the kernel does not properly lock access to user
space, which has unspecified impact and attack vectors, possibly related to
a deadlock.
Another vulnerability has been reported in Linux kernel caused by a
boundary error within the handling of incoming CAPI messages in
net/bluetooth/cmtp/capi.c. This can be exploited to overwrite certain
Kernel data structures. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-4623
|
| Created: | October 18, 2006 |
Updated: | November 14, 2007 |
| Description: |
The kernel DVB layer can be caused to crash with maliciously-formatted unidirectional lightweight encapsulation (ULE) data. |
| Alerts: |
|
Comments (none posted)
kernel: multiple vulnerabilities
| Package(s): | kernel |
CVE #(s): | CVE-2007-0005
CVE-2007-1000
|
| Created: | March 15, 2007 |
Updated: | November 14, 2007 |
| Description: |
The Linux kernel has a boundary error problem with the
Omnikey CardMan 4040 driver read and write functions. This can be used
to cause a buffer overflow and possible execution or arbitrary code with
kernel privileges.
The ipv6_getsockopt_sticky function in
net/ipv6/ipv6_sockglue.c is vulnerable to a NULL pointer dereference.
Local users can use this to crash the kernel or to disclose kernel
memory. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-0007
CVE-2007-0006
|
| Created: | February 15, 2007 |
Updated: | November 14, 2007 |
| Description: |
Linux kernel versions from 2.6.9 to 2.6.20 have a denial of service
vulnerability. A remote attacker can cause the key_alloc_serial
function's key serial number collision avoidance code to have a
null dereference, resulting in a crash. |
| Alerts: |
|
Comments (1 posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-4535
CVE-2006-4538
|
| Created: | September 18, 2006 |
Updated: | December 3, 2007 |
| Description: |
Sridhar Samudrala discovered a local denial of service vulnerability
in the handling of SCTP sockets. By opening such a socket with a
special SO_LINGER value, a local attacker could exploit this to crash
the kernel. (CVE-2006-4535)
Kirill Korotaev discovered that the ELF loader on the ia64 and sparc
platforms did not sufficiently verify the memory layout. By attempting
to execute a specially crafted executable, a local user could exploit
this to crash the kernel. (CVE-2006-4538) |
| Alerts: |
|
Comments (none posted)
kernel: denial of service by memory consumption
| Package(s): | kernel |
CVE #(s): | CVE-2006-2936
|
| Created: | July 17, 2006 |
Updated: | November 14, 2007 |
| Description: |
The ftdi_sio driver (usb/serial/ftdi_sio.c) in Linux kernel 2.6.x up to
2.6.17, and possibly later versions, allows local users to cause a denial
of service (memory consumption) by writing more data to the serial port
than the driver can handle, which causes the data to be queued. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2007-0772
|
| Created: | February 23, 2007 |
Updated: | November 14, 2007 |
| Description: |
The Linux kernel before 2.6.20.1 allows remote attackers to cause a denial
of service (oops) via a crafted NFSACL 2 ACCESS request that triggers a free
of an incorrect pointer. |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-5757
|
| Created: | November 13, 2006 |
Updated: | November 14, 2007 |
| Description: |
From the MOKB-05-11-2006
advisory: "The ISO9660 filesystem handling code of the Linux
2.6.x kernel fails to properly handle corrupted data structures, leading to
an exploitable denial of service condition. This particular vulnerability
seems to be caused by a race condition and a signedness issue. When
performing a read operation on a corrupted ISO9660 fs stream, the
isofs_get_blocks() function will enter an infinite loop when
__find_get_block_slow() callback from sb_getblk() fails ("due to various
races between file io on the block device and getblk")." |
| Alerts: |
|
Comments (none posted)
kernel: denial of service
| Package(s): | kernel |
CVE #(s): | CVE-2006-2935
CVE-2006-4145
CVE-2006-3745
|
| Created: | September 1, 2006 |
Updated: | July 30, 2008 |
| Description: |
Previous versions of the kernel package are subject to several
vulnerabilities. Certain malformed UDF filesystems can cause the system to
crash (denial of service). Malformed CDROM firmware or USB storage devices
(such as USB keys) could cause system crash (denial of service), and if
they were intentionally malformed, can cause arbitrary code to run with
elevated privileges. In addition, the SCTP protocol is subject to a remote
system crash (denial of service) attack. |
| Alerts: |
|