The X Window System, past and future
The Jargon File
defines X as
"
An over-sized, over-featured, over-engineered and incredibly
over-complicated window system developed at MIT and widely used on Unix
systems." The
Unix Hater's Handbook states: "
X Windows
[sic] is the Iran-Contra of graphical user interfaces: a tragedy of
political compromises, entangled alliances, marketing hype, and just plain
greed." The "fortune" program shipped with most Linux
distributions contains
six extended
diatribes against X, with delightful tidbits like:
"
The trailing edge of software technology.",
"
The greatest productivity aid since typhoid.",
"
You'll envy the dead.",
and
"
Making the world safe for competing window systems.".
And those are just from the first of six. The last dig quoted above
is interesting, though, when confronted with one little fact: there
are no competing window systems.
Most LWN readers will be aware by now of the current dispute over the
direction of the XFree86 project. The next article will look at what is
going on there, but, first, it's worth taking a moment to look at the
absolute monopoly that X holds on Linux (and Unix) desktops.
As free software projects go, X is one of the older ones. The first X
release, built with support from the company then known as Digital
Equipment Corporation, came out of MIT in 1984. By the time X10 was
released, the window system was beginning to be widely used
outside of MIT, but it was X11 (released
on September 15, 1987 - you could order it on nine-track tape) that
established X as the definitive Unix windowing environment. Several
vendors, wanting to support the continued development of a vendor-neutral
windowing system, formed the X Consortium to further support development in
1988. The Consortium eventually lost its relevance when the Unix vendors
decided they wanted to start "differentiating" their window systems, and
the XFree86 project became the real core of X11 development. That, of
course, is how things stand today.
X11 is certainly one of the longest-lasting major releases in software
history; more than fifteen years later the X11 protocol maintains backward
compatibility, and there has never been an X12 release.
Since the early days, X has been the target of severe criticism. Attackers
claim that it is over-engineered and bloated. Its absolute refusal to
dictate policy (or even provide a standard window manager) has led to
wildly incompatible interfaces on the same desktop. X requires
applications to deal with too much information about the underlying
hardware. The network-based client/server protocol is slow and has led to
security problems. There is no way to load code into the server itself.
The server doesn't even maintain window contents, forcing applications to
deal with "expose" events. And so on. X, it is said, is "vacuumware," it
sucks, but succeeded because there was nothing else out there.
The above criticisms are, beyond doubt, not entirely lacking in merit. But
the fact remains that X is the only viable windowing system for
Unix-like systems. It pushed aside numerous proprietary systems (SunView
was halfway out the door before Sun officially switched) and established
itself as the standard across an amazing range of systems from
different vendors. If X were truly that bad, a viable competitor would
certainly have arisen in the 15 years since X11R1 was released. The few
attempts (your editor once had the unfortunate experience of trying to
program a project under NeWS) have sunk without a trace.
Why has X been so successful? Here's a few possible reasons:
- X actually does pretty well at hiding hardware details for
many applications. But the ability (and, occasionally, requirement)
to deal with the hardware allowed the writing of applications that
behaved optimally on a wide range of systems.
- The X client/server protocol was unique; it enabled the separation
of applications from the desktop where their interfaces were
displayed. If you were a system admin who suddenly could easily
monitor several servers on one screen, or a scientific user who could
run supercomputer visualizations from your desktop, this was a
big deal.
- The refusal to set policy allowed a great deal of experimentation
in user interface policies. Lots of bad ideas (i.e. tiling window
managers, Motif) were tried and discarded without having been wired
into the window system itself. Even now, X provides a platform where
competing visions of the desktop can be implemented and tried out.
- The built-in extensibility of the X11 protocol has allowed it to
evolve over time without breaking compatibility with older
applications.
- It works, and has for a long time.
Of course, one should not forget the other important reason why X succeeded
back in the 1980's: it was free software.
So now X dominates the non-Windows desktop. Given the extent to which some
people criticize X, one would assume there would be a whole set of
development projects working to replace it. The fact that X works well
and the existence of a large set of existing X
applications present a daunting challenge to any potential replacement,
however. Without a compelling reason to change (and rock-solid X
compatibility), users are likely to remain with X for quite some time into
the future. So it is not surprising that free software projects working on
X replacements are not easy to find. There just isn't that much of an itch
to scratch.
One group that is trying, however, is the Fresco project
(formerly known as "Berlin"). Fresco's approach differs from that of X in many
ways: user interface policy will be wired into the window system itself;
more advanced rendering will be supported by the server; the API will be
based on vector operations and will be resolution-independent; CORBA will
be used as the network transport; and the whole thing will be built with
heavy use of threading in mind.
Potential users will need to be patient; according to the web site,
"Fresco
is only useful for demos (really cool demos though :)". Fresco announced its second
milestone release on March 4.
Someday a project like Fresco may well succeed in displacing X from our
desktops. Someday. Meanwhile, X will remain one of the crucial components
of free operating systems like Linux. So the current disagreements over
the direction of the XFree86 project are important.
Comments (17 posted)
The Future of XFree86
[This article was contributed by Joe 'Zonker' Brockmeier]
Sometimes a good argument is necessary to get everything out in the open
and to make a little progress. That seems to be the case with the
current XFree86 controversy.
If you haven't been following it, the furor started when XFree86
developer Keith Packard was ousted from the Core Team. Apparently,
Packard was trying to start a fork of the project without discussing the issue with other Core Team members first.
After the dust had settled, somewhat, the XFree86 Project's board issued
an open
invitation to discuss "Any topics...from those related to
administrative and management issues through to technical issues." In
just eight days, more than 700 messages have been sent to the list. A
lot of ideas have been thrown around, including a joint
statement from the GNOME and KDE projects.
Packard has now made public some of his complaints with the current
status of the XFree86 Project. His "A Call
For Open Governance Of X Development" posits that there are a number
of problems with development of XFree86. Specifically, Packard writes
that XFree86 suffers from limited development resources, slow release
schedules, a lack of cooperation with other projects and a lack of
information on how to get involved with XFree86 development. Packard
concludes that XFree86 needs to be a community-governed project.
The XFree86 Project has already responded to
Packard's complaint that there is a lack of information on becoming a
developer by adding a prominent link to the front page titled "How to
become an XFree86 Developer." Short and to the point, it nevertheless
provides some guidance for interested developers: "Get and build the
latest XFree86 code from the CVS repository, subscribe to the XFree86
developer list (devel@XFree86.org) and participate."
David Wexelblat, one of the Core Team members, notes that the issue of infrequent releases, at least in terms of card support, is a non-issue:
I will ALSO point out for the record that ever since we did the loadable
driver thing, there is NO NEED for XFree86 to put out a release to get
new device support (or so the theory goes). The card vendors can do it.
Nvidia does it, and ATI does it, right? Yes, there is more work to do on
ABI-type issues to make this work better, but the drivers are not built
into the server binaries any more.
David Dawes, head of the XFree86 Board of Directors and leader of the
core team has
committed to tagging regular snapshots, every two weeks, of the CVS
trunk. This doesn't address the question of more frequent stable
releases, but it should provide a way for more people to be involved in
testing XFree86 and providing feedback.
Wexelblat also disagrees that XFree86 should be community-governed.
"There is no reason to change the meritocracy, other than to work on
promoting sufficient people through it, of sufficient
skill/quality/integridy [sic] to get the work done." Rich Murphey,
another member of the XFree86 board, agrees
that "sweat equity" is the
best way to have influence on the direction of the project. "Join
devel, write code, join core. That's how it works...I don't see a more
effective solution than that."
Both Packard and Wexelblat agree that XFree86 could benefit from
additional resources. Wexelblat raises the issue of poor support for
XFree86 by commercial companies:
Another thing to note is that XFree86 has dramatically less commercial
support than just about any "cornerstone" Open Source project. Maybe
that's because of our "meritocracy" and focus on individual
contributors; I dunno. I know that these companies have LOTS of people
working on Linux kernels, databases, desktops, whatever, and bloody few
pay very many to work on X. So it mostly falls to a very small handful
of people. Who are pretty much volunteering, and doing what they can
when they can...For many of the things commercial entities complain
about, I say "put up or shut up".
Given the importance of XFree86 to the long-term success of Linux on the
desktop, now might be a good time for some of the Linux companies to
step up support for XFree86. It seems clear that, regardless of other
changes, XFree86 development will remain a meritocracy.
However, the attention now being focused on the project is likely to
produce some long-term benefits despite the initial unpleasantness.
Comments (8 posted)
Quick LWN update
Time flies... it is now six months since LWN began the subscription
experiment. How do we know? Many of you signed up for six-month
subscriptions, and those are now expiring. If you are one of those, it's
time to be thinking about renewing; remember that prepaid subscriptions of
ten months or longer get a 10% discount.
LWN's subscribers are the only thing keeping this site on the net; we thank
you for your support.
Comments (15 posted)
Page editor: Jonathan Corbet
Security
Security news
Relaxing with the XDR Vulnerability
[This article was contributed by Tom Owen]
A vulnerability in a library is unsettling.
When the affected code is in glibc it seems like genuine grounds for alarm.
Not only the library itself, but potentially every static-linked executable
may need to be replaced or rebuilt,
and it takes a very confident system administrator to swear to the link
status of everything
on the system.
These vulnerabilities do appear from time to time.
Fortunately, it generally turns out that thought is a substitute for panicky
rebuilds.
The
XDR vulnerability
provides a handy example.
RPC (Remote Procedure Call) is an upper-layer network protocol developed by Sun
as part of their
vision of network-centric computing.
Services offered via RPC appear to be simple functions which are called by
applications; this system has been a key basis for many distributed
applications, with NFS being the most famous.
One obstacle to passing program data between hosts is the varying
binary representation of basic data types like integers and floating point
numbers.
Ones-complement integers aren't much of a problem these days, but little and
big endian
byte orders are in use as are non-IEEE floating point formats.
The solution used by Sun is for all hosts to convert data to and from a
standard network representation; this representation is called "external
data representation," or XDR.
The routines for XDR data conversion are included in glibc.
One of these routines
(xdr_array()) has a vulnerability
where a crafted message can cause a buffer overflow.
Finding out how much to worry about this vulnerability is really a matter
of finding all of
the uses of the XDR code in your system.
The place to start is with the new glibc itself.
There's no good reason not to install this update --
it's insurance against changes in the future if nothing else.
Another sensible precaution for any site is to ensure that RPC network traffic
is stopped at the firewall.
Running RPC across the public Internet is a fine security challenge,
but not an obvious win.
A complete block takes a bit of research as RPC ports sometimes vary from site
to site,
but blocking TCP and UDP for 111 (the portmapper) and 2049 (NFS) is a start.
If RPC can't get in from outside then you won't be interpreting any external
messages as XDR.
For many Linux sites RPC is needed to support NFS, or other services
like NIS.
That's the first stopping point --
all sites without NFS and without some other need for RPC-based services
can stop now. Job done.
The next set of easy exits is for the bulk of those RPC and NFS sites.
Dynamic linking has its downside, but like most good ideas,
its disadvantages turn out to be the same as its benefits.
For certain, dynamic linking means that a working system can be silently wrecked
by installing an application with an incompatible version of some library.
But that same feature gets us out of trouble here --
if ever there was a library to link dynamically,
glibc -- stable and ubiquitous -- is it.
Distributors that have published fixes are typically offering the updated
library itself
and perhaps some NFS daemons.
Since most applications use dynamic linking with glibc, replacing that
library is sufficient to close the vulnerability. For most sites, updating
glibc is all that is required.
Everybody left counts as a programmer or a builder.
Programmers will know whether they have a problem.
The rest of us -- call us naive builders -- are the ones with the problem.
It's here that we have to fall back on the safe course.
If we truly can't tell whether we're using the XDR functions or static
linking then, finally,
it's time to rebuild and reinstall our applications.
Comments (3 posted)
New vulnerabilities
bonsai: multiple vulnerabilites
| Package(s): | bonsai |
CVE #(s): | CAN-2003-0152
CAN-2003-0153
CAN-2003-0154
CAN-2003-0155
|
| Created: | March 21, 2003 |
Updated: | March 26, 2003 |
| Description: |
Remi Perrot fixed several security related bugs in bonsai, the Mozilla CVS
query tool by web interface. Vulnerabilities include arbitrary code
execution, cross-site scripting and access to configuration parameters.
The Common Vulnerabilities and Exposures project identifies the following
problems:
- CAN-2003-0152 - Remote execution of arbitrary commands as www-data
- CAN-2003-0153 - Absolute path disclosure
- CAN-2003-0154 - Cross site scriptiong attacks
- CAN-2003-0155 - Unauthenticated access to parameters page
|
| Alerts: |
|
Comments (none posted)
delegate - remote code execution vulnerability
| Package(s): | delegate |
CVE #(s): | |
| Created: | March 20, 2003 |
Updated: | March 26, 2003 |
| Description: |
According to a SNS
security advisory, a remote code execution vulnerability exists in the
application level gateway DeleGate
version 8.4.0 and earlier. Fetching a large robots.txt file through
DeleGate HTTP proxy could result in a buffer overflow. |
| Alerts: |
|
Comments (none posted)
evolution: multiple vulnerabilities
| Package(s): | Evolution |
CVE #(s): | CAN-2003-0128
CAN-2003-0129
CAN-2003-0130
|
| Created: | March 21, 2003 |
Updated: | May 14, 2003 |
| Description: |
Multiple vulnerabilities have been found in Ximian's Evolution Mail User
Agent, according to this
CoreLabs advisory.
"Three vulnerabilities were found that could lead to various forms of
exploitation ranging from denying to users the ability to read email,
provoke system unstability, bypassing security context checks for email
content and possibly execution of arbitrary commands on vulnerable
systems."
Ximian Evolution is a personal and
workgroup information management solution for Linux and UNIX-based
systems. The software integrates email, calendaring, meeting scheduling,
contact management, and task lists, in one application. |
| Alerts: |
|
Comments (1 posted)
glibc: integer overflow in the xdrmem_getbytes() function
| Package(s): | glibc krb5 dietlibc |
CVE #(s): | CAN-2003-0028
|
| Created: | March 21, 2003 |
Updated: | May 27, 2003 |
| Description: |
An integer overflow in the xdrmem_getbytes() function, and possibly other
functions, of XDR (external data representation) libraries derived from
SunRPC, including libnsl, libc, and glibc, allows remote attackers to
execute arbitrary code via certain integer values in length fields
See
CAN-2003-0028 and CERT advisory
CA-2003-10 for more information. |
| Alerts: |
|
Comments (3 posted)
ircii: buffer overflow vulnerability
| Package(s): | ircii |
CVE #(s): | |
| Created: | March 20, 2003 |
Updated: | April 22, 2003 |
| Description: |
Timo Sirainen audited ircII based clients (see this Bugtraq post) and
found some buffer overflow vulnerabilities in ircii-20020912. |
| Alerts: |
|
Comments (none posted)
kerberos - cryptographic weakness
| Package(s): | kerberos, heimdal, openafs |
CVE #(s): | CAN-2003-0138
CAN-2003-0139
|
| Created: | March 26, 2003 |
Updated: | May 27, 2003 |
| Description: |
Version 4 of the Kerberos protocol contains a cryptographic weakness which enables a chosen-plaintext attack. A suitably equipped attacker can impersonate any principal in the realm. Another weakness allows the creation of false Kerberos tickets. Given the weaknesses in the cryptography, cross-realm authentication cannot be performed in a secure way.
OpenAFS
kaserver implements version 4 of the Kerberos protocol, and therefore
is also vulnerable. |
| Alerts: |
|
Comments (none posted)
mutt: buffer overflow in IMAP client code
| Package(s): | mutt |
CVE #(s): | CAN-2003-0140
|
| Created: | March 21, 2003 |
Updated: | April 22, 2003 |
| Description: |
Core
Security Technologies has found a remotely exploitable buffer overflow
in mutt's IMAP client code. This Bugtraq post
contains additional information.
The problem has been fixed in Mutt 1.4.1 (stable) and 1.5.4 (unstable). |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
apcupsd - remote root vulnerability and buffer overflows
| Package(s): | apcupsd |
CVE #(s): | CAN-2003-0098
CAN-2003-0099
|
| Created: | February 24, 2003 |
Updated: | April 3, 2003 |
| Description: |
From the MandrakeSoft
advisory:
A remote root vulnerability in slave setups and some buffer overflows in
the network information server code were discovered by the apcupsd
developers. They have been fixed in the latest unstable version, 3.10.5
which contains additional enhancements like USB support, and the latest
stable version, 3.8.6.
There are a few changes that need to be noted, such as the port has changed
from port 7000 to post 3551 for NIS, and the new config only allows access
from the localhost. Users may need to modify their configuration files
appropriately, depending upon their configuration. |
| Alerts: |
|
Comments (none posted)
Heap corruption vulnerability in at
| Package(s): | at at, sudo, xchat |
CVE #(s): | CAN-2002-0004
|
| Created: | May 20, 2002 |
Updated: | May 15, 2003 |
| Description: |
The at command has a
potentially exploitable heap corruption bug.
(First LWN report: January 17th).
|
| Alerts: |
|
Comments (none posted)
bind buffer overflow vulnerability in DNS resolver libraries
| Package(s): | bind glibc |
CVE #(s): | CAN-2002-0651
CAN-2002-0684
|
| Created: | July 8, 2002 |
Updated: | September 30, 2003 |
| Description: |
The BIND 4.9.8-OW2 patch and BIND 4.9.9 release (and thus 4.9.9-OW1)
include fixes for a libc related vulnerability which does not
affect Linux. Updates from
the Internet Software Consortium (ISC)
are available from here.
No release or branch of Openwall GNU/*/Linux (Owl) is known to be
affected, due to Olaf Kirch's fixes for this problem getting into the
GNU C library more than two years ago.
Unfortunatly that does not mean that Linux systems are not vulnerable.
Similar code, without Olaf Firch's fixes,
is in the glibc getnetbyXXX functions.
These functions are described in the SuSE alert as
"
used by very few applications only, such as ifconfig and ifuser,
which makes exploits less likely."
CERT Advisory: CA-2002-19
Buffer Overflow in Multiple DNS Resolver Libraries
CAN-2002-0651
CAN-2002-0684 |
| Alerts: |
|
Comments (1 posted)
BitchX - denial of service
| Package(s): | BitchX |
CVE #(s): | |
| Created: | February 20, 2003 |
Updated: | May 26, 2003 |
| Description: |
From this Bugtraq posting:
A denial of service vulnerability exists in BitchX. Sending a malformed
RPL_NAMREPLY numeric 353 causes BitchX to segfault. This problem was
reported to panasync@efnet#bitchx on Jan 30 2003, as of this writing we are
unaware of any patches or workarounds provided by panasync and or any
members of #bitchx |
| Alerts: |
|
Comments (none posted)
Canna server: exploitable buffer overrun
| Package(s): | canna |
CVE #(s): | CAN-2002-1158
CAN-2002-1159
|
| Created: | December 10, 2002 |
Updated: | September 30, 2003 |
| Description: |
Canna is a kana-kanji conversion server which is necessary for Japanese
language character input.
A buffer overflow bug in the Canna server up to and including version 3.5b2
allows a local user to gain the privileges of the user 'bin' which could
lead to further exploits. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2002-1158 to this issue.
A lack of validation of requests has been found that affects Canna version
3.6 and earlier. A malicious remote user could exploit this vulnerability
to leak information, or cause a denial of service attack. (CAN-2002-1159)
See also
http://canna.sourceforge.jp/sec/Canna-2002-01.txt
CAN-2002-1158
CAN-2002-1159 |
| Alerts: |
|
Comments (none posted)
CVS - exploitable double-free bug in the CVS server
| Package(s): | cvs |
CVE #(s): | CAN-2003-0015
|
| Created: | January 20, 2003 |
Updated: | April 7, 2003 |
| Description: |
CVS is a version control system frequently used to manage source code
repositories. During an audit of the CVS sources, Stefan Esser
discovered an exploitable double-free bug in the CVS server.
On servers which are configured to allow anonymous read-only access, this
bug could be used by anonymous users to gain write privileges. Users with
CVS write privileges can then use the Update-prog and Checkin-prog features
to execute arbitrary commands on the server.
All users of CVS are advised to upgrade to erratum packages which contain
patches to correct the double-free bug.
See also this CERT advisory |
| Alerts: |
|
Comments (none posted)
dhcp3 - ignored counter boundary
| Package(s): | dhcp3 |
CVE #(s): | CAN-2003-0039
|
| Created: | January 28, 2003 |
Updated: | April 4, 2003 |
| Description: |
Florian Lohoff discovered a bug in the dhcrelay causing it to send a
continuing packet storm towards the configured DHCP server(s) in case
of a malicious BOOTP packet, such as sent from buggy Cisco switches.
When the dhcp-relay receives a BOOTP request it forwards the request
to the DHCP server using the broadcast MAC address ff:ff:ff:ff:ff:ff
which causes the network interface to reflect the packet back into the
socket. To prevent loops the dhcrelay checks whether the
relay-address is its own, in which case the packet would be dropped.
In combination with a missing upper boundary for the hop counter an
attacker can force the dhcp-relay to send a continuing packet storm
towards the configured dhcp server(s).
This patch introduces a new commandline switch ``-c maxcount'' and
people are advised to start the dhcp-relay with ``dhcrelay -c 10''
or a smaller number, which will only create that many packets.
The dhcrelay program from the ``dhcp'' package does not seem to be
affected since DHCP packets are dropped if they were apparently
relayed already. |
| Alerts: |
|
Comments (none posted)
dvips: command execution vulnerability
| Package(s): | dvips |
CVE #(s): | CAN-2002-0836
|
| Created: | October 16, 2002 |
Updated: | June 10, 2003 |
| Description: |
The dvips utility uses the system() function improperly when managing fonts. An attacker who can craft the right sort of print job can use this vulnerability to execute commands under the UID used by the print system. |
| Alerts: |
|
Comments (none posted)
ethereal - format string vulnerability
| Package(s): | ethereal |
CVE #(s): | CAN-2003-0081
|
| Created: | March 10, 2003 |
Updated: | June 12, 2003 |
| Description: |
The SOCKS dissector in Ethereal 0.9.9 is susceptible to a format string
overflow. This vulnerability has been present in Ethereal since the SOCKS
dissector was introduced in version 0.8.7. It was discovered by Georgi
Guninski. Additionally, the NTLMSSP code is susceptible to a heap
overflow. All users of Ethereal 0.9.9 and below are encouraged to upgrade.
See the full
advisory for additional information. |
| Alerts: |
|
Comments (none posted)
Filename disclosure vulnerability in fam
| Package(s): | fam |
CVE #(s): | CAN-2002-0875
|
| Created: | August 19, 2002 |
Updated: | January 5, 2005 |
| Description: |
"fam" (file alteration monitor) watches files and directories for changes and lets interested applications know when something happens. This package has a flaw in its group handling that blocks some legitimate operations while, at the same time, exposing the names of files that should otherwise be invisible. |
| Alerts: |
|
Comments (none posted)
fetchmail: buffer overflow
| Package(s): | fetchmail |
CVE #(s): | CAN-2002-1365
|
| Created: | December 17, 2002 |
Updated: | October 20, 2003 |
| Description: |
Versions of fetchmail prior to 6.2.0 have (yet another) buffer overflow vulnerability which can be exploited remotely via a suitably crafted message. See this advisory for details. |
| Alerts: |
|
Comments (3 posted)
file - memory allocation problem, stack overflow
| Package(s): | file |
CVE #(s): | CAN-2003-0102
|
| Created: | March 4, 2003 |
Updated: | June 4, 2003 |
| Description: |
Jeff Johnson found a memory allocation problem and David Endler found a
stack overflow corruption problem in the file "Automatic File Content
Type Recognition Tool" version 3.41. Nalin Dahyabhai improved ELF section
and program header handling in file version 3.40. The folks at OpenPKG
believe that file versions without those modifications are vulnerable to
memory allocation and stack overflow problems which put security at risk. |
| Alerts: |
|
Comments (none posted)
GNU fileutils race condition
| Package(s): | fileutils ucdsnmp |
CVE #(s): | CAN-2002-0435
|
| Created: | May 20, 2002 |
Updated: | May 16, 2003 |
| Description: |
A race
condition in rm may cause the root user to delete the whole filesystem.
The problem exists in the version of rm in
fileutils
4.1 stable and 4.1.6 development version. A patch
is available.
(First LWN
report: May 2).
|
| Alerts: |
|
Comments (none posted)
Potential remote root exploit in glibc
| Package(s): | glibc |
CVE #(s): | CAN-2002-0391
|
| Created: | August 14, 2002 |
Updated: | June 29, 2003 |
| Description: |
Felix von Leitner, discovered a
potential division by zero bug in
code derived from the SunRPC library which is used in glibc.This bug could be
exploited to gain unauthorized root access to software linking to glibc.
Updating as soon as practical is a good idea.
Because SunRPC-derived XDR libraries are used by a variety of vendors in a variety of applications, this defect may lead to a number of differing security problems. Exploiting this vulnerability will lead to denial of service, execution of arbitrary code, or the disclosure of sensitive information.
CERT/CC Vulnerability Note VU#192995 Integer
overflow in xdr_array() function when deserializing the XDR stream
|
| Alerts: |
|
Comments (none posted)
glibc: DNS stub resolvers contain buffer overflow vulnerability
| Package(s): | glibc |
CVE #(s): | CAN-2002-1146
|
| Created: | November 7, 2002 |
Updated: | February 5, 2004 |
| Description: |
DNS stub resolvers from multiple vendors contain a buffer overflow
vulnerability. The impact of this vulnerability appears to be limited to
denial of service. (See CERT Vulnerability Note
VU#738331)
The BIND 4 and BIND 8.2.x stub resolver libraries, and other libraries such
as glibc 2.2.5 and earlier, libc, and libresolv, uses the maximum buffer
size instead of the actual size when processing a DNS response, which
causes the stub resolvers to read past the actual boundary ("read buffer
overflow"), allowing remote attackers to cause a denial of service
(crash).
|
| Alerts: |
|
Comments (none posted)
IMP - SQL injection vulnerability
| Package(s): | imp |
CVE #(s): | CAN-2003-0025
|
| Created: | January 15, 2003 |
Updated: | July 8, 2003 |
| Description: |
The IMP IMAP server, versions 2.2.8 and prior, is vulnerable to SQL
injection; see this advisory for details.
Version 3.x is not vulnerable to this problem. |
| Alerts: |
|
Comments (1 posted)
kernel - ptrace-related vulnerability
| Package(s): | kernel |
CVE #(s): | CAN-2003-0127
|
| Created: | March 17, 2003 |
Updated: | June 30, 2003 |
| Description: |
Versions 2.2.x and 2.4.x of the Linux kernel contain a vulnerability in
ptrace() which may be exploited by a local user to obtain root
access. This announcement contains the
details and a patch for 2.4.20. For 2.2 users, 2.2.25 has been released
which contains the fix. |
| Alerts: |
|
Comments (none posted)
kernel-utils: setuid vulnerability
| Package(s): | kernel-utils |
CVE #(s): | CAN-2003-0019
|
| Created: | February 7, 2003 |
Updated: | January 21, 2005 |
| Description: |
The kernel-utils package contains several utilities that can be used to
control the kernel or machine hardware. In Red Hat Linux 8.0 this package
contains user mode linux (UML) utilities.
The uml_net utility in kernel-utils packages with Red Hat Linux 8.0 was
incorrectly shipped setuid root. This could allow local users to control
certain network interfaces, add and remove arp entries and routes, and put
interfaces in and out of promiscuous mode.
All users of the kernel-utils package should update to these packages that
contain a version of uml_net that is not setuid root.
Alternatively, as a work-around to this vulnerability issue the following
command as root:
chmod -s /usr/bin/uml_net |
| Alerts: |
|
Comments (none posted)
libpng, libpng3: buffer overflow
| Package(s): | libpng, libpng3 |
CVE #(s): | CAN-2002-1363
|
| Created: | December 19, 2002 |
Updated: | July 14, 2004 |
| Description: |
Glenn Randers-Pehrson discovered a problem in connection with 16-bit
samples from libpng, an interface for reading and writing PNG
(Portable Network Graphics) format files. The starting offsets for
the loops are calculated incorrectly which causes a buffer overrun
beyond the beginning of the row buffer. |
| Alerts: |
|
Comments (none posted)
lprold - buffer overflow in lprm
| Package(s): | lprold lpd |
CVE #(s): | CAN-2003-0144
|
| Created: | March 13, 2003 |
Updated: | May 28, 2003 |
| Description: |
The lprm command of the printing package lprold contains a buffer
overflow. This buffer overflow can be exploited by a local user, if the
printer system is set up correctly, to gain root privileges. |
| Alerts: |
|
Comments (none posted)
lxr - input validation error
| Package(s): | lxr |
CVE #(s): | |
| Created: | March 19, 2003 |
Updated: | March 19, 2003 |
| Description: |
lxr fails to properly sanitize incoming filenames, with the result that an attacker can read arbitrary files on the system. |
| Alerts: |
|
Comments (none posted)
lynx: CRLF injection vulnerability
| Package(s): | lynx |
CVE #(s): | CAN-2002-1405
|
| Created: | November 19, 2002 |
Updated: | September 30, 2003 |
| Description: |
If lynx is given a url with some special characters on the command line, it
will include faked headers in the HTTP query. This feature can be used to
force scripts (that use Lynx for downloading files) to access the wrong
site on a web server with multiple virtual hosts.
CAN-2002-1405 |
| Alerts: |
|
Comments (none posted)
perl-MailTools: remote command execution
| Package(s): | MailTools |
CVE #(s): | CAN-2002-1271
|
| Created: | November 5, 2002 |
Updated: | September 19, 2003 |
| Description: |
The SuSE Security Team reviewed critical Perl modules, including the
Mail::Mailer package. This package contains a security hole which allows
remote attackers to execute arbitrary commands in certain circumstances.
This is due to the usage of mailx as default mailer which allows commands
to be embedded in the mail body.
Note that mail processing programs which use this package can be affected by this vulnerability; in particular, SpamAssassin is vulnerable if you use the -r or -w flags.
|
| Alerts: |
|
Comments (none posted)
man - code execution vulnerability
| Package(s): | man |
CVE #(s): | CAN-2003-0124
|
| Created: | March 19, 2003 |
Updated: | May 7, 2003 |
| Description: |
Versions of man prior to 1.51 contain a code execution vulnerability which can be exploited by a carefully crafted man file. See this advisory for the details. |
| Alerts: |
|
Comments (none posted)
micq: Denial of service
| Package(s): | micq |
CVE #(s): | |
| Created: | December 13, 2002 |
Updated: | April 24, 2003 |
| Description: |
Rüdiger Kuhlmann, upstream developer of mICQ, a text based ICQ client,
discovered a problem in mICQ. Receiving certain ICQ message types
that do not contain the required 0xFE seperator causes all versions to
crash. |
| Alerts: |
|
Comments (none posted)
MySQL: multiple vulnerabilities
| Package(s): | mysql |
CVE #(s): | |
| Created: | December 13, 2002 |
Updated: | April 10, 2003 |
| Description: |
The MySQL database server has several buffer overflow and integer bounds checking vulnerabilities which can lead to denial of service attacks, and, possibily, remote code execution. See this e-matters advisory for details. Version 3.23.54 fixes the problems. |
| Alerts: |
|
Comments (none posted)
mysql - configuration file vulnerability
| Package(s): | mysql mysqld |
CVE #(s): | CAN-2003-0150
|
| Created: | March 18, 2003 |
Updated: | May 16, 2003 |
| Description: |
According to a
report on BugTraq, a vulnerability exists in
version 3.23.55 and earlier versions of the MySQL server. If the MySQL server is
launched by root, as it is often done by system startup scripts, any
database users with the "FILE" privilege can write a configuration file
(usually my.cnf) that causes the MySQL server to run under an arbitrary
user id, including the user id of the super-user, on the next restart. |
| Alerts: |
|
Comments (none posted)
nethack: buffer overflow
| Package(s): | nethack, slashem, falconseye |
CVE #(s): | CAN-2003-0358
CAN-2003-0359
|
| Created: | February 18, 2003 |
Updated: | July 15, 2003 |
| Description: |
Overflowing a buffer in nethack may lead to privilege escalation to games
uid.
Read the the full advisory for the details.
Note that falconseye does not contain the file permission error
CAN-2003-0359 which affected some other nethack packages. |
| Alerts: |
|
Comments (none posted)
NetPBM: math overflow errors
| Package(s): | NetPBM |
CVE #(s): | CAN-2003-0146
|
| Created: | March 17, 2003 |
Updated: | May 27, 2003 |
| Description: |
Al Viro and Alan Cox discovered several maths overflow errors in
NetPBM, a set of graphics conversion tools. These programs are not
installed setuid root but are often installed to prepare data for
processing. These vulnerabilities may allow remote attackers to cause
a denial of service or execute arbitrary code. |
| Alerts: |
|
Comments (none posted)
netscape-flash: buffer overflow
| Package(s): | netscape-flash |
CVE #(s): | |
| Created: | March 10, 2003 |
Updated: | June 20, 2003 |
| Description: |
Potentially exploitable buffer overflows exist in the Macromedia Flash
Player. The full advisory is here.
"The cumulative security patch is available today and addresses the
potential for exploits surrounding buffer overflows (read/write) and
sandbox integrity within the player, which might allow malicious users to
gain access to a user's computer. The possibility of running native code on
a users machine is a theoretical exploit, and extremely difficult to
execute in practice. There are no known examples of running such native
code from Macromedia Flash movies; however, even though this issue is
difficult and theoretical in nature only, we are encouraging users to
upgrade." |
| Alerts: |
|
Comments (none posted)
net-snmp: denial of service vulnerability
| Package(s): | net-snmp |
CVE #(s): | CAN-2002-1170
|
| Created: | December 17, 2002 |
Updated: | November 7, 2003 |
| Description: |
The SNMP daemon included in the Net-SNMP package versions 5.0.1 through
5.0.4 can be caused to crash if it is sent a specially crafted packet. |
| Alerts: |
|
Comments (none posted)
openssl: local and remote extraction of RSA private key
| Package(s): | openssl, apache, mod_ssl |
CVE #(s): | CAN-2003-0147
|
| Created: | March 18, 2003 |
Updated: | May 22, 2003 |
| Description: |
David Brumley and Dan Boneh of Stanford University have researched and
documented a timing attack on OpenSSL which allows local and remote
attackers to extract the RSA private key of a server. The OpenSSL RSA
implementation is generally vulnerable to these type of attacks unless RSA
blinding has been turned on. See this
paper (pdf format) for additional details.
Typically, RSA blinding is not enabled by OpenSSL based applications,
mainly because it is not obvious how to do so when using OpenSSL to provide
SSL/TLS. This problem affects mostly all applications using OpenSSL and
have to be rebuilded against the fixed OpenSSL version (where RSA blinding
is now enabled by default) or have to enable RSA blinding explicitly their
own.
The performance impact of RSA blinding appears to be small (a few percent
only) and the RSA functionality is still fully compatible. The Common
Vulnerabilities and Exposures (CVE) project assigned the id
CAN-2003-0147 to the problem. |
| Alerts: |
|
Comments (none posted)
pam_xauth: root exploit
| Package(s): | pam_xauth |
CVE #(s): | CAN-2002-1160
|
| Created: | February 13, 2003 |
Updated: | July 10, 2003 |
| Description: |
The pam_xauth module is used to forward xauth information from user to user
in applications such as 'su'.
Andreas Beck discovered that versions of pam_xauth supplied with Red Hat
Linux since version 7.1 would forward authorization information from the
root account to unprivileged users. This could be used by a local attacker
to gain access to an administrator's X session. In order to exploit this
vulnerability, the attacker would have to get the administrator, as root,
to use su to the account belonging to the attacker. |
| Alerts: |
|
Comments (none posted)
PHP: vulnerability in mail function
| Package(s): | php |
CVE #(s): | CAN-2002-0985
CAN-2002-0986
|
| Created: | November 13, 2002 |
Updated: | September 30, 2003 |
| Description: |
Two vulnerabilities exists in the mail() PHP function. The first one allows
the execution of any program/script bypassing safe_mode restriction, the
second one may give an open-relay script if the mail() function is not
carefully used in PHP scripts. See this Bugtraq
report for more details. Note that this is a different vulnerability than the previous PHP mail() problem, which affected versions through 4.1.0.
CAN-2002-0985
CAN-2002-0986 |
| Alerts: |
|
Comments (none posted)
PostgreSQL - more buffer overflows
| Package(s): | postgresql |
CVE #(s): | |
| Created: | February 12, 2003 |
Updated: | November 7, 2003 |
| Description: |
A new set of buffer overflows has been discovered in PostgreSQL 7.2.2; they affect the circle_poly(), path_encode(), and path_addr() functions. Exploiting these overflows requires that the attacker first obtain a connection to the PostgreSQL server. |
| Alerts: |
|
Comments (1 posted)
Local arbitrary code execution vulnerability in Python
| Package(s): | python |
CVE #(s): | CAN-2002-1119
|
| Created: | August 28, 2002 |
Updated: | September 30, 2003 |
| Description: |
Zack Weinberg discovered that
os._execvpe from os.py uses a predictable name which could lead
to execution of arbitrary code. According to the Debian
advisory, the problem
was present in Python versions 1.5, 2.1 and 2.2.
CAN-2002-1119 |
| Alerts: |
|
