LinkSys and binary modules
In response to pressure from the Free Software Foundation and the
community, LinkSys has made a new tarball available containing the source
for the firmware running in its WRT56G wireless router. This new source
distribution (
available
here; get the 1.41.2 version) contains a good deal of new code,
including the modifications to the kernel to support the Broadcom 4702
processor. Many of those who have been pursuing
this particular GPL violation case are now satisfied.
The celebration is not universal, however; the new kernel source still
lacks the driver for the wireless interface. Unlike the other kernel
modifications found in the WRT54G router, the wireless interface is
packaged as a separate, binary module. In the eyes of many, that packaging
is sufficient to ensure that the driver is not a derived product of the
kernel, and, thus, it need not be licensed under the GPL. But not
everybody agrees.
The status of binary modules remains the subject of a great deal of confusion;
it deserves (yet another) look. There is a widespread impression that
Linus Torvalds has issued a blanket exemption to the GPL for closed-source
modules. There are only two problems with this idea: (1) it is not
entirely true, and (2) the relevance of Linus's opinion is limited.
On the first point, consider this pronouncement
from Linus, issued almost exactly one year ago:
There is NOTHING in the kernel license that allows modules to be
non-GPL'd. The _only_ thing that allows for non-GPL modules is
copyright law, and in particular the "derived work" issue. A vendor
who distributes non-GPL modules is _not_ protected by the module
interface per se, and should feel very confident that they can show
in a court of law that the code is not derived.
On the second point, it suffices to remember that Linus is far from the
only kernel copyright holder. He made a crucial decision years ago to not
require
copyright assignments from contributors, and, thus, to allow each
contributor to retain copyrights on his or her code. As Linus's role has
shifted from coding to rejecting contributions from others, the portion of
the kernel code base carrying his copyright has shrunk. Linus can speak
for himself, but not for the other kernel copyright holders. And some of
the others are getting increasingly grumpy about closed-source modules.
The crucial question here is whether a court would find that a kernel
module is a derived product of the kernel itself or not. There is a
difference of opinion on that score, to say the least. Eight years ago,
Linus suggested
that kernel modules, by virtue of the module API which only allowed
modules to link to "logically independent" functions within the kernel,
were not derived products. As
others have pointed out, the list of
functions available to modules is rather less controlled these days. 2.6
loadable modules have access to a great many kernel functions (a quick
grep turns up over 8000 exported symbols) and require a great deal of inline
code from the kernel header files. By some accounts, any code that is so
intimately tied into the kernel must be a derived product.
Others have taken the view that anything which can be
unplugged and replaced is not a derived product. The existence of a
plug-in interface creates a boundary which the GPL cannot cross.
In some cases, this must
be true; consider, for example, Linuxant's controversial new DriverLoader product. DriverLoader is a
proprietary module which will interface Windows NDIS network drivers to the
Linux kernel. The legal status of DriverLoader may be unclear, but nobody
would argue that a binary Windows driver, when shoehorned into the Linux kernel in
this way, becomes a derived product of the kernel. On the other hand, with
a small (GPL-licensed) patch, the kernel could be opened to "pluggable"
modules implementing proprietary network protocols, memory managers,
schedulers, etc. This scheme, if considered legal, would allow proprietary
code to be lodged within the heart of the Linux kernel. At that point,
there would be no restriction on derived products at all.
Another view, less often heard, notes that the kernel module loader checks
the license of every module loaded into the system. If the module lacks a
free license, the kernel complains, but loads the module anyway. One could
argue that this behavior is an explicit acknowledgment that closed-source
modules are permissible.
The only way to get a definitive answer on the location of the GPL boundary
will be to go in front of a judge. Even then, the answer is unlikely to be
useful beyond the specific case considered there.
In the LinkSys case, some developers are claiming that the source for the
binary modules should be released even if they are not strictly seen to be
derived products. This claim is based on the following language from
section 2 of the General Public License:
If identifiable sections of that work are not derived from the
Program, and can be reasonably considered independent and separate
works in themselves, then this License, and its terms, do not apply
to those sections when you distribute them as separate works. But
when you distribute the same sections as part of a whole which is a
work based on the Program, the distribution of the whole must be on
the terms of this License, whose permissions for other licensees
extend to the entire whole, and thus to each and every part
regardless of who wrote it.
Some feel that the LinkSys WRT56G router is, indeed, a "whole which is a
work based on the Program" and that the entire system must be licensed
under the GPL if it is to be distributed legally. This view relies on the
contract
provisions of the GPL, and not just on copyright law; it is controversial,
to say the least. By this reasoning, a Linux distribution with, say, a
proprietary installer could be seen to be violating the GPL. In the end,
this claim, too, can only be verified in a courtroom. Until then, the
definition of a "whole" is subject to debate.
The status of closed-source modules has always been somewhat unclear, and
one gets the impression that the kernel developers have been happy to keep
it that way. There is a strong desire to discourage such modules, but,
seemingly, little wish to abolish them altogether. The system has worked
reasonably well so far, but it may well be asking for trouble in the longer
term. With the current state of affairs, it seems certain that, sooner or
later, a company or individual holding kernel copyrights will take a
proprietary module vendor to court.
One of the best features of free software is the fact that users don't need
to worry. The rights of users are broad and well defined;
there is no equivalent of the Business Software Alliance looking for
companies to raid. The distribution of closed-source kernel modules is an
exception, however; nobody really knows if this distribution is legal or
not. The free software community is not helped by this uncertainty; it
really is past time to clarify the status of closed-source modules. Doing
so will be a challenging task, but doing nothing will bring unwanted
challenges of its own.
The free software community does not need any more litigation, be it
instigated by ourselves or by others.
Comments (30 posted)
Two views of the Unix philosophy
We have recently received two books, both of which attempt to set down the
Unix philosophy. This philosophy is said to underlie the work we all do
with Linux, so discussions of it are worth a look. Maybe we can finally
find out what we have been trying to do all these years.
The first is The Art of Unix Programming by Eric Raymond (published
by Addison Wesley). We have
discussed this book before on these pages,
so a detailed look is not necessary at this time. Suffice to say that
Eric's book is now available in the stores. It is also available on the
net under a relatively restrictive Creative Commons license.
The other entry is Linux and the Unix Philosophy by Mike Gancarz,
published by Digital Press. This book appears to be a fairly
straightforward remake of Mr. Gancarz's The Unix Philosophy,
published in 1994. References to Linux have been retrofitted in, but the
book is little changed. If the underlying Unix philosophy is as enduring
as these books would have us believe, a book from 1994 should still be
current now. Unfortunately, Linux and the Unix Philosophy looks
old; consider, for example, the author's advice that a function's parameter
list should fit on a single line of an (80-column) screen. That might have
been good advice for an old-style C function, but, in the modern world,
where parameter names and types all go together, even a very short
parameter list can take multiple lines.
This book also ignores many of the features of modern Unix/Linux
programming, including scripting languages (beyond the shell) and graphical
interfaces. In Mr. Gancarz's view, all programs are small, and their
functions are minimal; he even states that multi-column output has bloated
the ls command excessively. Or consider:
Why has the metric of MIPS become such a hot issue in the computer
world today? Because as Unix usage has become more prevalent, the
use of small programs has proliferated as well. Small programs,
although they usurp little system memory when executing, derive the
most benefit from the injection of additional CPU horsepower.
This discussion does not fit your editor's world, where the best way to
improve the performance of a system is often to add memory.
The most interesting area of investigation, however, would be how the two
books characterize the Unix philosophy. Happily, both of them provide nice
sets of rules suitable for slides in any executive briefing - or a summary
table in LWN. So, without further ado...
| The Art of Unix Programming |
Linux and the Unix Philosophy |
|
Write a big program only when it is clear by demonstration that
nothing else will do.
|
Small is beautiful.
|
|
Design for simplicity; add complexity only where you must.
|
Make each program do one thing well.
|
|
Prototype before polishing. Get it working before you optimize
it.
|
Build a prototype as soon as possible.
|
|
(No rule, but portability is listed as one of the things Unix got
right).
|
Chose portability over efficiency.
|
|
Design programs to be connected with other programs.
|
Store data in flat text files.
Make every program a filter
|
|
Avoid hand-hacking; write programs to write programs when you can.
|
Use software leverage to your advantage. [i.e. reuse code].
|
|
Programmer time is expensive; conserve it in preference to machine
time.
|
Use shell scripts to increase leverage and portability.
|
|
In interface design, always do the least surprising thing.
|
Avoid captive user interfaces.
|
|
When a program has nothing to say, it should say nothing.
|
Silence is Golden
|
|
|
Look for the 90-percent solution.
Worse is better.
|
|
Design for visibility to make inspection and debugging easier.
|
|
|
Fold knowledge into data so program logic can be stupid and robust.
|
|
|
Repair what you can, but when you must fail, fail noisily and as
soon as possible.
|
|
|
Separate policy from mechanism; separate interfaces from engines.
|
|
|
Distrust all claims for the "one true way."
|
|
The further expression of these rules shows the relative age and limited
scope of Gancarz's book. He talks about flat text files, while Raymond
discusses the importance of transparent, textual network protocols as
well. Raymond covers the network, modern languages, and the ups and downs
of programming techniques as an integral part of his book; Gancarz has a
brief "Brave New World" chapter at the end where he treats bleeding-edge technologies
like the Internet, artificial intelligence, object-oriented programming,
and Java.
On the other side, Eric Raymond's tendencies are well known. The Art of
Unix Programming can be verbose and gives a lot of coverage to
Mr. Raymond's own work and beliefs. Most people would have found a way to
write a Unix book without including quotes from famous people on the evils
of gun control, for example.
Both books neglect areas of great concern for any contemporary software
developer. Neither will give as much help as the implementer of a web
browser, office suite, or DVD player might like. No developer can afford
to be
unaware of security issues in the current environment, but neither author
devotes any space to security. What is the Unix philosophy's
approach to security? Silence in response to that question is all too
telling.
In the end, if your editor had to choose between the two books, he would go
with The Art of Unix Programming, though both have their merits.
Readers of either would be well advised to heed Mr. Raymond's last rule,
however: distrust anybody who claims to know the "one true way."
Comments (5 posted)
Background on Citizens Against
Government Waste
After
Citizens Against Government
Waste (CAGW) issued a
strongly-worded
press release against the state of Massachusetts's
initiative
to move toward open systems, we at LWN decided to take a longer look at
this organization's background and see why they might exhibit such
hostility toward open source.
According to CAGW's website, the group has been in operation since 1984.
It is, according to its press materials "a private, non-partisan,
non-profit organization" on a mission to eliminate "waste,
mismanagement, and inefficiency in the federal government." It claims to
be "nationally recognized as the source of information on
government waste," with more than one million members.
Apparently, Microsoft has
been one of the corporate donors that provided funding to CAGW in the
past. But the group prefers to remain mum on
whether Microsoft continues to fund them and what other groups may
be providing funding.
We contacted CAGW directly to find out whether Microsoft is still
donating money, and how they came to form their opinions on open source
use in government. We spoke to CAGW President Tom Schatz, who also
declined to specify whether CAGW is still receiving money from Microsoft
and said that interested parties could examine CAGW's IRS 990 filing.
CAGW is required to make this document available upon request, but is not
required to provide the names of its donors.
We located CAGW's filings for 2000 and 2001 online, but the donor information had been whited out. According to CAGW's website, about 85 percent of the organization's funding comes from individual contributors, with the remaining 15 percent coming from corporate and foundation gifts. In 2001, three contributors donated a total of $490,765 to CAGW, accounting for only 10 percent of the non-profit group's entire income of $4,898,720 for the year. In 2000, CAGW brought in $4,846,934 with a single anonymous donor of $150,000. If Microsoft or one of the foundations it supports is still a contributor to CAGW, the contributions are only a minor percentage of overall contributions.
To be sure, CAGW does not exist solely as an apologist or mouthpiece for
Microsoft. The organization tracks government spending in many areas
unrelated to the software industry, and provides ratings for members of congress, according to their criteria of eliminating government waste.
However, the group has been unrelenting in its opposition
to the governments' antitrust suit against Microsoft, and was part of the
"grass-roots" effort to stir up public support against the suit. The group
made headlines after some of their form letters were mailed in by CAGW
members who had
died.
Citizens Against Government Waste, on the other hand, distributed
identical letters to citizens. Those varied only by the signature
attached. The two letters from beyond the grave came from the Citizens
Against Government Waste crop. According to the Times, family members
crossed out the names and signed for them. Another letter was sent from
"Tuscon, Utah," a city that doesn't even exist.
When news hit the wires late last month that Massachusetts may be
favoring open source, CAGW was quick to oppose the idea -- apparently
without bothering to get all the facts on the issue first. Schatz admitted
that he later found that, contrary to the position stated in
the release, Massachusetts was not barring proprietary vendors
from competing for state contracts. Schatz says he will issue a second
release with a correction "if something does come out in writing from the
state...we've seen quotes, but nothing in writing."
We asked Schatz if he opposes open source software in government, and he
replied that he was not opposed to open source software but was opposed
to a policy that prefers or requires single-sourcing.
We have been fairly consistent with support for the concept of
dual-sourcing a piece of equipment...the state needs to consider what
the best product is, what's going to operate most efficiently.
We also asked Schatz about the communist rhetoric contained in their
"Mass. Taxpayers Hurt by Proposed Software Monopoly" release. Schatz
denied that comparisons of Massachusetts' open source policy were
designed to tie in with other comparisons of open source and free
software to communism or socialism.
If you read any of our stuff... take a look at our porker of the month,
we're just as strong in our language... I may choose my words more
carefully next time. We're trying to raise an government issue, not an
issue with how people see the world. Communism won't be part of the next
press release.
Schatz also mentioned that CAGW group received a number of e-mails from
the Linux community on the topic, and had discovered that the community
does not appreciate comparisons to communism or socialism. He also noted
that CAGW receives strong reactions to many of their releases, not just
those on the topic of Linux or open source. A cursory search of CAGW's
website did not turn up references to socialism or communism as
metaphors for other government waste. The reader can judge for
themselves whether the tone in other CAGW releases is similar to the
tone of the "Proposed Software Monopoly" release.
It may be that CAGW is poorly informed on the benefits of open source,
and too easily swayed by pro-Microsoft studies. Schatz acknowledged that
CAGW had not performed any studies independently to determine the cost
benefits of open source products versus proprietary software.
We honestly don't have the expertise here to fight the studies, or to
make our own, we rely on things that are out there...since open source
is newer for government experience, we should probably wait and see how
it works and what the expenses are on the other side.
It's clear that CAGW carries a substantial amount of influence with a
widespread public audience, and with elected officials. Open source
advocates would do well to keep tabs on future pronouncements from the
group, and to work toward politely educating CAGW on the benefits of
free software and the unnecessary waste of government funds on proprietary
software.
Comments (7 posted)
Page editor: Jonathan Corbet
Security
Open spam filtering rules considered harmful?
Readers of LWN know that we have long been a fan of
SpamAssassin. Your editor, whose
personal spam load is approaching 500 messages per day, would long have
ceased to function without it. Network life in the 21st century requires
either a well-hidden email address, or some sort of effective filtering.
SpamAssassin's extensive arsenal of tests has
traditionally included checks for legitimate mail. In the past, mail which
identified itself as having been created with certain free email agents or
which contained a software patch was given some extra credit in the scoring
process. Spammers have often found and exploited those tests; for a while,
some of us were receiving mail which had been simultaneously "created" with
mutt and evolution. The usual response to such activity has been to remove
the tests in question.
Most recently, some spammers have started adding fake PGP signatures (in
full HTML glory) to their output, in the hopes of slipping past
SpamAssassin. The PGP signature test was removed some time ago, but the
exploit was still enough to inspire this News.com article
which, among other things, says:
The attack on the software's filtering process highlights the
dangers of open-source projects, but it also reinforces the ability
of projects with active development teams to quickly respond to
such security holes.
The open nature of SpamAssassin's filtering is, thus, a "danger." Lest one
become too concerned about the "dangers" involved in using SpamAssassin,
however, there are a few things which should be kept in mind:
- Prospective spam can be tested against any filter, open or closed.
It would be surprising if spammers were not trying their products
against SpamAssassin in this way. They also, most likely, maintain
accounts with large ISPs and try to craft messages that get past the
filters those ISPs employ as well.
- SpamAssassin remains highly effective, even when spammers have had
plenty of time to study its tests and work out ways to get around it.
Open or not, SpamAssassin's rules are very good at identifying spam,
and they appear to be hard to get around. Fighting spam is an arms
race; it is surprising, actually, how rarely one has to upgrade
SpamAssassin to keep it effective.
- The bayesian filtering techniques used by SpamAssassin (and many other
spam filtering systems) cannot be worked around in any easy way. A
quick test on about 6400 messages which had accumulated in your
editor's spam folder shows that the bayesian filter is the decisive
test which condemns 15-25% of all incoming spam. Bayesian filters are
highly individualized, and they are inaccessible to spammers. The
algorithm is entirely open, but that is little comfort to those who
would bury us in unwanted trash.
The real lesson from the PGP signature "exploit," most likely, is that
negative tests will always be relatively easy for spammers to abuse. That
will be why SpamAssassin 2.60 contains almost none of these tests.
The most important point, however, is entirely different. For many of us,
email is a vital connection to the world. It is natural to be concerned
about trusting a program to filter our incoming mail for us; mistakes can
have real consequences. Would you really want to trust your mail to a
hidden, proprietary filtering scheme? Don't you want to know what
assumptions and biases have gone into the filtering decisions? Or, at
least, don't you want that information to be available to those with the
time and interest to check it out?
Allowing a black box to pass
judgment on one's incoming mail stream poses more dangers than an open,
free system ever could.
Comments (19 posted)
New vulnerabilities
glibc - buffer overflow
| Package(s): | glibc |
CVE #(s): | CAN-2003-0689
|
| Created: | October 15, 2003 |
Updated: | November 25, 2003 |
| Description: |
The GNU C library contains a buffer overflow in the getgrouplist() function. If the user belongs to more groups than the calling application expects, the allocated storage will be overrun. |
| Alerts: |
|
Comments (none posted)
tomcat4: denial of service vulnerability
| Package(s): | tomcat |
CVE #(s): | |
| Created: | October 15, 2003 |
Updated: | October 15, 2003 |
| Description: |
Aldrin Martoq has discovered a denial of service (DoS) vulnerability in
Apache Tomcat 4.0.x. Sending several non-HTTP requests to Tomcat's HTTP
connector makes Tomcat reject further requests on this port until it is
restarted. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
2.4 kernel - several vulnerabilities
| Package(s): | 2.4 kernel |
CVE #(s): | CAN-2003-0461
CAN-2003-0462
CAN-2003-0464
CAN-2003-0476
CAN-2003-0501
CAN-2003-0550
CAN-2003-0551
CAN-2003-0552
|
| Created: | July 21, 2003 |
Updated: | December 23, 2003 |
| Description: |
Several security issues have been discovered affecting the Linux kernel:
-
CAN-2003-0461: /proc/tty/driver/serial reveals the exact character
counts for serial links. This could be used by a local attacker to infer
password lengths and inter-keystroke timings during password entry.
-
CAN-2003-0462: Paul Starzetz discovered a file read race condition
existing in the execve() system call, which could cause a local crash.
-
CAN-2003-0464: A recent change in the RPC code set the reuse flag on
newly-created sockets. Olaf Kirch noticed that his could allow normal
users to bind to UDP ports used for services such as nfsd.
-
CAN-2003-0476: The execve system call in Linux 2.4.x records the file
descriptor of the executable process in the file table of the calling
process, allowing local users to gain read access to restricted file
descriptors.
-
CAN-2003-0501: The /proc filesystem in Linux allows local users to
obtain sensitive information by opening various entries in /proc/self
before executing a setuid program. This causes the program to fail to
change the ownership and permissions of already opened entries.
-
CAN-2003-0550: The STP protocol is known to have no security, which
could allow attackers to alter the bridge topology. STP is now turned
off by default.
-
CAN-2003-0551: STP input processing was lax in its length checking,
which could lead to a denial of service.
-
CAN-2003-0552: Jerry Kreuscher discovered that the Forwarding table
could be spoofed by sending forged packets with bogus source addresses
the same as the local host.
|
| Alerts: |
|
Comments (none posted)
apache2: Denial of Service vulnerability
| Package(s): | apache2 |
CVE #(s): | |
| Created: | September 29, 2003 |
Updated: | March 25, 2004 |
| Description: |
A problem was discovered in Apache2 where CGI scripts that write more than
4k to the standard error stream will hang the script's execution. This problem can lead to a
denial of service situation. See this bug
report for additional details. |
| Alerts: |
|
Comments (none posted)
cfengine: stack overflow
| Package(s): | cfengine |
CVE #(s): | |
| Created: | October 8, 2003 |
Updated: | October 8, 2003 |
| Description: |
Versions of cfengine prior to 2.0.8 contain a stack overflow in the network I/O code which can be exploited remotely. See this advisory for details. |
| Alerts: |
|
Comments (none posted)
ethereal: security problems in Ethereal 0.9.12
| Package(s): | ethereal |
CVE #(s): | CAN-2003-0428
CAN-2003-0429
CAN-2003-0431
CAN-2003-0432
|
| Created: | June 23, 2003 |
Updated: | November 10, 2003 |
| Description: |
Several security problems have been found in Ethereal
0.9.12. "It may be possible to make Ethereal crash or run
arbitrary code by injecting a purposefully malformed packet onto the wire,
or by convincing someone to read a malformed packet trace file." |
| 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)
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)
gnupg: key validation
| Package(s): | gnupg |
CVE #(s): | CAN-2003-0255
|
| Created: | May 15, 2003 |
Updated: | November 17, 2003 |
| Description: |
A key validation bug was discovered in the GNU Privacy Guard (GPG) which
would cause keys with more then one user ID to trust all user ID's with the
amount of trust given to the most-valid user ID. |
| 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)
KDE: Two issues in KDM
| Package(s): | kde, xfree86 |
CVE #(s): | CAN-2003-0690
CAN-2003-0692
|
| Created: | September 16, 2003 |
Updated: | December 19, 2003 |
| Description: |
According to this advisory two issues have
been discovered in KDM:
- CAN-2003-0690: Privilege escalation with specific PAM modules. The XDM display manager that ships with XFree86 prior to 4.3 is also vulnerable.
- CAN-2003-0692: Session cookies generated by KDM are potentially insecure
All versions of KDM as distributed with KDE up to and including KDE 3.1.3
are affected. |
| 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)
mikmod: buffer overflow
| Package(s): | mikmod |
CVE #(s): | CAN-2003-0427
|
| Created: | June 16, 2003 |
Updated: | June 16, 2005 |
| Description: |
Ingo Saitz discovered a bug in mikmod whereby a long filename inside
an archive file can overflow a buffer when the archive is being read
by mikmod. |
| Alerts: |
|
Comments (none posted)
mplayer: remotely exploitable buffer overflow vulnerability
| Package(s): | mplayer |
CVE #(s): | CAN-2003-0835
|
| Created: | September 29, 2003 |
Updated: | April 6, 2004 |
| Description: |
A remotely exploitable buffer overflow vulnerability was found in
MPlayer. A malicious host can craft a harmful ASX header, and trick MPlayer
into executing arbitrary code upon parsing that header. Read the full advisory
for details. |
| Alerts: |
|
Comments (none posted)
mysql: arbitrary code execution
| Package(s): | mysql |
CVE #(s): | CAN-2003-0780
|
| Created: | September 15, 2003 |
Updated: | October 9, 2003 |
| Description: |
Frank Denis
reported a vulnerability in MySQL affecting MySQL3 versions 3.0.57 and
earlier and MySQL4 versions 4.0.14 and earlier. Passwords of MySQL users
are stored in the "Password" field of the "User" table, part of the "mysql"
database. The passwords are hashed and stored as a 16 characters long
hexadecimal value. Unfortunately, a function involved in password checking
misses correct bounds checking. By filling a "Password" field a value
wider than 16 characters, a buffer overflow will occur. The Common
Vulnerabilities and Exposures (CVE) project assigned the id
CAN-2003-0780 to the problem. |
| Alerts: |
|
Comments (none posted)
Nessus NASL scripting engine security issues
| Package(s): | nessus |
CVE #(s): | |
| Created: | May 27, 2003 |
Updated: | August 12, 2004 |
| Description: |
Some some vulnerabilities exsist in the Nessus NASL scripting engine. To
exploit these flaws, an attacker would need to have a valid Nessus account
as well as the ability to upload arbitrary Nessus plugins in the Nessus
server (this option is disabled by default) or he/she would need to trick a
user somehow into running a specially crafted nasl script. Read the full
advisory for additional information. |
| 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)
nfs-utils xlog() off-by-one bug
| Package(s): | nfs-utils |
CVE #(s): | CAN-2003-0252
|
| Created: | July 14, 2003 |
Updated: | March 8, 2004 |
| Description: |
Linux NFS utils package contains remotely exploitable off-by-one bug.
A local or remote attacker could exploit this vulnerability by sending
specially crafted request to rpc.mountd daemon. See this BugTraq post for more details. |
| Alerts: |
|
Comments (none posted)
openssh: timing attack leads to information disclosure
| Package(s): | openssh |
CVE #(s): | CAN-2003-0190
|
| Created: | May 2, 2003 |
Updated: | November 30, 2004 |
| Description: |
From the advisory:
"During a pen-test we stumbled across a nasty bug in OpenSSH-portable
with PAM support enabled (via the --with-pam configure script switch). This
bug allows a remote attacker to identify valid users on vulnerable systems,
through a simple timing attack. The vulnerability is easy to exploit and
may have high severity, if combined with poor password policies and other
security problems that allow local privilege escalation." |
| Alerts: |
|
Comments (1 posted)
openssl: vulnerabilities in ASN.1 code
| Package(s): | openssl |
CVE #(s): | CAN-2003-0543
CAN-2003-0544
CAN-2003-0545
|
| Created: | September 30, 2003 |
Updated: | November 4, 2003 |
| Description: |
Vulnerabilities have been found in OpenSSL ASN.1 code. This advisory contains details of 4 separate
problems in versions of OpenSSL up to and including 0.9.6j and 0.9.7b and
all versions of SSLeay.
An attack against other applications that use OpenSSL could result in a
Denial of Service. See
CAN-2003-0543 and
CAN-2003-0544.
It may be possible for an attacker to exploit this issue to execute
arbitrary code. See
CAN-2003-0545.
CERT has an updated OpenSSL advisory
identifying additional OpenSSL vulnerabilities. |
| Alerts: |
|
Comments (none posted)
postfix: denial of service vulnerabilities
| Package(s): | postfix |
CVE #(s): | CAN-2003-0468
CAN-2003-0540
|
| Created: | August 5, 2003 |
Updated: | May 27, 2004 |
| Description: |
The postfix MTA, versions through 1.1.12 (but not 2.0) is subject to two remotely exploitable denial of service vulnerabilities; see this advisory from Michal Zalewski for details. |
| 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)
proftpd: remote root shell
| Package(s): | proftpd |
CVE #(s): | CAN-2003-0831
|
| Created: | September 24, 2003 |
Updated: | January 2, 2004 |
| Description: |
The ASCII translation mechanism in ProFTPD 1.2.8 contains a vulnerability which will provide a remote attacker with a root shell - if the attacker is able to download a specially-crafted file. See this ISS advisory for more information. |
| Alerts: |
|
Comments (2 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)
sane-backends: several vulnerabilities
| Package(s): | sane-backends |
CVE #(s): | CAN-2003-0773
CAN-2003-0774
CAN-2003-0775
CAN-2003-0776
CAN-2003-0777
CAN-2003-0778
|
| Created: | September 11, 2003 |
Updated: | February 20, 2004 |
| Description: |
Alexander Hvostov, Julien Blache and Aurelien Jarno discovered several
security-related problems in the sane-backends package, which contains
an API library for scanners including a scanning daemon (in the
package libsane) that can be remotely exploited. These problems allow
a remote attacker to cause a segfault fault and/or consume arbitrary
amounts of memory. The attack is successful, even if the attacker's
computer isn't listed in saned.conf.
You are only vulnerable if you actually run saned e.g. in xinetd or
inetd. If the entries in the configuration file of xinetd or inetd
respectively are commented out or do not exist, you are safe.
Try "telnet localhost 6566" on the server that may run saned. If you
get "connection refused" saned is not running and you are safe.
The Common Vulnerabilities and Exposures project identifies the
following problems:
-
CAN-2003-0773: saned checks the identity (IP address) of the remote
host only after the first communication took place (SANE_NET_INIT). So
everyone can send that RPC, even if the remote host is not allowed to
scan (not listed in saned.conf).
-
CAN-2003-0774: saned lacks error checking nearly everywhere in the
code. So connection drops are detected very late. If the drop of the
connection isn't detected, the access to the internal wire buffer leaves
the limits of the allocated memory. So random memory "after" the wire
buffer is read which will be followed by a segmentation fault.
-
CAN-2003-0775: If saned expects strings, it mallocs the memory
necessary to store the complete string after it receives the size of the
string. If the connection was dropped before transmitting the size,
malloc will reserve an arbitrary size of memory. Depending on that size
and the amount of memory available either malloc fails (->saned quits
nicely) or a huge amount of memory is allocated. Swapping and OOM
measures may occur depending on the kernel.
-
CAN-2003-0776: saned doesn't check the validity of the RPC numbers
it gets before getting the parameters.
-
CAN-2003-0777: If debug messages are enabled and a connection is
dropped, non-null-terminated strings may be printed and segmentation
faults may occur.
-
CAN-2003-0778: It's possible to allocate an arbitrary amount of
memory on the server running saned even if the connection isn't dropped.
At the moment this can not easily be fixed according to the author.
Better limit the total amount of memory saned may use (ulimit).
|
| Alerts: |
|
Comments (none posted)
sendmail: remotely exploitable buffer overflow
| Package(s): | sendmail |
CVE #(s): | CAN-2003-0694
CAN-2003-0681
|
| Created: | September 17, 2003 |
Updated: | November 18, 2003 |
| Description: |
Michal Zalewski has reported a buffer overflow in sendmail. This overflow, apparently, may be exploited remotely, but only in certain (non-default) configurations. Sendmail 8.12.10 has the fix. |
| Alerts: |
|
Comments (none posted)
stunnel: signal handler reentrancy DoS
| Package(s): | stunnel |
CVE #(s): | CAN-2002-1563
|
| Created: | July 25, 2003 |
Updated: | November 25, 2003 |
| Description: |
Stunnel is a wrapper for network connections. It can be used to tunnel an
unencrypted network connection over a secure connection (encrypted using
SSL or TLS) or to provide a secure means of connecting to services that do
not natively support encryption.
When configured to listen for incoming connections (instead of being
invoked by xinetd), stunnel can be configured to either start a thread or a
child process to handle each new connection. If Stunnel is configured to
start a new child process to handle each connection, it will receive a
SIGCHLD signal when that child exits.
Stunnel versions prior to 4.04 would perform tasks in the SIGCHLD signal
handler which, if interrupted by another SIGCHLD signal, could be unsafe.
This could lead to a denial of service. |
| 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: |
|
Comments (none posted)
unzip: directory traversal vulnerability
| Package(s): | unzip |
CVE #(s): | CAN-2003-0282
|
| Created: | July 1, 2003 |
Updated: | November 13, 2003 |
| Description: |
A vulnerabilitiy in unzip version 5.50 and earlier allows attackers to
overwrite arbitrary files during archive extraction by placing invalid
(non-printable) characters between two "." characters. These non-printable
characters are filtered, resulting in a ".." sequence. See the full
advisory for further information. |
| Alerts: |
|
Comments (none posted)
vim - modeline vulnerability
| Package(s): | vim |
CVE #(s): | CAN-2002-1377
|
| Created: | January 16, 2003 |
Updated: | February 10, 2004 |
| Description: |
VIM allows a user to set the modeline differently for each edited text file
by placing special comments in the files. Georgi Guninski found that these
comments can be carefully crafted in order to call external programs. This
could allow an attacker to create a text file such that when it is opened
arbitrary commands are executed. |
| Alerts: |
|
Comments (4 posted)
webmin: session ID spoofing
| Package(s): | webmin |
CVE #(s): | CAN-2003-0101
|
| Created: | June 13, 2003 |
Updated: | November 18, 2003 |
| Description: |
miniserv.pl in the webmin package does not properly handle
metacharacters, such as line feeds and carriage returns, in
Base64-encoded strings used in Basic authentication. This
vulnerability allows remote attackers to spoof a session ID, and
thereby gain root privileges. |
| Alerts: |
|
Comments (none posted)
wget: buffer overflow
| Package(s): | wget |
CVE #(s): | CAN-2003-1565
|
| Created: | August 5, 2003 |
Updated: | December 10, 2003 |
| Description: |
The wget utility contains a buffer overflow which, when exploited with an over-long URL, can enable arbitrary code execution. |
| Alerts: |
|
Comments (1 posted)
XFree86 4.3.0 integer overflows in font libraries
| Package(s): | XFree86 |
CVE #(s): | CAN-2003-0730
|
| Created: | September 12, 2003 |
Updated: | November 25, 2003 |
| Description: |
Several vulnerabilities were discovered by blexim(at)hush.com in the font
libraries of XFree86 version 4.3.0 and earlier. These bugs could
potentially lead to execution of arbitrary code or a DoS by a remote user
in any way that calls these functions, which are related to the transfer
and enumeration of fonts from font servers to clients. See the
advisory for additional details.
|
| Alerts: |
|
Comments (none posted)
xinetd: Memory leak in xinetd 2.3.10
| Package(s): | xinetd |
CVE #(s): | CAN-2003-0211
|
| Created: | May 13, 2003 |
Updated: | November 12, 2003 |
| Description: |
Xinetd is a 'master server' that is used to to accept service connection
requests and start the appropriate servers.
Because of a programming error, memory was allocated and never freed if a
connection was refused for any reason. An attacker could exploit this flaw
to crash the xinetd server, rendering all services it controls unavailable.
In addition, other flaws in xinetd could cause incorrect operation in
certain unusual server configurations.
All users of xinetd are advised to update to xinetd-2.3.11 which is not
vulnerable to these issues. |
| Alerts: |
|
Comments (none posted)
Resources
This month's CRYPTO-GRAM
Bruce Schneier's CRYPTO-GRAM newsletter for October is out. This month's
topics include
the future of surveillance,
the expanding use of the "Patriot" act,
pirating movies,
identity cards,
and the security risks of monocultures.
"
The upshot of this is that you should consider the possibility, albeit
remote, that you are being observed whenever you're out in
public. Assume that all public Internet terminals are being
eavesdropped on; either don't use them or don't care. Assume that
cameras are watching and recording you as you walk down the
street. (In some cities, they probably are.) Assume that surveillance
technologies that were science fiction ten years ago are now
mass-market."
Full Story (comments: 2)
Linux Security Week
The October 14 issue of Linux Security Week from LinuxSecurity.com is
available.
Full Story (comments: none)
New CERT Coordination Center (CERT/CC) PGP Key
CERT has adopted a new PGP key which will be used in its outgoing email. See the announcement for details on how to get the new key. Apparently the passphrase for the previous key was spread a little more widely than CERT had intended.
Full Story (comments: none)
Events
FIRST Conference
The 16th Forum of Incident Response and Security Teams (FIRST) will be held
June 13 to 18 in Budapest, Hungary. The call for papers is out
now, with a submission deadline of December 1.
Full Story (comments: none)
Page editor: Jonathan Corbet
Kernel development
Release status
Kernel release status
The current development kernel is 2.6.0-test7; there have been no
development kernel releases in the last week.
Linus's BitKeeper tree does contain a pile of patches, most of which are
stability fixes as one would expect. It also includes a (controversial)
patch to allow kernel threads to handle signals properly, a fix for a
possible interrupt handling deadlock, and a workaround for the AMD Opteron
prefetch bug.
The current stable kernel is 2.4.22. Marcelo released 2.4.23-pre7 on October 9; it includes
Jens Axboe's laptop mode patch, a new MegaRAID driver, BIOS enhanced disk
detection support, USB gadget support, and various other fixes and
updates. The plan is apparently to get the first release candidate out
within a month.
Comments (1 posted)
Kernel development news
Looking forward to 2.7
Some attention has been given to the "
2.7
thoughts" list which has been circulating on linux-kernel. Looking
forward to what can be done in the next development series can be an
interesting exercise. In this case, though, the exercise has mostly been
carried out by people who will not actually be doing the work; as a result,
the list has been dismissed by a few kernel hackers; one called it
"crackpot wishlist gunk."
So what are the crackpots wishing for? Some of the items they want (marked
"mandatory features" on the list) are already in the works; these include
support for CPU hotplugging, full NTFS support and virtual machine
support. Others are somewhat vague, including "complete user quota
centralization" and "improve kobject model for security, quota rendering."
And some will never happen; there is just not a whole lot of call for
features like an in-kernel Gopher server or a /proc implementation
of the loadable module tools.
Kernel hackers have far more respect for code (and those who produce it)
than they do for list makers. The 2.7 thoughts list may yet inspire
somebody to do some hacking, but its influence on the development process
is likely to remain small.
A more interesting view into what could happen with 2.7 might be found in a
conversation between Linus and Joel Becker of Oracle. The discussion turned
to what information was needed from the kernel to perform direct I/O, which lead to this outburst from Linus:
Have you ever noticed that O_DIRECT is a piece of crap? The
interface is fundamentally flawed, it has nasty security issues, it
lacks any kind of sane synchronization, and it exposes stuff that
shouldn't be exposed to user space.
Linus went on to wish an early death upon disk-based databases; he seems to
think that all but the largest databases should just be done in-memory.
Direct I/O does bring its share of problems. It is hard to keep the kernel
page cache in a coherent condition when I/O operations are allowed to
circumvent it; page cache confusion can lead to corrupted data. Getting
good performance out of direct I/O is hard unless asynchronous I/O is used
as well. Direct I/O can also confuse the disk I/O scheduler by creating
request patterns (especially overlapping requests) which don't otherwise
happen. In other words, the direct I/O idea is hard to get right for both
kernel and user space.
But systems like Oracle do need some of the capabilities that direct I/O
provides. They need to be able to move large amounts of data without
polluting the page cache with stuff that will not be used. Databases which
use shared storage need to be able to force data to be reread from disk
when another system has changed it. Large applications also tend to have a
better idea of how their access patterns work than the kernel does; they
know when a particular block of data will not be used any more. The need
for the level of control and performance direct I/O can provide will
persist, whether it