The Art of Unix Programming
Eric Raymond first
announced this
project back in 1999:
The Art of Unix Programming was to be a new
book, written with help from the community, that would "
attempt to
explain the Zenlike 'special transmission, outside the scriptures' that
distinguishes Unix gurus from ordinary mortals." More than three
years later,
a
draft of the book is available for review.
The Art of Unix Programming is certainly not a beginner's
programming manual. It assumes, instead, that the reader is already a
competent hacker and is looking to learn more about the Unix way of doing
things. So there is a lot of talk about philosophy and history, and a
wealth of case studies. There is a lot of language like:
As with Zen art, the simplicity of good Unix code depends on
exacting self-discipline and a high level of craft, neither of
which are necessarily apparent on casual inspection. Transparency
is hard work, but worth the effort for more than merely artistic
reasons. Unlike Zen art, software requires debugging - and usually
needs continuing maintenance, forward-porting, and adaptation
throughout its lifetime. Transparency is therefore more than an
esthetic triumph, but a victory that will be reflected in lower
costs throughout the software's lifecycle.
Eric would, seemingly, like his book to be seen as a successor to the
Kernighan and Plauger classics The Elements of Programming Style and
Software Tools. This book shows some of the classic Raymond traits:
no less than six case studies feature fetchmail (which he wrote), and the
examples demonstrating the fortune file format are all about the evils of
gun control.
But there is some good stuff in there which has not necessarily been
written down before. Eric is a good writer, and he has experience in the
realm he is writing about. The Art of Unix Programming is worth a
look.
We asked Eric a few questions about the draft release; here are his
answers.
LWN: If you could characterize the art of programming in/for Unix as
described in your book, in a single paragraph, how would you do it?
ESR:
I'll do better, I'll boil it down to a single phrase. Keep it simple, stupid!
The true art of programming -- and this is something Unix guys were
arguably the first to figure out and the most consistent at applying --
is minimizing global complexity. Most of the rest of the Unix philosophy
pretty much falls out of that.
LWN:
The draft as posted does not include any sort of licensing; will the final
version be available under a free license?
ESR:
Yes, but I haven't decided which one. There will be some restrictions
on print reproduction, but none on electronic.
LWN:
When you first announced the book project, it seemed you were planning to
put the chapters out gradually and make use of a lot of community input.
After chapter four, however (released almost exactly two years ago), things
went quiet, and the rest of the book, seemingly, was done in a "cathedral"
mode. Why is that? Did the more open approach not work out?
ESR:
No, it's just that I stalled out for a long time and then gave it six
weeks of intense work. This happened after an acquisitions editor at
Addison-Wesley called me and said "Uh. Apparently you had an
agreement to do a book with my predecessor, but I can't find a
contract." There wasn't one; I have a twitch that way, I don't sign a
contract until the book is essentially complete. He successfully
nudged me into working on it again.
LWN:
The book talks little about the programming of complex graphical
applications, and avoids the GNOME/KDE issue altogether. Yet one could
argue that complex applications are a big part of the future of Unix-like
systems. There is often, however, a sort of impedance mismatch between
fancy applications (think StarOffice 5) and the Unix way of doing things.
What suggestions do you have for authors of graphical applications to help
them carry forward the Unix tradition in the graphical world?
ESR:
Separate policy from mechanism, because policy ages much faster than
mechanism. Separate engines from interfaces, because tangling the two
together tends to lead to unmaintainable messes. Don't give it a GUI
if it doesn't need one.
Policy-mechanism separation is a major theme in the book. It's
usually thought of in connection with X, but it can be applied a lot
more widely -- and, in fact, Unix programmers *do* apply it a lot more
widely without being really aware of the principle consciously.
(Yes, that's right, I'm doing another yet another book that's
basically about conscious expression of unconscious folk practices.
This would be #3. Is there anybody left who still finds this
surprising? No? I thought not... :-))
One of the insights I got, one that's especially applicable to big
gnarly GUI applications, is that Unix programmers divide all Gaul into
three parts -- policy, mechanism, and glue. Mechanism is code that
tells how to do things, policy is code that tells what to do -- and glue
is the stuff that binds policy and mechanism together.
The punch line: glue is evil and must be destroyed, or at least minimized.
Your typical huge honkin' C++ application with classes stacked twelve
deep is an unmaintainable mess because the top two layers are policy,
the bottom two are mechanism, and the middle eight are glue. And the
trouble with glue is that it's opaque -- it impedes your ability to see
clear down through the system from the top, or clear up from the bottom.
You can't debug what you can't see through, because you can't form an
adequate mental model of its behavior.
So my advice to GUI programmers is this: Decide what's policy and
what's mechanism. Separate them cleanly -- ideally, have the GUI and
engine running in separate processes, like gv and ghostscript or
xcdroast and cdrecord. Then *ruthlessly eliminate all glue*. Or
as much of it as you can, anyway.
LWN:
There is very little treatment of security in the book. Why is that? Is,
in your mind, security peripheral to the main art of Unix programming, or
is something else going on?
ESR:
It's peripheral. This is not a book about system administration, it's
about how to design well. There's an aspect of that that has to do with
secirity of course, but most of the things that make for good security
(like minimizing code that has to be trusted) are just good engineering
practice. That I *do* talk about a lot.
LWN:
Unix has had a long run in the computing world, and, by all indications, it
has a while to go yet. All good things come to an end eventually,
however. What do you think might bring about the end of the Unix era, and
what might replace Unix in the future?
ESR:
My money is on capability-based persistent-object systems like EROS.
But prophecy is difficult, especially about the future.
Comments (24 posted)
Comparing free and proprietary software defect rates
[This article was contributed by Joe 'Zonker'
Brockmeier]
Tuesday a company called
Reasoning,
Inc. released a study that seems to prove what Open Source
developers have been saying for years: Open code, and the inspection
that it allows, produces a better product. Specifically, the company
compared the Linux TCP/IP stack against a number of commercial TCP/IP
stacks and found that the Linux implementation had fewer defects than
other proprietary implementations.
The paper, "How Open-Source and Commercial Software Compare" is
available from Reasoning by request, so we decided to take a look at it
to see how they had reached their conclusions.
Specifically, Reasoning lined up the Linux TCP/IP implementation from
the 2.4.19 Linux kernel against five commercial implementations. In
total, out of 81,852 lines of code, Reasoning found only 8 defects in
the Linux TCP/IP code. All but one of the other five implementations
compared with Linux were at least ten years old, the other is about
three years old. The company did not name the specific operating
systems, but Reasoning's CEO Scott Trappe confirmed that two were
commercial Unix systems, one was "not Unix but in very broad use," and
the embedded implementations were by "major vendors of networking
equipment." Trappe said that Reasoning couldn't name companies
specifically, but the companies had agreed to let Reasoning use the
aggregate data.
As always, it helps to understand the company doing the research, and
the context of the research, before taking the results too seriously. We
spoke with Trappe, to clarify some information not in the white paper
and to get a feel for Reasoning's background. Reasoning is a company
that specializes in automated testing of software written in C/C++,
which it has been doing since 2001. Prior to that, the company had
specialized in Y2K testing. The company plans to add testing of Java
software to its services later this year.
The study was not commissioned by any of the Linux vendors or companies
who might be competing with Linux. Instead, Trappe said that the company
had performed the study primarily to highlight its services. Unlike
the other projects that Reasoning works on, they were free to release
their results along with specific code examples from the Linux TCP/IP
stack. Trappe also said that the company was looking to prove that
inspection itself was important in providing quality software and that
"testing alone can never uncover all the defects in software."
The company chose the TCP/IP stack because it provided a good point of
comparison. Trappe admitted that it might be stretching it to draw too
many conclusions from the study of one piece of software, but that their
study "does support some claims that it can rival commercial quality."
Trappe also mentioned that the company may do further studies in the
future comparing Open Source software to commercial software.
The company looks for five kinds of defects in code: Memory leaks, null
pointer dereferences, bad deallocations, out of bounds array access and
uninitialized variables. According to Trappe, none of the errors found
in the Linux TCP/IP stack were security issues. At least one of the
issues, a memory leak, was fixed in the 2.4.20 kernel before Reasoning
notifed the kernel team of the defects. Four of the problems found (an
uninitialized variable and some out-of-bounds errors) are not
truly defects, since they do not cause the code to behave incorrectly.
So, of eight defects reported, four are not real, three are
debatable and one has been fixed.
When taking into account the revised information, the Linux TCP/IP stack
has a defect density of 0.013 per 1,000 lines of code. The
implementation with the fewest defects after Linux is one of the
embedded stacks, with .08 defects per 1,000 lines of code. One
implementation, one of the commercial OSes, had 183 defects out of about
269,100 lines of code - 0.7 per thousand.
To be sure, the Reasoning study raises some interesting points, though
there's not enough data to say conclusively that Open Source software is
always of higher quality than its proprietary counterparts. The study
looked only at one small piece of the Linux kernel, and only considered
a small set of information. The Linux kernel has also been extensively
checked for this sort of error by the Stanford checker and the new "smatch"
program, so it should be relatively clean.
Reasoning's study says nothing about
performance or features, and it does not address the
functionality of the code. However, it does supply some data in favor of
the argument that open code leads to higher quality -- at least in terms
of specific defects.
We'll be interested to see what kinds of studies Reasoning does in the
future, and how other Open Source projects compare to commercial code.
Comments (8 posted)
Lawrence Lessig wins FSF Award
The Free Software Foundation has
announced
that this year's winner of its Award for the Advancement of Free Software
is Lawrence Lessig - a fine choice. "
FSF President and founder,
Richard Stallman, presented the award
to Professor Lawrence Lessig for promoting understanding of the
political dimension of free software, including the idea that 'code is
law'."
Comments (1 posted)
Page editor: Jonathan Corbet
Security
Security news
Keeping Secrets
[This article was contributed by Tom Owen]
Information contained on hard drives is often of the type that should not
fall into the wrong hands. After all, being on the wrong end of a
Canadian class action lawsuit for releasing personal information
counts as one of the rougher server administrator nightmares.
It's not clear whether the Canadian disk drive was stolen or retired,
but it
doesn't look like an isolated case.
Responsible equipment dealers and recyclers
use special tools to sanitize disks that come into their hands.
But it doesn't always happen, and there's always the risk of simple theft.
Being sued is one possible outcome.
In Europe,
criminal charges are possible, though unlikely.
Even if all you have to worry about is an embarrassingly public gap between
your privacy policy
and your real operations, it may be time to look more closely
at what might emerge if your data partitions ended up on eBay.
The problem is that the ordinary techniques of host security are useless
against an explorer who can install your disks in a lab machine.
0600 modes won't be noticed by an attacker who is root already.
Wipes and sanitizers won't have been used if the equipment was stolen.
The only option is to encrypt the information you don't want to leak.
If you do it right you can publish the contents of your disks without a qualm.
Encryption is doubly important for Linux administrators because the range of
software is so great that failure to encrypt is that much less excusable.
The only plausible objections relate to performance and convenience issues.
In the past, the US imposed export restrictions on cryptographic software.
Those rules obliged Linux kernels from
kernel.org to
exclude cryptographic software.
Something like that never stops hackers,
and the kernel code for encrypted disks and networks was hosted
and has continued
outside the US. The 2.5 kernel has
crypto built in, but users of the current stable kernels must get their
encryption code from another source.
Incorporating crypto code into a standard kernel is
well
documented
but it's simpler to use a distribution like SuSE which includes crypto out of
the box.
Beyond the offerings from your distribution the broad choice is rather daunting.
The
standard approach
uses encryption in the loopback device to create
a secure partition "hosted" in a big contiguous file.
A filesystem can be created on that device and mounted as the data directory.
The host file is unintelligible without the passphrase.
Encrypted loopback can't handle swapfiles,
and so there's a risk of leaving decrypted application information on the disk.
If you can't configure enough memory,
ppdd,
which layers encryption on top of the plain loopback device
does support swap files.
Other
approaches
like CFS don't use loopback, instead running a userspace daemon to encrypt
on a file by file basis.
These suffer under I/O load and wouldn't be a good choice to host a database.
All of this is relatively well documented.
But the manuals seem to skate around the hard problems:
-
Passwords are hard to manage.
Changing the password involves backup and restore,
too much trouble to do often, so it has to be closely guarded.
Even worse, the passphrase can't be held anywhere on the machine,
so an unattended start isn't possible.
-
It's surprisingly tricky to backup encrypted data.
The loopback host file can be sensitive to absolute location on the disk,
and getting data securely off the machine requires more encryption.
It's unfortunate that the commonest server setup, remote hosting,
is one of the toughest operational security challenges.
But if remote servers are the only possible answer,
then encryption security is still possible.
Linux is solid enough that unattended restart isn't strictly necessary.
Instead, the machine can boot far enough to page the admin to ssh in and mount
the loopback devices.
And a backup can be prepared on the encrypted volume and
once it's
re-encrypted
with the admin's public key any transfer method will do.
This is all convoluted to say the least.
It's not standard, and it goes beyond what's commonly done.
It's easy to feel that keeping the site going and current is challenge enough.
But if you take privacy seriously there are no other choices.
Once your hosts are as secure as you can make them against attacks from
the network,
it's time to move up a level.
If you have other people's personal data,
you should probably encrypt it.
Comments (9 posted)
New vulnerabilities
hypermail - buffer overflows
| Package(s): | hypermail |
CVE #(s): | CAN-2003-0057
|
| Created: | February 11, 2003 |
Updated: | February 27, 2003 |
| Description: |
Ulf Harnhammar discovered two problems in hypermail, a program to
create HTML archives of mailing lists.
An attacker could craft a long filename for an attachment that would
overflow two buffers when a certain option for interactive use was
given, opening the possibility to inject arbitrary code. This code
would then be executed under the user id hypermail runs as, mostly as
a local user. Automatic and silent use of hypermail does not seem to
be affected.
The CGI program mail, which is not installed by the Debian package,
does a reverse look-up of the user's IP number and copies the
resulting hostname into a fixed-size buffer. A specially crafted DNS
reply could overflow this buffer, opening the program to an exploit. |
| 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)
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)
w3m - cross-site scripting vulnerabilities
| Package(s): | w3m |
CVE #(s): | CAN-2002-1335
CAN-2002-1348
|
| Created: | February 7, 2003 |
Updated: | February 18, 2003 |
| Description: |
w3m is a pager with Web browsing capabilities. Two cross-site scripting
(XSS) issues have been found in w3m.
An XSS vulnerability in w3m 0.3.2 allows remote attackers to insert
arbitrary HTML and web script into frames. Frames are disabled by default
in the version of w3m shipped with Red Hat Linux. Therefore, this problem
will not appear as long as users do not use w3m with the -F option, or
enable frame support in either the /etc/w3m/w3mconfig or ~/.w3m/config
configuration files. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2002-1335 to this issue.
An XSS vulnerability in versions of w3m before 0.3.2.2 allows attackers to
insert arbitrary HTML and web script into image attributes. The Common
Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name
CAN-2002-1348 to this issue |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
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)
BIND8: Multiple vulnerabilities
Comments (1 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)
bladeenc - improper input verification
| Package(s): | bladeenc |
CVE #(s): | |
| Created: | February 5, 2003 |
Updated: | February 5, 2003 |
| Description: |
Versions 0.94.2 (and prior) of the Blade MP3 encoder contain an input validation vulnerability which can lead to arbitrary code execution; see this advisory for details. |
| 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)
courier - missing input sanitizing
| Package(s): | courier |
CVE #(s): | CAN-2003-0040
|
| Created: | January 30, 2003 |
Updated: | February 5, 2003 |
| Description: |
The developers of courier, an integrated user side mail server, discovered
a problem in the PostgreSQL auth module. Not all potentially malicious
characters were sanitized before the username was passed to the PostgreSQL
engine. An attacker could inject arbitrary SQL commands and queries
exploiting this vulnerability. The MySQL auth module is not affected. |
| Alerts: |
|
Comments (none posted)
cups - multiple vulnerabilities
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)
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)
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)
IM: creates temporary files insecurely
| Package(s): | im |
CVE #(s): | CAN-2002-1395
|
| Created: | December 3, 2002 |
Updated: | March 6, 2003 |
| Description: |
Tatsuya Kinoshita discovered that IM, which contains interface
commands and Perl libraries for E-mail and NetNews, creates temporary
files insecurely.
- The impwagent program creates a temporary directory in an insecure
manner in /tmp using predictable directory names without checking
the return code of mkdir, so it's possible to seize a permission
of the temporary directory by local access as another user.
- The immknmz program creates a temporary file in an insecure manner
in /tmp using a predictable filename, so an attacker with local
access can easily create and overwrite files as another user.
|
| 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)
KDE - command parameter quoting problems
| Package(s): | kde |
CVE #(s): | CAN-2002-1393
|
| Created: | December 23, 2002 |
Updated: | February 21, 2003 |
| Description: |
In some instances, KDE (versions 2 and 3) fails to properly quote parameters of instructions
passed to a command shell for execution.
These parameters may incorporate data such as URLs, filenames and e-mail
addresses, and this data may be provided remotely to a victim in an e-mail,
a webpage or files on a network filesystem or other untrusted source.
By carefully crafting such data an attacker might be able to execute
arbitary commands on a vulnerable sytem using the victim's account and
privileges.
See this announcement for more details. |
| Alerts: |
|
Comments (none posted)
kdelibs: Vulnerabilities in KIO subsystem support
| Package(s): | kdelibs |
CVE #(s): | CAN-2002-1281
CAN-2002-1282
|
| Created: | November 22, 2002 |
Updated: | March 14, 2003 |
| Description: |
Vulnerabilities were discovered in the KIO subsystem support for various
network protocols. The implementation of the rlogin protocol affects all
KDE versions from 2.1 up to 3.0.4, while the flawed implementation of the
telnet protocol only affects KDE 2.x. They allow a carefully crafted URL
in an HTML page, HTML email, or other KIO-enabled application to execute
arbitrary commands as the victim with their privilege.
The KDE team provided a patch for KDE3 which has been applied in these
packages. No patch was provided for KDE2, however the KDE team recommends
disabling both the rlogin and telnet KIO protocols. This can be
accomplished by removing, as root, the following files:
/usr/share/services/telnet.protocol and
/usr/share/services/rlogin.protocol.
If either file also exists in a user's ~/.kde/share/services directory,
they should likewise be removed.
See also:
http://www.kde.org/info/security/advisory-20021111-1.txt |
| Alerts: |
|
Comments (none posted)
kernel: local denial of service vulnerability
| Package(s): | kernel |
CVE #(s): | |
| Created: | November 19, 2002 |
Updated: | February 5, 2003 |
| Description: |
All versions of the Linux kernel from (at least) 2.2.x through 2.4.19 and
2.5.47 contain a vulnerability which allows any local user to crash the
system. This LWN article describes how the
exploit works in detail. The vulnerability affects only x86 systems. |
| Alerts: |
|
Comments (none posted)
kernel - Multiple vulnerabilities in version 2.4.18 of the kernel
| Package(s): | kernel |
CVE #(s): | CAN-2003-0001
CAN-2003-0018
|
| Created: | February 4, 2003 |
Updated: | February 5, 2003 |
| Description: |
Vulnerabilities have been found in version 2.4.18 of the kernel.
Multiple ethernet Network Interface Card (NIC) device drivers do not pad
frames with null bytes, which allows remote attackers to obtain information
from previous packets or kernel memory by using malformed packets. The
Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned
the name CAN-2003-0001 to this issue.
A vulnerability exists in O_DIRECT handling in Linux kernels 2.4.10 and
later that can create a limited information leak where any user on the
system with write privileges to a file system can read information from
that file system (from previously deleted files), and can create minor file
system corruption (easily repaired by fsck). Red Hat Linux in its default
configuration is not affected by this bug, because the ext3 file system
(the default file system in Red Hat Linux 7.2 and later) does not support
the O_DIRECT feature. Of the kernels Red Hat has released, only the 2.4.18
kernels have this bug. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2003-0018 to this issue. |
| Alerts: |
|
Comments (none posted)
krb5 - vulnerability in Kerberos ftp client
| Package(s): | krb5 ftp netkit |
CVE #(s): | CAN-2003-0041
|
| Created: | January 31, 2003 |
Updated: | February 21, 2003 |
| Description: |
Kerberos is a network authentication system.
A problem has been found in the Kerberos ftp client. When retrieving a
file with a filename beginning with a pipe character, the ftp client will
pass the filename to the command shell in a system() call. This could
allow a malicious ftp server to write to files outside of the current
directory or execute commands as the user running the ftp client.
The Kerberos ftp client runs as the default ftp client when the Kerberos
package krb5-workstation is installed on a Red Hat Linux distribution. |
| Alerts: |
|
Comments (none posted)
libmcrypt: buffer overflows and memory exhaustion
| Package(s): | libmcrypt |
CVE #(s): | CAN-2003-0031
CAN-2003-0032
|
| Created: | January 6, 2003 |
Updated: | February 27, 2003 |
| Description: |
libmcrypt versions prior to 2.5.5 contain a number of buffer overflow
vulnerabilities that stem from improper or lacking input validation. By
passing a longer than expected input to a number of functions (multiple
functions are affected) the user can successful make libmcrypt crash.
Another vulnerability is due to the way libmcrypt loads algorithms via
libtool. When the algorithms are loaded dynamically the each time the
algorithm is loaded a small (few kilobytes) of memory are leaked. In a
persistant enviroment (web server) this could lead to a memory exhaustion
attack that will exhaust all avaliable memory by launching repeated
requests at an application utilizing the mcrypt library. |
| 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)
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)
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)
PHP Remote Compromise/DOS Vulnerability
| Package(s): | mod_php4 |
CVE #(s): | |
| Created: | July 22, 2002 |
Updated: | February 18, 2003 |
| Description: |
PHP 4.2.0 and 4.2.1 have an error in the handling of POST requests which
can lead to the corruption of memory, and the usual bad consequences. According to this alert, the vulnerability can only be used for denial of service on x86 systems - there is no way to get it to run exploit code. SPARC/Solaris systems are apparently vulnerable to full remote compromise.
According to the CERT Advisory,
almost every Linux distributor, it seems, ships older (and thus not vulnerable) versions of PHP.
Note that, sometimes, systems thought to be safe from remote compromise turn out to be vulnerable to a modified attack, so x86 users should not relax too much. The solution, for those systems with PHP
4.2.0 or 4.2.1 installed,
is to upgrade to PHP 4.2.2.
For more information see the alert from
the discover of the vulnerability, Stefan Esser of e-matters GmbH,
or the security
advisory from the php team.
CERT Advisory: CA-2002-21 Vulnerability in PHP |
| Alerts: |
|
Comments (1 posted)
mod_php - buffer overflow
| Package(s): | mod_php php |
CVE #(s): | CAN-2002-1396
|
| Created: | January 13, 2003 |
Updated: | February 20, 2003 |
| Description: |
The wordwrap() function on user-supplied input may allow a
specially-crafted input to overflow the allocated buffer and overwrite the
heap. There are no known exploits, but an exploit is theoretically possible.
Read the full advisory at
http://marc.theaimsgroup.com/?l=bugtraq&m=104102689503192&w=2 |
| Alerts: |
|
Comments (none posted)
Mozilla: Privacy leak and other vulnerabilities
| Package(s): | mozilla |
CVE #(s): | CAN-2002-1126
CAN-2002-1091
|
| Created: | November 1, 2002 |
Updated: | February 13, 2003 |
| Description: |
Mozilla 1.1 and earlier, and Mozilla-based browsers such as Netscape and
Galeon, set the document referrer too quickly in certain situations when a
new page is being loaded, which allows web pages to determine the next page
that is being visited, including manually entered URLs.
Netscape 6.2.3 and earlier, and Mozilla 1.0.1, allow remote attackers to
corrupt heap memory and execute arbitrary code via a GIF image with a zero
width.
See also Mozilla's
Recently fixed security issues page.
All users are encouraged to upgrade to this latest stable 1.0.x release of
Mozilla. |
| Alerts: |
|
Comments (none posted)
MySQL - double free vulnerability
| Package(s): | mysql |
CVE #(s): | CAN-2003-0073
|
| Created: | January 29, 2003 |
Updated: | February 21, 2003 |
| Description: |
MySQL 3.23.55 fixes a double-free vulnerability which allows a hostile
client to crash the server process. Logging into the server is necessary
before this vulnerability can be exploited. |
| 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)
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)
OpenLDAP2: remote command execution
| Package(s): | OpenLDAP2 |
CVE #(s): | CAN-2002-1378
CAN-2002-1379
|
| Created: | December 6, 2002 |
Updated: | February 21, 2003 |
| Description: |
OpenLDAP is the Open Source implementation of the Lightweight Directory
Access Protocol (LDAP) and is used in network environments for distributing
certain information such as X.509 certificates or login information.
The SuSE Security Team reviewed critical parts of that package and found
several buffer overflows and other bugs remote attackers could exploit to
gain access on systems running vulnerable LDAP servers. In addition to
these bugs, various local exploitable bugs within the OpenLDAP2 libraries
(openldap2-devel package) have been fixed.
Since there is no workaround possible except shutting down the LDAP server,
an update is strongly recommended. |
| Alerts: |
|
Comments (1 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)
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: |
|
Comments (none posted)
qt-dcgui: file leaking
| Package(s): | qt-dcgui |
CVE #(s): | |
| Created: | February 4, 2003 |
Updated: | February 5, 2003 |
| Description: |
All versions of qt-dcqui prior to 0.2.2 have a major security vulnerability
in the directory parser. This bug allows a remote attacker to download
files outside the sharelist. It's recommended that you upgrade the
packages immediatly.
Read the full announcment at:
http://dc.ketelhot.de/pipermail/dc/2003-January/000094.html |
| Alerts: |
|
Comments (none posted)
Multiple-use vulnerability in Safe.pm
| Package(s): | Safe.pm |
CVE #(s): | CAN-2002-1323
|
| Created: | October 9, 2002 |
Updated: | February 20, 2004 |
| Description: |
usePerl has a
description of a vulnerability in the Safe.pm Perl module. It seems
that if a Safe compartment is used more than once, it ceases to be safe.
The problem is fixed in Safe 2.08. |
| Alerts: |
|
Comments (none posted)
slocate - buffer overflow
| Package(s): | slocate |
CVE #(s): | CAN-2003-0056
|
| Created: | February 5, 2003 |
Updated: | May 8, 2003 |
| Description: |
version 2.6 (at least) of slocate contains a buffer overflow vulnerability which could lead to a local exploit; see this advisory for the details.
|
| Alerts: |
|
Comments (none posted)
File overwrite vulnerability in tar and unzip
| Package(s): | tar unzip |
CVE #(s): | CAN-2001-1267
CAN-2001-1268
CAN-2001-1269
CAN-2002-0399
|
| Created: | October 1, 2002 |
Updated: | April 9, 2006 |
| Description: |
The tar utility does not properly filter file names containing
"../", meaning that a hostile archive can, if unpacked by an
unsuspecting user, overwrite any file that is writable by that user. GNU
tar versions 1.13.19 and earlier are vulnerable; unzip through version 5.42
has the same vulnerability. |
| Alerts: |
|
Comments (1 posted)
Multiple vendor telnetd vulnerability
| Package(s): | telnet Telnet netkit-telnet-ssl kerberos telnetd netkit-telnet nkitb/nkitserv/telnetd krb5 |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | October 5, 2004 |
| Description: |
This vulnerability,
originally thought to be confined to BSD-derived systems, was first covered
in the July 26th Security
Summary. It is now known that Linux telnet daemons are vulnerable as
well.
|
| Alerts: |
|
