The Grumpy Editor plugs in his camera
Your editor has finally acted to bring an end to an annual embarrassment.
Each year, at the Kernel Summit, the entire group is brought together for a
photograph. Most digital cameras can do a reasonable job of taking a
portrait, but getting a reasonable image of some 70 people all together is
another story. Your editor, possessing a camera of the "other story"
variety, has been forced to post grainy, second-rate pictures of a
first-rate crowd, only to be upstaged by attendees with far superior
equipment. To be absolutely sure that he will not be shamed this year,
your editor went and picked up a shiny new Sony DSC-V3
camera. If his writing in LWN has seemed distracted recently, blame the
new toy.
In the classic days of Linux, one would expect to spend a full, painful day
making a new device work with Linux. In this century, however, people have
this irrational expectation that their hardware will "just work." Linux
has gotten good at living up to that expectation in a number of ways; see
the advances in printer configuration, for example. Your editor set out to
determine if support for digital cameras has made the same sort of
progress.
It turns out that there are very few free applications which are aimed
specifically at interfacing with digital cameras. And the big ones,
reviewed below, are all based on the libgphoto2 library. So
this review did not take as long as some of the others in this series.
gtkam
![[gtkam screenshot]](/images/ns/grumpy/gtkam-sm.png)
Gtkam is "the official GTK2
GUI" for libgphoto2. On many distributions, it is the default digital
camera interface application. Your editor tried version 0.1.12 on Fedora
and Ubuntu systems.
The initial gtkam window is mostly blank. The "camera" item on the tool
bar leads to the obvious "add camera" dialog, which, in turn, contains a
pulldown menu for
the camera model. In theory, the user need only select the right model
![[The gtkam camera dialog]](/images/ns/grumpy/gtkam-camera-sm.png)
from this list, and all will be well. Unfortunately, this menu contains
over 500 entries, making the camera selection process unwieldy at best.
Even more unfortunately, your editor's camera - on the market since June of
last year - was not on the list. Obviously, your editor should have
checked first and bought a supported camera; somehow, however, the idea of
showing up at the Kernel Summit with a Barbie camera lacks appeal.
There is also a "detect" button next to the model pulldown; it failed to
find your editor's camera, however.
Now, the DSC-v3 has two ways of dealing with the USB bus. In its default
configuration, the camera appears to be a USB mass storage device. The
camera can also be instructed to use the "picture transport protocol" (PTP)
mode, which is an older, specialized way of talking to cameras. When your
editor put the camera into the PTP mode, and after tweaking some
permissions under /proc/bus/usb, gtkam was able to detect it - as
a Sony DSC-F707V. The model was wrong, but everything worked.
When it is talking to a camera it knows about, gtkam presents a simple
browsing interface. The left pane is the directory hierarchy as exported
by the camera, while the right shows thumbnails of any images stored in the
currently-selected directory. Many of the obvious things are not possible;
you cannot ask gtkam to display a full-resolution image, for example, and
it will not let you drag images into file browsers or other applications.
There are, in fact, exactly two things you can do: download images, and
delete them.
The download window is somewhat awkward to work with, mostly because it
seems to want to provide for several possible actions. It can save the
pictures themselves, or just the thumbnails or metadata. It can feed the
images to an external application. Or it can rename the pictures, adding
an incrementing number to a user-supplied base filename. Once you get the
hang of the window, things work reasonably well, but it can take a couple
of tries at the outset.
digikam
![[Digikam screenshot]](/images/ns/grumpy/digikam-sm.png)
The KDE digital camera application is digikam.
Your editor used version 0.7; that version is a bit old (there is a 0.7.2 beta out), but attempts to build
something more recent were a dismal failure. Digikam, it turns out, is not
a straightforward application to build.
The initial digikam window resembles gtkam's, in that there is not much to
be seen. The "Camera" toolbar item has an "add camera" option, which is a
nice enhancement over previous versions of digikam, which required the user
to wander into the "configure digikam" dialogs.
The camera dialog looks very much like gtkam's, and it
behaves in a very similar way. Since the same library is doing the work
underneath it all, this resemblance is not entirely coincidental. There is
one interesting addition to the digikam dialog, however: the user who
remains awake after having scrolled through some 500 possibilities will see
"USB mass storage" as a camera type. The user must provide the directory
where the camera will be mounted - and arrange for it to be actually
mounted there. With that work done, however, digicam was able to talk to
your editor's camera in its native mode. The PTP mode also works, as it
did with gtkam.
Actually, the PTP mode almost works. It will happily detect the camera
(once again calling it a DSC-F707V) and work with it - for one session.
Once the camera has been disconnected and plugged back in, however, digikam
is unable to work with it. Removing the camera from the configuration and
asking digikam to detect it from the beginning worked. It would seem that
the camera pops up with a different address under /proc/bus/usb
each time; gtkam is able to handle that change, but digikam is not.
Digikam provides the same basic operations as gtkam: download images from
the camera, and delete images from the camera. There is much more to
digikam than that, however: while gtkam forgets about images once they have
been extracted from the camera, digikam is a full image management and
manipulation framework. It implements albums, performs simple image
editing, and provides a large set of gimp-style plugins (which seem to be
mostly front ends to tools from the ImageMagick package).
gthumb
Your editor reviewed
gthumb
almost one year ago in
this article on image
viewers and editors. This application is not often presented as being
![[The gthumb import dialog]](/images/ns/grumpy/gthumb-import-sm.png)
a tool for working with digital cameras, but the attentive user will notice
an "import images" item on gthumb's "file" menu. Selecting that option
yields the dia digital camera
interface.
It is, perhaps, the best of them all. There is no need to tell gthumb to
configure a camera; it simply goes out and talks to whatever it finds.
It found your editor's new camera without trouble (in PTP mode only), but
had to be instructed
on where to look for the old one, which is of the painful serial port
variety. The dialog has a blank marked "film," which would appear to be
the name of a subdirectory to create for the images.
Once that has been
figured out, it is simply a matter of deciding where the images should go,
whether they should be deleted from the camera, and hitting the "import"
button.
Summary
So which is the preferred interface for a grumpy editor? Of the three
programs discussed above, gthumb has the most straightforward interface,
with a minimum of bureaucracy required before work can be done. That would
be your editor's pick.
The truth of the matter is this, however: your editor thinks the best
approach is to get a modern camera which implements the USB mass storage
protocol. Then you can simply mount the camera as a disk, move the image
files across, and be done with it. It's fast, easy, and for those who
prefer not to use the mv command, setting up hotplug scripts to
launch a file manager is relatively straightforward. There should be no
need for separate, specialized applications to interface with a digital
camera.
On the other hand, the management of images once they have been
pried from a camera's clutches is an interesting problem. Tools like
digikam and gthumb have been written with that task in mind; there are
several others out there as well. And that is likely to be your editor's
next (and rather more ambitious) exercise: a review of image management
tools. Stay tuned.
Comments (44 posted)
OSDL's desktop specificaton
The Open Source Development Labs has, just in time for LinuxWorld,
announced the availability of the "Desktop Linux
Capabilities" specification. This document is available
in
PDF format.
One of OSDL's most controversial functions is the creation of
specifications for Linux in particular environments. The Carrier Grade
Linux and Data Center Linux documents might indeed be an accurate
reflection of the features desired by commercial interests in those
sectors. But those documents also appear, to the developers who actually
create Linux, as an attempt to tell them what they should be working on.
In that regard, the introduction from the desktop Linux document is likely
to rub some developers the wrong way:
An important decision taken by the OSDL Desktop Linux Working Group is
that the Linux operating system will be developed independently. We
will not attempt to emulate other existing desktop systems. We feel
that the system should interoperate with existing systems, but we do
not strive for complete compatibility.
The people at OSDL know quite well that any attempt to "decide" that
desktop Linux would not be developed independently would fail. They
do not yet seem to know how to keep that sort of language out of their
documents, however.
The introduction continues:
Variety and choice, two of Linux's greatest strengths, are also its
Achilles heel. ISVs and large corporations do not have the resources
(or ability, in some cases) to ensure all applications work in all
current graphical environments and windowing managers available in
each distribution.
OSDL goes on from there that there should be a single desktop Linux
standard. Furthermore, this standard must be chosen from one of the
existing desktop environments; any attempt to combine them was regarded as
not feasible. The authors are clearly not complete masochists, however:
they stopped short of saying which environment they think should be chosen,
or even naming a subset from which the choice should be made.
The document identifies four types of desktop deployment, ranging from
"fixed function" (locked-down kiosks of one form or another) through to
"technical workstation" and "basic office". The existence of a "general
purpose" usage category is recognized, but not really addressed in the
document.
The bulk of the document follows: it is a tiresome series of tables
describing the capabilities the authors think desktop Linux should have.
Many of them are obvious, and already present: x86 processor support, USB
support, IPv4, and so on. Some will be controversial: DVD playback support
(which "will require licenses") and implementation of digital restrictions
management schemes. Some make sense, and are in the works: persistent
device naming, good IPSec support, etc. And some things are strange in
their absence: instant messaging, Microsoft document format support,
electronic mail, internationalization, and so on.
And a few things are bizarre. It would appear that all desktop users, even
those with "fixed function" systems, have an urgent need for a Linux
installer which uses their preferred desktop environment. Installations
must be checkpointed so that they can be restarted in the middle. Desktop
users should, it is said, be able to do things like update their kernel
without needing root access to the machine. Numerous pages are devoted to
various aspects of the installation process - despite the fact that, in a
world of widespread Linux desktop deployments - most desktop users should
never do their own installations.
If Linux is to achieve desktop World Domination, quite a bit of work will
have to be done. Even the most ardent desktop Linux supporter will not (or
should not) say that all of the necessary pieces are in place now. When
OSDL set out to create its desktop capabilities document, it had an
opportunity to identify the missing pieces, the features which, were they
present, would make Linux more attractive in more desktop situations. That
opportunity was lost in what must have been a series of tiresome meetings
creating checklists of features Linux has had for years. Meanwhile the
development community continues to improve Linux (for all environments) at
a staggering rate - no specification required.
Comments (9 posted)
A look at CentOS
The
CentOS
(Community ENTerprise Operating System)
project has been thrust into the spotlight recently as a result of
contact from Red Hat's lawyers regarding the use of trademarks. In reality, that's something of a non-story, since Red Hat is only asking the project to comply with Red Hat's
trademark guidelines. Red Hat has
enforced its trademarks before without destroying the GPL or stopping the distribution of Red Hat derivatives.
The CentOS team makes it very clear that the trademark issue is not a major obstacle, and is no threat to the future development of CentOS. But the brief flurry of press did bring our attention to the cAos (community assembled operating systems) Foundation and its CentOS and cAos Linux distributions. This writer has run into several admins who've chosen to go with CentOS as an alternative to Red Hat Enterprise Linux.
The CentOS distribution is compiled from source packages from "a Prominent North American Enterprise Linux Vendor." CentOS-3 is built from Red Hat Enterprise Linux (RHEL) 3 sources, and CentOS-2 is built from RHEL 2. The project is working on CentOS 4 as well, but it is still in beta at the moment.
Installing and using CentOS is much (almost exactly) like using RHEL. There are some cosmetic differences, the CentOS logo and name replaces Red Hat's in most places -- though Red Hat is still given due credit in copyrights and so on -- and some changes in non-free packages. For the most part, though, CentOS seems to be an acceptable drop-in replacement for RHEL.
We also tested installing binary packages compiled for RHEL 3 on CentOS 3. We didn't run into any issues with packages compiled for RHEL 3 on CentOS 3 -- so CentOS seems to be suitable for users and organizations that want to use commercial products that support RHEL 3.
Support for CentOS is offered through forums, mailing lists, IRC channels and commercial organizations. We didn't approach any of the commercial organizations, but the CentOS community seems to be very helpful and responsive. The mailing lists, in particular, are fairly active. The February archive for CentOS 3 has 318 messages already, though some of the traffic is directly tied to the trademark issue.
Updates for CentOS are available via Yum repositories, which is a suitable replacement for the Red Hat Network as far as this writer is concerned. We did a little checking to see if the packages available from CentOS were up to date. After running "yum update" on CentOS 3 to get the latest packages, we checked against the Red Hat FTP repository for updates to RHEL 3. In each instance, we found that the CentOS packages were current, or at least as current as the packages on Red Hat's site.
The cAos Foundation is also distributing cAos Linux, not based on Red Hat's sources. The cAos Linux distribution is also RPM-based, but features its own Cinch installer, and a different design philosophy than CentOS. We did not spend much time with this distribution, but it does look like an interesting project for users who are looking for a community-driven RPM distribution with a long shelf-life. (The cAos page promises a 3-5 year life cycle, which is a bit more attractive for many users than the rapid development cycle for Fedora Core.)
Red Hat may have been better off leaving the trademark issue alone, since it seems that the project has garnered some attention it might not have received otherwise. After spending some time with CentOS, this writer sees little difference between Red Hat's official offerings and the CentOS offerings that are community-supported. Official support directly from Red Hat may be necessary for some organizations, but if that's not a requirement, the CentOS distribution may be a better choice.
Comments (11 posted)
Page editor: Jonathan Corbet
Security
Mailman and safe input validation
Members of the Full Disclosure mailing list recently
got
a little more disclosure than they had been looking for. It
turns out that a bug in the
mailman list manager enabled a
suitably clever attacker to pull arbitrary files from the server. In
particular, the list of mailman accounts and passwords was taken from the
Full Disclosure server. Since people tend to use username and password
combinations in more than one place, it is entirely possible that the
information obtained could be used to attack user accounts elsewhere.
The bug was in this bit of code:
def true_path(path):
"Ensure that the path is safe by removing .."
path = path.replace('../', '')
path = path.replace('./', '')
return path[1:]
At first glance, it would appear that the above checks would remove any
directory traversal attempts. If, however, the URL contains a string like
".../....///", the string replacements performed will leave a
simple "../" in the path.
In retrospect, there is an obvious error here. The checks in the function
above perform some transformations to the input string, but never actually
verify that the resulting string does not violate the constraints they are
supposed to be enforcing. Such
code will likely always be exploitable in one way or another. The
short-term fix changes the above logic by splitting the path into
components and dealing with each component separately.
The bigger error, however, and one which is not addressed by the short-term
fix, is to allow the request to proceed at all if undesirable elements are
found. Assuming the code is reasonably well done, it should not generate
URLs which later need to be fixed up by the input validation routines. So
if something comes through which looks like a directory traversal attempt,
the more prudent action would be to reject the request outright. Hostile
input suggests hostile intent; it should be responded to accordingly.
Comments (11 posted)
Security reports
Mozilla Foundation Response to IDN Homograph Spoofing Attack (MozillaZine)
The Mozilla Foundation has
issued a
short-term response to Mozilla's vulnerability to a homograph spoofing
attack using international domain names (IDNs). "
In the forthcoming
Mozilla Firefox 1.0.1 and Mozilla 1.8 Beta releases, IDN support will be
disabled (bug 282270). For those users that need it, an XPI will be
released to turn IDN support back on (bug 282269)." Gervase Markham
has also provided some clarification and possible long-term solutions on
his
web
log.
Comments (1 posted)
New vulnerabilities
alsa-lib: disabled stack execution protection
| Package(s): | alsa-lib |
CVE #(s): | CAN-2005-0087
|
| Created: | February 15, 2005 |
Updated: | February 16, 2005 |
| Description: |
A flaw in the alsa mixer code was discovered that caused stack execution
protection to be disabled for the libasound.so library. The effect of this
flaw is that stack execution protection, through NX or Exec-Shield, would
be disabled for any application linked to libasound. |
| Alerts: |
|
Comments (none posted)
htdig: cross site scripting
| Package(s): | htdig |
CVE #(s): | CAN-2005-0085
|
| Created: | February 14, 2005 |
Updated: | January 10, 2006 |
| Description: |
Michael Krax discovered that ht://Dig fails to validate the 'config'
parameter before displaying an error message containing the parameter.
This flaw could allow an attacker to conduct cross-site scripting
attacks. |
| Alerts: |
|
Comments (none posted)
hztty: local utmp exploit
| Package(s): | hztty |
CVE #(s): | CAN-2005-0019
|
| Created: | February 10, 2005 |
Updated: | February 14, 2005 |
| Description: |
hztty has a vulnerability in which local users can
execute arbitrary commands with group utmp privileges. |
| Alerts: |
|
Comments (none posted)
lighttpd: script source disclosure
| Package(s): | lighttpd |
CVE #(s): | |
| Created: | February 15, 2005 |
Updated: | February 16, 2005 |
| Description: |
lighttpd uses file extensions to determine which elements are programs
that should be executed and which are static pages that should be sent
as-is. By appending %00 to the filename, you can evade the extension
detection mechanism while still accessing the file. A remote attacker
could send specific queries and access the source of scripts that should
have been executed as CGI or FastCGI applications. |
| Alerts: |
|
Comments (none posted)
linux-source-2.6.8.1: multiple vulnerabilities
| Package(s): | linux-source-2.6.8.1 |
CVE #(s): | CAN-2005-0176
CAN-2005-0177
CAN-2005-0178
|
| Created: | February 15, 2005 |
Updated: | March 15, 2005 |
| Description: |
Michael Kerrisk noticed an insufficient permission checking in the shmctl()
function. Any process was permitted to lock/unlock any System V shared
memory segment that fell within the the RLIMIT_MEMLOCK limit (that is the
maximum size of shared memory that unprivileged users can acquire). This
allowed am unprivileged user process to unlock locked memory of other
processes, thereby allowing them to be swapped out. Usually locked shared
memory is used to store passphrases and other sensitive content which must
not be written to the swap space (where it could be read out even after a
reboot). (CAN-2005-0176)
OGAWA Hirofumi noticed that the table sizes in nls_ascii.c were incorrectly
set to 128 instead of 256. This caused a buffer overflow in some cases
which could be exploited to crash the kernel. (CAN-2005-177)
A race condition was found in the terminal handling of the "setsid()" function, which is used to start new process sessions. (CAN-2005-178)
|
| Alerts: |
|
Comments (none posted)
mod_python: remote access vulnerability
| Package(s): | mod_python |
CVE #(s): | CAN-2005-0088
|
| Created: | February 10, 2005 |
Updated: | April 9, 2006 |
| Description: |
mod_python has a vulnerability in the publisher handler that may allow
a remote user to use a specially crafted URL to allow access to
objects that should be protected. An information leak can result. |
| Alerts: |
|
Comments (none posted)
netkit-rwho: missing input validation
| Package(s): | netkit-rwho |
CVE #(s): | CAN-2004-1180
|
| Created: | February 11, 2005 |
Updated: | February 17, 2005 |
| Description: |
"Vlad902" discovered a vulnerability in the rwhod program that can be
used to crash the listening process. The broadcasting one is
unaffected. This vulnerability only affects little endian
architectures (i.e. on Debian: alpha, arm, alpha, ia64, i386, mipsel
and s390). |
| Alerts: |
|
Comments (none posted)
postgresql: EXECUTE privilege vulnerability
| Package(s): | postgresql |
CVE #(s): | CAN-2005-0244
CAN-2005-0245
CAN-2005-0246
CAN-2005-0247
|
| Created: | February 10, 2005 |
Updated: | July 19, 2005 |
| Description: |
postgresql has a vulnerability in which the EXECUTE privilege may
not be checked on custom functions. This may allow any database user to
circumvent the EXECUTE restriction on functions. |
| Alerts: |
|
Comments (none posted)
PowerDNS: denial of service
| Package(s): | pdns |
CVE #(s): | |
| Created: | February 14, 2005 |
Updated: | February 14, 2005 |
| Description: |
A vulnerability has been reported in the DNSPacket::expand method of
dnspacket.cc. An attacker could cause a temporary Denial of Service by
sending a random stream of bytes to the PowerDNS Daemon. |
| Alerts: |
|
Comments (none posted)
sympa: arbitrary code execution
| Package(s): | sympa |
CVE #(s): | CAN-2005-0073
|
| Created: | February 11, 2005 |
Updated: | February 14, 2005 |
| Description: |
Erik Sjölund discovered that a support script of sympa, a mailing list
manager, is running setuid sympa and vulnerable to a buffer overflow.
This could potentially lead to the execution of arbitrary code under
the sympa user id. |
| Alerts: |
|
Comments (none posted)
synaesthesia: privilege escalation
| Package(s): | synaesthesia |
CVE #(s): | CAN-2005-0070
|
| Created: | February 14, 2005 |
Updated: | February 14, 2005 |
| Description: |
Erik Sjölund and Devin Carraway discovered that synaesthesia, a
program for representing sounds visually, accesses user-controlled
configuration and mixer files with elevated privileges. Thus, it is
possible to read arbitrary files. |
| Alerts: |
|
Comments (none posted)
thunderbird: cookie handling bug
| Package(s): | thunderbird |
CVE #(s): | CAN-2005-0149
|
| Created: | February 15, 2005 |
Updated: | February 16, 2005 |
| Description: |
A bug was found in the way Thunderbird handled cookies when loading content
over HTTP regardless of the user's preference. It is possible that a
particular user could be tracked through the use of malicious mail messages
which load content over HTTP. |
| Alerts: |
|
Comments (none posted)
toolchain-source: insecure temporary files
| Package(s): | toolchain-source |
CVE #(s): | CAN-2005-0159
|
| Created: | February 14, 2005 |
Updated: | February 14, 2005 |
| Description: |
Sean Finney discovered several insecure temporary file uses in
toolchain-source, the GNU binutils and GCC source code and scripts. These
bugs can lead a local attacker with minimal knowledge to trick the admin
into overwriting arbitrary files via a symlink attack. The problems exist
inside the Debian-specific tpkg-* scripts. |
| Alerts: |
|
Comments (none posted)
vmware: untrusted library search path
| Package(s): | vmware |
CVE #(s): | |
| Created: | February 14, 2005 |
Updated: | February 16, 2005 |
| Description: |
VMware may load shared libraries from an untrusted, world-writable
directory, resulting in the execution of arbitrary code. |
| Alerts: |
|
Comments (none posted)
Webmin: Information leak in Gentoo binary package
| Package(s): | webmin |
CVE #(s): | |
| Created: | February 11, 2005 |
Updated: | February 14, 2005 |
| Description: |
Tavis Ormandy of the Gentoo Linux Security Audit Team discovered that
the Webmin ebuild contains a design flaw. It imports the encrypted
local root password into the miniserv.users file before building binary
packages that include this file. A remote attacker could retrieve
Portage-built Webmin binary packages and recover the encrypted root
password from the build host. |
| Alerts: |
|
Comments (none posted)
xpcd: buffer overflow in pcdsvgaview
| Package(s): | xpcd |
CVE #(s): | CAN-2005-0074
|
| Created: | February 11, 2005 |
Updated: | February 14, 2005 |
| Description: |
Erik Sjölund discovered a buffer overflow in pcdsvgaview, an SVGA
PhotoCD viewer. xpcd-svga is part of xpcd and uses svgalib to display
graphics on the Linux console for which root permissions are required.
A malicious user could overflow a fixed-size buffer and may cause the
program to execute arbitrary code with elevated privileges. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
a2ps: input validation error
| Package(s): | a2ps |
CVE #(s): | CAN-2004-1170
CAN-2004-1377
|
| Created: | November 26, 2004 |
Updated: | December 19, 2005 |
| Description: |
The GNU a2ps utility fails to properly sanitize filenames, which can be
abused by a malicious user to execute arbitrary commands with the
privileges of the user running the vulnerable application. More
information at Security
Focus. |
| Alerts: |
|
Comments (none posted)
AWStats: remote code execution
| Package(s): | awstats |
CVE #(s): | CAN-2005-0116
CAN-2005-0362
CAN-2005-0363
|
| Created: | January 25, 2005 |
Updated: | February 15, 2005 |
| Description: |
When 'awstats.pl' is run as a CGI script, it fails to validate specific
inputs which are used in a Perl open() function call. A remote attacker
could supply AWStats malicious input, potentially allowing the execution of
arbitrary code with the rights of the web server. |
| Alerts: |
|
Comments (1 posted)
cdrecord: failure to drop privilege
| Package(s): | cdrecord |
CVE #(s): | CAN-2004-0806
|
| Created: | September 8, 2004 |
Updated: | February 21, 2005 |
| Description: |
The cdrecord utility, which is installed setuid on some distributions, fails to drop privilege before running a user-specified program. |
| Alerts: |
|
Comments (none posted)
ClamAV: multiple issues
| Package(s): | clamav |
CVE #(s): | CAN-2005-0133
|
| Created: | January 31, 2005 |
Updated: | March 3, 2005 |
| Description: |
ClamAV fails to properly scan ZIP files with special headers and base64
encoded images in URLs. |
| Alerts: |
|
Comments (none posted)
cpio - file permissions error
| Package(s): | cpio |
CVE #(s): | CAN-1999-1572
|
| Created: | February 2, 2005 |
Updated: | July 19, 2005 |
| Description: |
Some versions of cpio contain an ancient vulnerability where files created by that utility have overly generous access permissions. |
| Alerts: |
|
Comments (none posted)
cups: multiple vulnerabilities
| Package(s): | cups |
CVE #(s): | CAN-2004-1267
CAN-2004-1268
CAN-2004-1269
CAN-2004-1270
|
| Created: | December 17, 2004 |
Updated: | February 9, 2005 |
| Description: |
cups has a denial of service vulnerability in the lppasswd utility
and a remote code execution vulnerability in the hpgltops filter. |
| Alerts: |
|
Comments (none posted)
cyrus-sasl: remote buffer overflow
| Package(s): | cyrus-sasl |
CVE #(s): | CAN-2004-0884
|
| Created: | October 7, 2004 |
Updated: | March 16, 2005 |
| Description: |
cyrus-sasl has a vulnerability involving a buffer overflow
in the digestmda5.c file. A remote attacker may be able
to compromise the system. Also, a local user may be able to
exploit a vulnerability by using the SASL_PATH environment
variable. |
| Alerts: |
|
Comments (none posted)
dhcp: format string vulnerability
| Package(s): | dhcp |
CVE #(s): | CAN-2004-1006
|
| Created: | November 4, 2004 |
Updated: | July 13, 2005 |
| Description: |
Dhcp has a format string vulnerability in the log functions of dhcp 2.x
that may be exploited via a malicious DNS server. |
| Alerts: |
|
Comments (none posted)
emacs21: format string vulnerability in "movemail"
| Package(s): | emacs21 |
CVE #(s): | CAN-2005-0100
|
| Created: | February 7, 2005 |
Updated: | May 15, 2006 |
| Description: |
Max Vozeler discovered a format string vulnerability in the "movemail"
utility of Emacs. By sending specially crafted packets, a malicious
POP3 server could cause a buffer overflow, which could be exploited to
execute arbitrary code with the privileges of the user and the "mail"
group. |
| Alerts: |
|
Comments (none posted)
enscript: arbitrary code execution
| Package(s): | enscript |
CVE #(s): | CAN-2004-1184
CAN-2004-1185
CAN-2004-1186
|
| Created: | January 21, 2005 |
Updated: | May 27, 2006 |
| Description: |
Erik Sjölund has discovered several security relevant problems in enscript,
a program to convert ASCII text into Postscript and other formats.
Unsanitized input can cause the execution of arbitrary commands via EPSF
pipe support. Due to missing sanitizing of filenames it is possible that a
specially crafted filename can cause arbitrary commands to be executed.
Multiple buffer overflows can cause the program to crash. |
| Alerts: |
|
Comments (none posted)
ethereal: multiple vulnerabilites
Comments (none posted)
evolution: arbitrary code execution
| Package(s): | evolution |
CVE #(s): | CAN-2005-0102
|
| Created: | January 24, 2005 |
Updated: | May 19, 2005 |
| Description: |
Max Vozeler discovered an integer overflow in camel-lock-helper. A
user-supplied length value was not validated, so that a value of -1
caused a buffer allocation of 0 bytes; this buffer was then filled by
an arbitrary amount of user-supplied data. A local attacker or a malicious
POP3 server could exploit this to execute arbitrary code with root
privileges (because camel-lock-helper is installed as setuid root). |
| Alerts: |
|
Comments (1 posted)
exim: buffer overflows
Comments (1 posted)
f2c: insecure temp files
| Package(s): | f2c |
CVE #(s): | CAN-2005-0017
CAN-2005-0018
|
| Created: | January 27, 2005 |
Updated: | April 20, 2005 |
| Description: |
The f2c fortran to C translator has a vulnerability due to
insecure opening of temporary files. A local attacker can use this
to launch a symlink attack. |
| Alerts: |
|
Comments (none posted)
Foomatic: Arbitrary command execution in foomatic-rip
| Package(s): | foomatic |
CVE #(s): | CAN-2004-0801
|
| Created: | September 20, 2004 |
Updated: | May 31, 2006 |
| Description: |
There is a vulnerability in the foomatic-filters package. This
vulnerability is due to insufficient checking of command-line parameters
and environment variables in the foomatic-rip filter. This vulnerability
may allow both local and remote attackers to execute arbitrary commands on
the print server with the permissions of the spooler. |
| Alerts: |
|
Comments (none posted)
gaim: buffer overflow in MSN protocol
| Package(s): | gaim |
CVE #(s): | CAN-2004-0891
|
| Created: | October 25, 2004 |
Updated: | February 11, 2005 |
| Description: |
A buffer overflow in the MSN protocol handler for gaim 0.79 to 1.0.1 allows
remote attackers to cause a denial of service (application crash) and
possibly execute arbitrary code via an "unexpected sequence of MSNSLP
messages" that results in an unbounded copy operation that writes to the
wrong buffer. |
| Alerts: |
|
Comments (none posted)
Gallery: cross-site scripting vulnerability
| Package(s): | gallery |
CVE #(s): | |
| Created: | January 31, 2005 |
Updated: | February 10, 2005 |
| Description: |
Rafel Ivgi has discovered a cross-site scripting vulnerability where
the 'username' parameter is not properly sanitized in 'login.php'. See
this Gallery
announcement for the release of 1.4.4-pl5 for more information. |
| Alerts: |
|
Comments (none posted)
gtk2, gdk-pixbuf: buffer overflows
| Package(s): | gdk-pixbuf gtk2 |
CVE #(s): | CAN-2004-0753
CAN-2004-0782
CAN-2004-0783
CAN-2004-0788
|
| Created: | September 15, 2004 |
Updated: | February 25, 2005 |
| Description: |
The gdk-pixbuf and gtk2 libraries contain vulnerabilities in their handling of BMP and XPM files which can lead to denial of service and, potentially, code execution attacks. |
| Alerts: |
|
Comments (none posted)
gettext: Insecure temporary file handling
| Package(s): | gettext |
CVE #(s): | CAN-2004-0966
|
| Created: | October 11, 2004 |
Updated: | March 1, 2006 |
| Description: |
gettext insecurely creates temporary files in world-writeable directories
with predictable names. A local attacker could create symbolic links in
the temporary files directory, pointing to a valid file somewhere on the
filesystem. When gettext is called, this would result in file access with
the rights of the user running the utility, which could be the root user. |
| Alerts: |
|
Comments (1 posted)
ghostscript: symlink vulnerabilities
| Package(s): | ghostscript |
CVE #(s): | CAN-2004-0967
|
| Created: | October 20, 2004 |
Updated: | September 28, 2005 |
| Description: |
The ghostscript package (prior to version 7.07.1-r7) contains several scripts which are vulnerable to symlink attacks. |
| Alerts: |
|
Comments (none posted)
glibc: Information leak with LD_DEBUG
| Package(s): | glibc |
CVE #(s): | CAN-2004-1453
|
| Created: | August 17, 2004 |
Updated: | May 26, 2005 |
| Description: |
Silvio Cesare discovered a potential information leak in glibc. It allows
LD_DEBUG on SUID binaries where it should not be allowed. This has various
security implications, which may be used to gain confidential information.
An attacker can gain the list of symbols a SUID application uses and their
locations and can then use a trojaned library taking precedence over those
symbols to gain information or perform further exploitation. |
| Alerts: |
|
Comments (1 posted)
glibc: tempfile vulnerability in catchsegv script
| Package(s): | glibc |
CVE #(s): | CAN-2004-0968
|
| Created: | October 21, 2004 |
Updated: | November 14, 2005 |
| Description: |
The catchsegv script in the glibc package has a symlink vulnerability
that may allow a local user to overwrite arbitrary
files with the permissions of the user that is running the script. |
| Alerts: |
|
Comments (none posted)
gnome-vfs: backend script vulnerabilities
| Package(s): | gnome-vfs |
CVE #(s): | CAN-2004-0494
|
| Created: | August 4, 2004 |
Updated: | February 21, 2005 |
| Description: |
Several scripts packaged with gnome-vfs, using its "extfs" capability, have security flaws. These scripts tend not to be used on many systems, but their presence can still be a threat. |
| Alerts: |
|
Comments (none posted)
groff: insecure temporary directory
| Package(s): | groff |
CVE #(s): | CAN-2004-0969
|
| Created: | November 1, 2004 |
Updated: | February 9, 2006 |
| Description: |
Recently, Trustix Secure Linux discovered a vulnerability in the groff
package. The utility "groffer" created a temporary directory in an
insecure way, which allowed exploitation of a race condition to create
or overwrite files with the privileges of the user invoking the
program. |
| Alerts: |
|
Comments (none posted)
gtkhtml: malformed messages cause crash
| Package(s): | gtkhtml |
CVE #(s): | CAN-2003-0133
CAN-2003-0541
|
| Created: | April 14, 2003 |
Updated: | April 18, 2005 |
| Description: |
GtkHTML is the HTML rendering widget used by the Evolution mail reader.
GtkHTML supplied with versions of Evolution prior to 1.2.4 contain a bug
when handling HTML messages. Alan Cox discovered that certain malformed
messages could cause the Evolution mail component to crash. |
| Alerts: |
|
Comments (none posted)
imagemagick: .psd image file decode vulnerability
| Package(s): | imagemagick |
CVE #(s): | CAN-2005-0005
|
| Created: | January 18, 2005 |
Updated: | March 23, 2005 |
| Description: |
According to this iDEFENSE advisory,
ImageMagick is vulnerable to a heap overflow when decoding .psd image
files. This could be remotely exploited allowing an attacker to execute
arbitrary code. |
| Alerts: |
|
Comments (1 posted)
imlib2: buffer overflows
| Package(s): | imlib2 |
CVE #(s): | CAN-2004-0802
CAN-2004-0817
|
| Created: | September 8, 2004 |
Updated: | October 26, 2005 |
| Description: |
The imlib2 library contains buffer overflows in the BMP handling code. |
| Alerts: |
|
Comments (none posted)
iptables: missing initialization
| Package(s): | iptables |
CVE #(s): | CAN-2004-0986
|
| Created: | November 1, 2004 |
Updated: | February 11, 2005 |
| Description: |
Faheem Mitha noticed that the iptables command, an administration tool for
IPv4 packet filtering and NAT, did not always load the required modules on
its own as it was supposed to. This could lead to firewall rules not being
loaded on system startup. This caused a failure in connection with rules
provided by lokkit at least. |
| Alerts: |
|
Comments (none posted)
kdeenu: buffer overflow in fliccd
| Package(s): | kdeenu kstars |
CVE #(s): | CAN-2005-0011
|
| Created: | February 16, 2005 |
Updated: | February 18, 2005 |
| Description: |
Erik Sjolund discovered a buffer overflow in fliccd which is part of
kdeedu, edutainment applications for KDE. An attacker could exploit this
vulnerability to execute code with elevated privileges. If fliccd does not
run as daemon remote exploitation of this vulnerability is not possible. |
| Alerts: |
|
Comments (none posted)
kdelibs: unsanitzied input
| Package(s): | kdelibs |
CVE #(s): | CAN-2004-1165
|
| Created: | January 10, 2005 |
Updated: | July 19, 2005 |
| Description: |
Thiago Macieira discovered a vulnerability in the kioslave library,
which is part of kdelibs, which allows a remote attacker to execute
arbitrary FTP commands via an ftp:// URL that contains an URL-encoded
newline before the FTP command. |
| Alerts: |
|
Comments (none posted)
kerberos5: execution of arbitrary code by authenticated user
| Package(s): | kerberos5 |
CVE #(s): | CAN-2004-1189
|
| Created: | December 21, 2004 |
Updated: | February 15, 2005 |
| Description: |
There is a buffer overflow in the password history handling code of
libkadm5srv which could be exploited by an authenticated user to execute
arbitrary code on a Key Distribution Center (KDC) server. |
| Alerts: |
|
Comments (none posted)
kernel: i386 SMP page fault handler privilege escalation
| Package(s): | kernel |
CVE #(s): | CAN-2005-0001
|
| Created: | January 14, 2005 |
Updated: | February 25, 2005 |
| Description: |
Paul Starzetz found an exploitable hole in the x86 SMP page fault handler
which could lead to privilege escalation. See the advisory for details. |
| Alerts: |
|
Comments (none posted)
libdbi-perl: insecure temporary file
| Package(s): | libdbi-perl |
CVE #(s): | CAN-2005-0077
|
| Created: | January 25, 2005 |
Updated: | March 2, 2006 |
| Description: |
Javier Fernández-Sanguino Peña from the Debian Security Audit Project
discovered that the DBI library, the Perl5 database interface, creates
a temporary PID file in an insecure manner. This can be exploited by a
malicious user to overwrite arbitrary files owned by the person
executing the parts of the library. |
| Alerts: |
|
Comments (none posted)
libgd2: buffer overflows in PNG handling
| Package(s): | libgd2 |
CVE #(s): | CAN-2004-0990
CAN-2004-0941
|
| Created: | October 29, 2004 |
Updated: | June 28, 2006 |
| Description: |
Several buffer overflows have been discovered in libgd's PNG handling
functions.
If an attacker tricked a user into loading a malicious PNG image, they
could leverage this into executing arbitrary code in the context of
the user opening image. Most importantly, this library is commonly
used in PHP. One possible target would be a PHP driven photo website
that lets users upload images. Therefore this vulnerability might lead
to privilege escalation to a web server's privileges.
Multiple buffer overflows in the gd graphics library (libgd) 2.0.21 and
earlier may allow remote attackers to execute arbitrary code via malformed
image files that trigger the overflows due to improper calls to the
gdMalloc function. |
| Alerts: |
|
