The Grumpy Editor's guide to HDR with Linux
Your editor has long enjoyed photography. As a high school student, he
even pondered, briefly, the idea of pursuing photography as a career; for
better or for worse, common sense won out and your editor went to
engineering school instead. But taking pictures has remained an active
hobby, even if it has tended to degrade to the creation of a stream of
snapshots of the kids for grandparent consumption in recent years. The
advent of digital photography has brought a couple of your editor's
passions back together, with only one thing - free time - missing. But,
your editor has discovered, one of the keys to the finding of free time is
to take an activity of interest and redefine it as "work." Thus, this
article.
A while back, your editor stumbled across the Flickr HDR pool; some
of the photos in that pool were sufficiently amazing to inspire an
immediate "I wanna do that" reaction. The better part of a year later, it
finally became possible to learn a bit more about the process behind
those pictures. HDR (or high dynamic range)
photography is a set of techniques for overcoming the limitations of
contemporary hardware and, in the process, generating images which better
represent a scene as viewed by the human eye - or which appear to come from
a work of fantasy art.
The sensors in today's digital cameras have gotten good, but they still
fall short of the human eye in a few ways. In particular, the range of
light levels which can be captured by the sensor is not yet up to what film
can handle, and is far from what the eye can do. Anybody who has spent any
time taking pictures is familiar with this problem: one can take a
beautiful landscape picture, but, in the end result, the wild cloud
formations are washed out completely and the shadows just go black. Being
unable to capture a scene that one can see quite well can be most
frustrating.
The idea behind HDR, as it is used with photography, is to extend the
available dynamic range by taking multiple shots at different exposure
levels. For a given exposure, there will be a range of light levels which
will be captured with good resolution by the sensor; everything else gets
compressed at one end or the other. If one has a series of images at
different exposures and a reasonable model of the camera's response curve,
one can generate a composite image by using the parts of each source image
which are in the good part of the curve. So, in that landscape picture, a
very dark exposure can be used for the bright parts of the scene - clouds,
for example - while a bright exposure yields low-light details. By mixing
them together, the HDR algorithm can produce an image with full sensor
resolution across a much wider dynamic range.
As an example, consider the photograph below, taken from your editor's
dining room:
| Original | HDR |
|---|
![[Original]](/images/ns/grumpy/hdr/window-orig-sm.jpg) |
![[HDR]](/images/ns/grumpy/hdr/window-cf-sm.png) |
(Larger versions of the images are
available.) In the original, parts of the plant in the foreground are
entirely lost in the shadows. Meanwhile, the breathtaking view of Colorado
suburbia (with mountains in the distance) is washed out entirely. The HDR
version brings all of that detail back.
HDR is not applicable to all situations. It has a tendency to turn people
into cartoon characters. Beyond that, the need for multiple exposures
generally implies setting up a tripod and taking some time for the entire
process. It is thus not well suited to changing scenes, sports photography
(though baseball, perhaps, can be expected to stand still for the requisite
time), etc. It can work well for relatively static scenes: landscapes,
buildings, the SCO case, and so on.
Most of the people playing with HDR seem to be using proprietary plugins
for a proprietary image manipulation program running under a proprietary
operating system. That is, needless to say, not your editor's preferred
mode of operation. Thus your editor began a search for tools which would
perform HDR processing under Linux. It turns out that there are a few such
tools around; there is no need to use proprietary software for this task.
HDR generation
The first step is to look for a way to represent HDR images - normal image
formats are not up to that task. Linux.com ran
a reasonable
article on HDR formats late last year; the end result appears to be
that the
OpenEXR format is the way to
go. The OpenEXR package comes with the libraries needed by other
applications and the deeply painful "exrdisplay" image viewer. The
pfstools package
adds a set of pipeline-oriented tools for working with HDR images; it is a
necessary part of any HDR hobbyist's toolkit.
Next, one should come up with a set of source images. Ideally, these images are
taken with a tripod-mounted camera and cover a range of at least two
f-stops above and below the nominally "correct" exposure. Varying the
exposure time is preferred over changing the aperture; if nothing else,
this ensures that all of the images will have the same depth of field. One
can start with images taken without a tripod, but it will be
necessary to register them before continuing. Your editor did not get into
that aspect of the task; tools like hugin and hdrprep
can be used for this job. These tools may be a good topic for your
editor's attention in a future article. One can also apply HDR techniques
to a single image, especially if it is in the camera's raw format, but
multiple exposures give much better results.
With the images in place, one can look at combining them into an HDR
image. This is a two-stage process (two user-visible stages, at least):
creating a set of response curves and using them to map the images together
into a single dynamic range space. The response curves are a mapping
between some sort of real-world light levels and the resulting sensor
values on all three color channels. When combined with information on the
relative exposure times of two (or more images), the response curves allow
the HDR program to map pixels from all of the images into the same space.
The response curves can be generated directly from the source images; they
don't normally change, so they can be saved and reused later.
![[Cinepaint windows]](/images/ns/grumpy/hdr/cinepaint-ui-sm.png)
The first HDR-generation tool to look at is cinepaint,
once known as "Film Gimp." This tool is a fork of the GIMP which is aimed
at use by movie studios; its floating-point image data support makes it useful for
HDR processing as well. The generation of HDR is done with the "bracketing
to HDR" plugin which is, happily, packaged with the cinepaint source
distribution. There is a
detailed explanation of what this plugin does and how to use it. Be
warned that it makes for somewhat difficult reading - and it would even if
it weren't originally written in German.
The good news is that actually using this plugin is easy. One selects
"bracketing for HDR" from the File->New from menu, then
selects the set of source images from a simple dialog. The plugin will
then import them. There is no provision for obtaining the relative
exposure information from the image files themselves; instead, the plugin
sorts the images by brightness and applies an assumed (adjustable) exposure
difference between them.
It attempts to feed each image to dcraw for decoding, but your
editor was not able to get raw images to work despite the fact that dcraw
supports his camera just fine; it looks like the raw import plugin was
written for an older version of dcraw. That problem is likely to be easily
overcome; your editor just didn't want to spend much time on it. So TIFF
files were used instead.
Once the images are in, the user can check the exposure values, then hit
the "compute response" button. That yields the two plots shown in the
screenshot. By messing around with the buttons, one can look for the
reference image which yields the smoothest set of response curves - or one
can just accept what the plugin does by default.
Then a click on the "generate HDR" button creates the final
product, which can then be saved out in the OpenEXR format.
Your editor set out to take some amazing pictures for this article. The
area in which your editor resides is widely held to be beautiful, but,
frankly, Colorado is not at its best in early March; perhaps this article
should have been written in June. Nonetheless, the effort
was made. Below is a rather mediocre shot of the Boulder foothills in
original and HDR (with cinepaint) forms (larger
versions available).
| Original | HDR |
|---|
![[Original]](/images/ns/grumpy/hdr/flagstaff-orig-sm.jpg) |
![[HDR]](/images/ns/grumpy/hdr/flagstaff-cp-sm.png) |
The HDR image above shows a halo effect (the bright sky above the mountain)
which is characteristic of some tone mapping algorithms; we'll get into
tone mapping shortly.
An alternative approach is PFScalibration,
a command-line HDR generation utility based on pfstools. These tools work
as a netpbm-like pipeline; their use requires a fair amount of typing,
though much of the work can be scripted. The steps are the following:
- Run jpeg2hdrgen to generate a description file for the source
images. It reads the EXIF information from the source files to get
the relative exposures and outputs it in a simple file. There is a
dcraw2hdrgen tool as well, but the subsequent stages in the
pipeline are not able to work with raw files. Your editor suspects
that TIFF files could be used by creating the hdrgen file by hand, but
the whole process seems to be intended for use with JPEG files. A
lossy file format is not the most auspicious starting point for
somebody interested in high dynamic range imagery, but that's how it
is.
- The pfshdrcalibrate utility can then be used to create a set
of response curves; gnuplot can be used to visualize them.
This process can take some time (it's significantly slower than
cinepaint), but the resulting file can be saved and reused with
different images in the future.
- Another pfshdrcalibrate run then uses the response curves to
create the HDR image. Piping the output into pfsoutexr
generates an OpenEXR file.
Here's an example generated from a series of pictures of your editor's
dungeon office (larger
versions):
| Original | HDR |
|---|
![[Original]](/images/ns/grumpy/hdr/office-orig-sm.jpg) |
![[HDR]](/images/ns/grumpy/hdr/office-pc-sm.png) |
As a general rule, HDR images generated with cinepaint and PFScalibration
tend to look identical. The generation of HDR is not where the real magic
lies, so the results should be close.
![[qtpfsgui]](/images/ns/grumpy/hdr/qtpfsgui-create-dialog-sm.png)
For those who don't like command-line HDR processing, the qtpfsgui utility may be worth a
look. It is a graphical wrapper around PFScalibration based on QT4; it
handles both HDR generation and tone mapping. On the HDR side, it puts up
a file selection dialog for the source images followed by the "HDR creation
wizard." The user is asked to select a "creation configuration," from a
list of configurations helpfully named "Configuration 1" through
"Configuration 6". The advice to stick with Configuration 1 was
hard for your editor to ignore; simply hitting "next" generated the image.
Said image appeared in a display window; like exrdisplay, this window can
only show the image in full resolution. Your editor, lacking a
7 megapixel monitor, was thus unable to view the entire image at
once. Even worse, qtpfsgui is one of the family of (generally KDE-based)
graphical tools which feels the need to implement its own window manager.
The display window lives within the larger qtpfsgui window; it cannot be
resized with the usual shortcut your editor is used to. In summary,
qtpfsgui gets the job done, but writing a simple script around
PFScalibration seems like an easier way to go.
Tone mapping
While the tools above will generate a fine HDR image, one problem remains:
the dynamic range in that HDR image far exceeds the range of your editor's
monitor (or printer). Turning that image into something which can be
displayed requires a step called tone mapping. This is
where the serious magic comes in: somehow the vast amount of information in
the HDR image must be scaled back in a way which does not compromise the
image quality that was the whole point of this exercise in the first place.
Several tone mapping algorithms exist, and most of them have a number of
mysterious knobs to tweak. While the generation of HDR can be mostly
automated, tone mapping inherently requires experimentation and human
judgment.
The bulk of the action appears to be in the pfstmo package, which
implements several tone mapping algorithms as separate, standalone
filters. One can use pfstmo with the rest of the pfstools package to
construct pipelines which generate tone-mapped images. Given the iterative
nature of the task, however, it would be nice if there were a better way.
![[qpfstmo]](/images/ns/grumpy/hdr/qpfstmo-sm.png)
That better way is qpfstmo,
a Qt-based graphical interface to pfstmo. The interface feels a little
clunky at times, and it would sure be nice to have some online
documentation on what the various parameters do, but qpfstmo does what is
really needed: it lets the user play with tone mapping algorithms and
compare the results. A small image size can be used for trying out
algorithms and parameters - a real time saver, since some of the algorithms
can take a long time on a full-size image - and multiple versions of the image can be on the
screen at once. When a final configuration is found for a given image, it
can be generated in a larger size and saved in any of the usual image
formats. When applied to a large image file, this step can be rather hard
on the hardware; your editor discovered that 1GB of memory was not really
enough.
![[qtpfsgui]](/images/ns/grumpy/hdr/qtpfsgui-sm.png)
The qtpfsgui tool mentioned above has the ability to drive pfstmo as well.
It is, in fact, clear that this tool shares a lot of code with pfstmo. The
interface is far less friendly, however: everything happens within the One
Big Window and it does not appear to be possible to see the results from
more than one algorithm at the same time. It resets the display image size
every time the user changes algorithm. One assumes that this (fairly new)
tool will improve over time. For now, though, qpfstmo seems like a much
better way to go for tone mapping control.
A different set of tone mapping operators is supplied with the exrtools distribution. Your editor
tried them all; each one is a cumbersome, multi-step process. It can take
a long time to process an image, only to find that the parameters need
quite a bit of tweaking. The tools seem like they will do quality
transformations, but they just cry out for a qpfstmo-like interface which
allows experimentation with smaller-size images and comparison of results.
For what it's worth, here's a shot taken from the hill above your editor's
house mapped with the exrtools non-linear masking method:
| Original | HDR |
|---|
![[Original]](/images/ns/grumpy/hdr/arapaho-orig-sm.jpg) |
![[HDR]](/images/ns/grumpy/hdr/arapaho-nlm-sm.png) |
See the larger versions for more detail.
Doubtless one could get good results from these tools with enough effort,
but your editor found it easier to get quality images with psftmo.
Conclusion
For the generation of HDR images, your editor found cinepaint to be faster
and simpler to work with. This does not count, however, the long and
frustrating experience of building the HDR plugin on a Fedora
Rawhide system; one gets the sense that the plugin's author uses a rather
older, less picky version of g++. Longer-term, however, the PFScalibration
suite may prove to be the way to go. It is far more compact and easy to
install on a new system; why lug the weight of cinepaint if one is not
going to use its other features? A bit of scripting will easily turn
PFScalibration into a single-command HDR generation tool.
It's worth noting that there are a couple of other HDR generators for Linux
out there. MakeHDR is
where a lot of it started; one of its authors is Paul Debevec, who did much
of the early research in this area. The code was last touched in 1999,
however, and it comes with a "educational purposes only" license. One can
also look at HDRgen, but it is a
binary-only, free-beer tool. Your editor did not actually try either one
of them; given that the free tools do the job so well, there didn't seem to
be any point.
For tone mapping, pfstmo (and qpfstmo) are the best tools at this point. It is
hard to be entirely satisfied with the state of the art in this area,
though. Tone mapping will always be an exercise in compromises, so it's
not surprising that the results are rarely perfect. There is likely to be
room for improvement - in both the algorithms and the interface to them -
for some time to come.
As is the case in many areas, Linux has the tools one needs to play with
high dynamic range imagery. One just has to work a little harder to get
started than on some other systems. HDR has found its way into your
editor's photographic toolkit; look for the results in the reporting from
some conference in some exotic part of the world. When playing with this
stuff, your editor is far from grumpy.
Comments (28 posted)
Java cryptography and free distributions
The problem first
came
up in February: the Red Hat Directory Server developers would like to
include the Java Security Services module in the Fedora distribution. The
code, it seems, is free, but there is still a problem: the Java virtual
machine requires that all Java Cryptography Extension providers (of which
JSS is one) to be signed with a Sun-approved key. If an application tries
to use a JCE module which lacks the requisite signature, the whole thing
comes crashing down - an experience which probably differs from what the
user had in mind. In practice, this limitation means that users either use
the signed version obtained from Sun, or do not use JSS at all.
Warren Togami recently posted a couple of
possibilities for how Fedora might be able to ship JSS. They were:
- The Fedora team builds the JSS module, then compares it to the
Sun-signed version. Assuming they match, Fedora has proved that it
can rebuild the software. So the project can declare Mission
Accomplished, dump the module it just built, and ship Sun's version.
A variation on this approach suggested later on involved having Red
Hat obtain an approved key and sign the modules that Fedora would
distribute; in this way, Fedora could add its own modifications.
- Fedora ships an unsigned version of JSS. Applications would then have
to be recoded to load the module in a way which shorts out the
signature check. Any applications not fixed up in this way would
fail.
The first option, at first blush, would appear to work. Fedora would be
able to build its own module and ship the source. It falls down, however,
as soon as a Fedora user tries to make a change; that user will not be able
to rebuild the patched module in a way that will actually work. Derivative
distributions would run into the same problem. As a result, it would
appear that Fedora stopped considering this option fairly quickly.
Not signing the module at all has obvious problems as well. It seems
likely that many potential JSS users have their own applications in mind.
If those applications do not work, they will rightly see Fedora as not
having support for the features they are looking for.
Other alternatives have been considered; one is to emphasize the use of the
GCJ compiler and try to steer users away from Sun's virtual machine. That
approach would certainly offer a higher degree of freedom, at the cost of
not really providing what many Java users appear to want. Additionally,
not everybody is convinced that GCJ has achieved the level of maturity that
many users would expect.
In an interesting way, this is really just the Tivo problem under a
different guise. Locked-down hardware refuses to run software which lacks
the expected signatures. In this case, we have virtual hardware, in the
form of the Java virtual machine, which is doing the same thing. The
result is the same as well: the software is available and nominally free,
but the users of that software cannot create their own versions and expect
to be able to run them.
If Sun follows through on its desire to move to GPLv3, and if that license
retains its requirement that any needed signing keys be distributed with
the source, Sun may find itself in an interesting position. It is hard to
see how the current policy would be compliant with the new GPL's
requirements.
The upcoming GPL Java release would appear to be the best hope for
distributors trying to deal with this situation. Once the code is free,
distributors can patch it to make the whole of Java distributable as free
software. So the real solution to shipping JSS with a distribution which
insists on freedom would appear to be to wait for a free Java.
Comments (9 posted)
Page editor: Jonathan Corbet
Security
Intrusion detection for the browser
March 14, 2007
This article was contributed by Jake Edge.
Websites with malicious content are a growing problem,
so tools to detect this content and alert the user to its presence
are quite welcome. A plugin for Firefox called
Firekeeper uses the ideas behind
intrusion
detection systems (IDS) and applies them to web traffic. Firekeeper
uses some of the rule syntax and pattern matching code from
Snort, the venerable open source IDS,
providing it with a solid foundation.
As with any IDS, the basic function of Firekeeper is to inspect the traffic
that it sees, applying some pattern matching smarts and a set of rules to
determine what actions it takes. The possible actions are to alert the
user and allow them to decide what to do, stop processing the HTTP response
without user interaction or to accept and continue processing, also without
consulting the user. Alert rules can also provide extra information
![[Firekeeper alert]](/images/ns/firekeeper-sm.png)
that will be displayed with the alert in order to help the user make an
informed decision about what action to take. This information can
take the form of text strings to describe the content as well as references
to URLs, CVE entries and Bugtraq IDs potentially giving the user a wealth
of descriptive information.
Firekeeper can do pattern matching on three different parts of the HTTP or
HTTPS response: the URL, headers and body. The simplest form matches literal
strings in the various pieces of the response, but there is also a
Perl compatible regular expression (regexp) engine that can be applied to
each piece as well. The documentation warns of serious performance
implications from having too many regexps, especially ones that do not
contain a literal rule to narrow the search space; good advice for
most applications that use regexps.
Firekeeper can be downloaded from the project site and it installs flawlessly
if one is willing to add the site (hosted at mozdev.org) to the list
of trusted plugin locations and ignore the unsigned nature of the code.
The source is available from the site as well so those with concerns about
the security bypasses can build their own version. It comes with a handful
of default rules
and a test page to
try them out as well. Visiting various sites with Firekeeper enabled while
working on this article did not noticeably slow down the browser for the
author and, other than the tests, did not trigger any rules.
Any IDS is an invasive program and has access to all sorts of information
one probably wants to keep private, particularly decrypted network data.
This makes IDS programs high profile targets for exploitation. If an
attacker can send a packet or series of packets that can subvert the IDS,
they can potentially eavesdrop on all network traffic, even encrypted
traffic. Because Firekeeper has access to the decrypted HTTPS traffic,
there is reason to be concerned that the plugin could be subverted via
the same kinds of remotely exploitable vulnerabilities that have impacted
Snort, a recent example is
here.
Firekeeper implements a small subset of the Snort functionality, which should
make it less likely, but users of the plugin should be aware of the
possibility.
An IDS is only as good as the rules that it uses, and newer exploits (and
so-called 0-days)
will not yet have rules available, leaving a window of vulnerability.
Firekeeper does have provisions for loading rule files from external sites
(which, of course, has its own set of security issues) that would help
propagate new rules quickly, at least for users who restart their browser
frequently.
Firekeeper is certainly not for less technical users and probably never will
be. There is too much knowledge and understanding of web protocols and
security threats required to understand the alerts and too many false
positives to turn the alerts into blocks. And like many security tools
and techniques, this is no panacea; it will not stop all browser-targeted
attacks, but it does have its uses. An alert that a site has tried to
exploit a browser bug, even one that does not affect the browser version
being used, is still useful information which can help users to avoid dodgy sites.
Comments (1 posted)
Security news
A second remote hole for OpenBSD
Visitors to the
OpenBSD site will notice
that it now reads "Only two remote holes in the default install, in more
than 10 years!" That's one more than it had a little while ago. The
details can be found in
this Core Security
advisory: it seems that the problem was in the IPv6 code. It's amusing
to read the timeline - the OpenBSD folks were apparently not enthusiastic
about accepting the existence of a remotely exploitable vulnerability.
They did accept it, though, and their record over many years remains
impressive.
Comments (28 posted)
New vulnerabilities
amarok: remote code injection
| Package(s): | amarok |
CVE #(s): | |
| Created: | March 14, 2007 |
Updated: | March 14, 2007 |
| Description: |
Amarok's Magnatune component suffers from a shell code injection vulnerability exploitable by a hostile remote server. |
| Alerts: |
|
Comments (none 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)
ktorrent: incorrect validation
| Package(s): | ktorrent |
CVE #(s): | CVE-2007-1384
CVE-2007-1385
CVE-2007-1799
|
| Created: | March 13, 2007 |
Updated: | October 24, 2007 |
| Description: |
Bryan Burns of Juniper Networks discovered that KTorrent did not
correctly validate the destination file paths nor the HAVE statements
sent by torrent peers. A malicious remote peer could send specially
crafted messages to overwrite files or execute arbitrary code with user
privileges. |
| Alerts: |
|
Comments (1 posted)
mplayer: buffer overflow
| Package(s): | mplayer |
CVE #(s): | CVE-2007-1246
|
| Created: | March 8, 2007 |
Updated: | April 1, 2008 |
| Description: |
MPlayer versions up to 1.0rc1 have a buffer overflow in the
loader/dmo/DMO_VideoDecoder.c DMO_VideoDecoder_Open function.
user-assisted remote attackers can use this to create a buffer overflow
and possibly execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
silc-server: denial of service
| Package(s): | silc-server |
CVE #(s): | |
| Created: | March 14, 2007 |
Updated: | March 14, 2007 |
| Description: |
silc-server, a Secure Internet Live Conferencing protocol implementation, has a NULL pointer dereference which can be exploited to crash the server. |
| Alerts: |
|
Comments (none posted)
xen, qemu: information disclosure
| Package(s): | Xen |
CVE #(s): | CVE-2007-0998
|
| Created: | March 14, 2007 |
Updated: | March 20, 2007 |
| Description: |
From the Red Hat advisory: a flaw was found affecting the VNC server code in QEMU. On a
fully virtualized guest VM, where qemu monitor mode is enabled, a user who
had access to the VNC server could gain the ability to read arbitrary files
as root in the host filesystem. |
| Alerts: |
|
Comments (none posted)
xine-lib: arbitrary code execution
| Package(s): | xine-lib |
CVE #(s): | CVE-2007-1387
|
| Created: | March 13, 2007 |
Updated: | April 1, 2008 |
| Description: |
Moritz Jodeit discovered that the DirectShow loader of Xine did not
correctly validate the size of an allocated buffer. By tricking a user
into opening a specially crafted media file, an attacker could execute
arbitrary code with the user's privileges. |
| 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)
bind: denial of service
| Package(s): | bind |
CVE #(s): | CVE-2007-0493
CVE-2007-0494
|
| Created: | January 26, 2007 |
Updated: | March 14, 2007 |
| Description: |
The bind package is vulnerable to two remote denial of service attacks in
which attackers can cause the bind daemon to to crash or exit unexpectedly
by providing malformed data to the daemon in a DNS request. |
| Alerts: |
|
Comments (none posted)
bluez-utils: hidd vulnerability
| Package(s): | bluez-utils |
CVE #(s): | CVE-2006-6899
|
| Created: | January 16, 2007 |
Updated: | May 14, 2007 |
| Description: |
hidd in BlueZ (bluez-utils) before 2.25 allows remote attackers to obtain
control of the Mouse and Keyboard Human Interface Device (HID) via a
certain configuration of two HID (PSM) endpoints, operating as a server,
aka HidAttack. |
| Alerts: |
|
Comments (none posted)
bugzilla: multiple vulnerabilities
| Package(s): | bugzilla |
CVE #(s): | CVE-2006-5453
CVE-2006-5454
CVE-2006-5455
|
| Created: | November 10, 2006 |
Updated: | August 28, 2007 |
| Description: |
Bugzilla has the following vulnerabilities:
Input data passed to various fields is not properly sanitized before
being passed back to users.
Users can gain unauthorized access to read attachment
descriptions while using diff mode.
HTTP GET and HTTP POST requests can be used to perform unauthorized
actions due to improper verification.
Input that is passed to showdependencygraph.cgi is not properly
sanitized before being returned to users. |
| Alerts: |
|
Comments (none posted)
busybox: insecure password generation
| Package(s): | busybox |
CVE #(s): | CVE-2006-1058
|
| Created: | May 5, 2006 |
Updated: | May 2, 2007 |
| Description: |
The BusyBox 1.1.1 passwd command does not use a proper salt when generating
passwords. This would create an instance where a brute force attack could
take very little time. |
| Alerts: |
|
Comments (2 posted)
clamav: directory traversal, denial of service
| Package(s): | clamav |
CVE #(s): | CVE-2007-0897
CVE-2007-0898
|
| Created: | February 20, 2007 |
Updated: | March 7, 2007 |
| Description: |
Clam AntiVirus ClamAV before 0.90 does not close open file descriptors
under certain conditions, which allows remote attackers to cause a denial
of service (file descriptor consumption and failed scans) via CAB archives
with a cabinet header record length of zero, which causes a function to
return without closing a file descriptor. (CVE-2007-0897)
Directory traversal vulnerability in clamd in Clam AntiVirus ClamAV before
0.90 allows remote attackers to overwrite arbitrary files via a .. (dot
dot) in the id MIME header parameter in a multi-part
message. (CVE-2007-0898) |
| Alerts: |
|
Comments (none posted)
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)
fetchmail: password disclosure and DOS
| Package(s): | fetchmail |
CVE #(s): | CVE-2006-5867
CVE-2006-5974
|
| Created: | January 9, 2007 |
Updated: | March 16, 2007 |
| Description: |
Fetchmail suffers from a password disclosure vulnerability due to a failure to use secure protocols (advisory) and a denial of service vulnerability (advisory). |
| Alerts: |
|
Comments (none posted)
ffmpeg: buffer overflows
| Package(s): | ffmpeg |
CVE #(s): | CVE-2006-4799
CVE-2006-4800
|
| Created: | September 14, 2006 |
Updated: | May 28, 2007 |
| Description: |
the AVI processing code in FFmpeg has a number of buffer overflow
vulnerabilities.
If an attacker can trick a user into loading a specially crafted
crafted AVI, arbitrary code can be executed with the user's privileges. |
| Alerts: |
|
Comments (2 posted)
Mozilla stuff: multiple vulnerabilities
Comments (none posted)
freeradius: several vulnerabilities
| Package(s): | freeradius |
CVE #(s): | CVE-2005-4745
CVE-2005-4746
|
| Created: | August 8, 2006 |
Updated: | April 24, 2007 |
| Description: |
Several remote vulnerabilities have been discovered in freeradius, a
high-performance RADIUS server, which may lead to SQL injection or denial
of service. |
| Alerts: |
|
Comments (none posted)
freetype: integer overflows
| Package(s): | freetype |
CVE #(s): | CVE-2006-0747
CVE-2006-1861
CVE-2006-2493
CVE-2006-2661
CVE-2006-3467
|
| Created: | June 8, 2006 |
Updated: | October 10, 2007 |
| Description: |
The FreeType library has several integer overflow vulnerabilities.
If a user can be tricked into installing a specially
crafted font file, arbitrary code can be executed with the privilege
of the user. |
| Alerts: |
|
Comments (none posted)
gcc: file overwrite vulnerability
| Package(s): | gcc |
CVE #(s): | CVE-2006-3619
|
| Created: | September 6, 2006 |
Updated: | March 14, 2008 |
| Description: |
The fastjar utility found in the GNU compiler collection does not perform adequate file path checking, allowing the creation or overwriting of files outside of the current directory tree. |
| Alerts: |
|
Comments (none posted)
gd: buffer overflow
| Package(s): | gd |
CVE #(s): | CVE-2007-0455
|
| Created: | February 7, 2007 |
Updated: | February 28, 2008 |
| Description: |
The gd graphics library contains a buffer overflow which could enable a remote attacker to execute arbitrary code. Note that various other packages include code from gd and could also be vulnerable. |
| Alerts: |
|
Comments (2 posted)
gdb: buffer overflow
| Package(s): | gdb |
CVE #(s): | CVE-2006-4146
|
| Created: | September 15, 2006 |
Updated: | June 12, 2007 |
| Description: |
A buffer overflow in dwarfread.c and dwarf2read.c debugging code in GNU
Debugger (GDB) 6.5 allows user-assisted attackers, or restricted users, to
execute arbitrary code via a crafted file with a location block
(DW_FORM_block) that contains a large number of operations. |
| Alerts: |
|
Comments (none posted)
gdm: improper file permissions
| Package(s): | gdm |
CVE #(s): | CVE-2006-1057
|
| Created: | April 19, 2006 |
Updated: | May 2, 2007 |
| Description: |
The .ICEauthority file may be created with the wrong ownership and permissions; gdm 2.14.2 fixes the problem. |
| Alerts: |
|
Comments (none posted)
gnupg: stack overwrite
| Package(s): | gnupg |
CVE #(s): | CVE-2006-6235
|
| Created: | December 12, 2006 |
Updated: | March 13, 2007 |
| Description: |
A "stack overwrite" vulnerability in GnuPG (gpg) allows attackers to
execute arbitrary code via crafted OpenPGP packets that cause GnuPG to
dereference a function pointer from deallocated stack memory. |
| Alerts: |
|
Comments (3 posted)
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)
ImageMagick: buffer overflows
| Package(s): | ImageMagick |
CVE #(s): | CVE-2006-5456
|
| Created: | October 31, 2006 |
Updated: | March 8, 2007 |
| Description: |
Multiple buffer overflows in GraphicsMagick before 1.1.7 and ImageMagick
6.0.7 allow user-assisted attackers to cause a denial of service and
possibly execute execute arbitrary code via (1) a DCM image that is not
properly handled by the ReadDCMImage function in coders/dcm.c, or (2) a
PALM image that is not properly handled by the ReadPALMImage function in
coders/palm.c. |
| Alerts: |
|
Comments (2 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)
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: 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: 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: |
|
