Fun with software patents
Much of this week's LWN front page has to do with software patents, and how
to respond to them. Doubtless some people are tired of the topic, but it
remains important. The shape of our free software systems in the future
will, unfortunately, be much affected by software patents. It is important
that we figure out how to deal with them.
Comments (3 posted)
Red Hat and software patents
Software companies worry about software patents; an infringement suit can,
after all, ruin your whole day.
Red Hat has decided that the best way to deal with the problem of software
patents is to get into the game. So, the company has applied for (at least)
two patents:
Both of these techniques show Ingo Molnar as the inventor. And where might
one find the patented technology?
The
embodiments of the present invention described are implemented in a
computing platform based on the computer operating system commonly known as
'Linux' that is available as open source directly over the Internet. Linux
is also available through various vendors who provide service and support
for the Linux operating system. Among these vendors are Red Hat, Inc., of
Research Triangle Park, N.C., the assignee of the present
invention.
(This news was originally reported (in Italian) on FreeGo).
After letting people worry over the holiday weekend, Red Hat issued a statement of
position on software patents. According to that statement, Red Hat's
intent is defensive:
Red Hat has consistently taken the position that software patents
generally impede innovation in software development and that
software patents are inconsistent with open source/free
software.... At the same time, we are forced to live in the world
as it is, and that world currently permits software patents. A
relatively small number of very large companies have amassed large
numbers of software patents. We believe such massive software
patent portfolios are ripe for misuse because of the questionable
nature of many software patents generally and because of the high
cost of patent litigation. One defense against such misuse is to
develop a corresponding portfolio of software patents for defensive
purposes. Many software companies, both open source and
proprietary, pursue this strategy.
Red Hat, too, has decided to pursue that strategy; it has joined the
software patent arms race by arming itself.
What do these patents mean for free software? According to Red Hat's
position, not much; the statement includes a promise to not enforce any
patent claims against software using an "approved" open source license.
So the free software community can relax; Red Hat is simply trying to
protect itself from patent suits and will not be exploiting
the dark side of software patents.
Not so fast. The situation, unfortunately, is not quite that simple.
There are a couple of problems with Red Hat's position that should be kept
in mind.
The first of these problems is that a promise on Red Hat's web site only
means so much. It is not an enforceable contract that anybody can count
on; Red Hat can change its position at any time. A court may take the
published promise into account in a future case, but that promise may not
keep such a case from happening in the first place. Red Hat, under its
current management, seems unlikely to change its approach to patents - the
posted promise is undoubtedly sincere. But corporate management and
ownership can change quickly - and, with them, posted patent policies.
More disturbing in the short term, however, is Red Hat's list of "approved"
licenses. It includes the GPL, the IBM Public License, the Common Public
License, the Q Public License, and "any open source license granted by
Red Hat." A whole class of licenses, including the LGPL and, crucially,
the BSD license, has been excluded from Red Hat's patent promise.
In other words, the various versions of BSD Unix are not welcome to use Red
Hat's patented technology. In fact, they can be sued for infringement if
they do use that technology. The license wars, it seems, are still being
waged, and Red Hat has just launched a new offensive. This is a move which
will encourage division in the free software community, to say the least.
The cynical among us could even see this policy as a strike by Red Hat
against a whole class of competing free operating systems. That is almost
certainly not the case: Red Hat is just trying to ensure that its patent
weapons can actually be used. As the company told us:
We elected to specifically exclude licenses that don't expressly
prohibit open source code from being incorporated into proprietary
code. Absent that stance, the patents would be of little benefit.
It's not worth it. Red Hat ships a great deal of software under licenses
which, it seems, are now too free: consider the X window system or
OpenSSH, for starters. There has been a great deal of exchange of ideas
between Linux and *BSD; the FreeBSD VM subsystem, for example, has long
been seen as an inspiration by at least some Linux kernel hackers. We have
all benefitted from the OpenBSD security auditing work. Red Hat, in the
name of patent defense, is cutting off the flow of ideas in one direction.
That is not how free software is supposed to work. Red Hat should find a
way to deal with software patents that does not alienate a large and
valuable part of the free software community.
As a starting point, why not contribute these new patents (and the various
gcc patents said to have been originally obtained by Cygnus) to a free
software "patent pool"? The patents would be licensed for any use as long
as the licensee does not sue any company alleging patent infringement by
any free software used or distributed by that company. If it is absolutely
necessary to dirty one's hands with software patents, this approach seems
more constructive and beneficial to the community.
Comments (23 posted)
ADEOS - avoiding real-time Linux patents
The current systems for performing hard real-time tasks with Linux
(
RTLinux and
RTAI) take the same approach:
use a real-time kernel at the lowest level of the system, and run the
general purpose kernel (i.e. Linux) as the lowest-priority task. This
technique has been patented by Victor Yodaiken, and the patent has been
licensed
to the community under terms similar to those used by Red Hat: as long
as your work is licensed under the GPL, you can use the patented
technology without paying royalties.
This patent and its license have been the subject of endless controversy in
the free software community. In particular, developers and users of RTAI
have always felt a little nervous, especially when the
RTAI core was licensed under the LGPL. The recent relicensing of the RTAI core was
undertaken to be sure of compliance with the patent license, but not
everybody has been satisfied. In particular, people who wish to run or
distribute proprietary systems using RTAI have been unsure of their
status.
An obvious solution, one might think, would be to not use the patented
technology; until recently, however, alternatives have been somewhat
scarce. That situation may have changed, however, as the result of the announcement of the upcoming first release
of ADEOS.
ADEOS is, essentially, a small "nanokernel" which takes charge of low-level
hardware resources (interrupts in particular). Any number of higher level
operating systems can run in parallel on top of ADEOS; they run
independently and know little of each other. ADEOS implements an
abstraction called an "interrupt pipeline," which is essentially an ordered
list of systems which are interested in a particular interrupt. Real-time
systems put themselves at the head of the list, and are thus able to
respond quickly to interrupts. General purpose systems can handle any
interrupts which the real-time systems allow to pass down the pipeline.
The idea of running multiple operating systems over a small, low-level
kernel is not particularly new; IBM has been doing it for decades. It is
interesting, however, in that the ADEOS developers claim that it is
suffiently different from the RTLinux approach that it is not covered by
the patent. The reality of the situation, however, may not be determined
until a fair number of lawyers have been involved.
The RTAI project plans to move over to ADEOS and thus, with luck, free
itself of patent worries. Whether RTAI will be able to rid itself of the
persistent claims that it is a derivative of RTLinux could be another
story. RTLinux supporters will point out strong similarities between a
number of source files in the two projects. If RTAI really used RTLinux
code at the beginning, and released that code under a different license
(even if that license was the LGPL), the project has, in theory, lost its
rights to use that code. Nobody has seriously pursued a GPL infringement
claim against RTAI, but, as long as the allegations persist, such an action
is a possibility.
Meanwhile, ADEOS embodies a different approach to dealing with software
patents: find a way to work around them. From the press release:
Often a piece of Free Software, into which many people have
invested years of work, can be turned into non-free software by a
patent for one simple but essential calculation rule. Our example
shows that the developers need not always give up. Sometimes, by
trying very hard, an alternative calculation rule that does the
work and is not completely useless can be found. Developers should
not shy [from] the effort that this takes, because even if the patent
owner offers a license on friendly terms, usually the project will
be restricted in some way or other and the intentions of the
developers to create real Free Software will be betrayed.
This approach has been taken with other patents: using JPEG and PNG files
to get around the GIF patent, and Ogg Vorbis as an alternative to MP3, for
example. As software patents proliferate in the U.S., however (and
possibly spread to Europe), it will get always harder to dodge them all.
And tiresome as well. Software patents remain a threat to free software.
(See also: a more detailed, technical
description of how ADEOS works.)
Comments (none posted)
UnitedLinux makes its launch
After a suitable period of pre-launch hinting, the
UnitedLinux initiative sent out
a
press release announcing its existence. A press release is about all
there is, at the moment; the realization of the goals behind United Linux
will take a little longer.
UnitedLinux is a joint venture between Caldera, Conectiva, SuSE and
Turbolinux. Essentially, the four will be combining much of their Linux
distribution development operation. The advantages of this combination are
fairly clear: much duplicated work can be eliminated, and the companies
will have at their disposal a single base distribution which is standards
compliant and uniform. The companies' four distributions have all lacked
sufficient market share to inspire software vendors to target them. One,
larger distribution, it is hoped, will be more successful at attracting the
independent software vendors of the world.
An alpha release of UnitedLinux, apparently based most heavily on SuSE's
distribution, is due in the near future, with the general release happening
in the fourth quarter of this year. Each distributor will then add its own
special offerings and sell the result under its own brand. Interestingly,
the UnitedLinux
release plans page mentions KDE 3.0, but says nothing about
GNOME. Several "installation languages" will be supported.
The biggest controversy over UnitedLinux would appear to be whether it will
be available as a free download. The initial statements from the group
have been mixed. We will have to wait and see on that one. A more
worthwhile question might be: will UnitedLinux expose its development
version the way Mandrake, Debian, and Red Hat (sort of) do? Inviting
outsiders into the development process is a far more convincing sign of
openness than distributing free binaries.
The other open question, of course, is: what other companies might join? An
invitation has been extended to Red Hat, but nobody really expects that
company to want to be a part of UnitedLinux. MandrakeSoft is a more
interesting possibility; it is by far the largest other distributor which
is not currently a part of the group. Thus far, MandrakeSoft has been
awfully quiet about UnitedLinux.
If UnitedLinux lives up to its promise, it could become the platform upon
which a new generation of distributions can grow. Doing UnitedLinux right,
however, will require keeping both the free software community and the
commercial world happy. This goal should be achievable; we wish this group
luck.
Comments (1 posted)
The new LWN.net site
Back in August, 1998, LWN made a major site change: we went from the
"everything on one big page" format to the multi-page format that is still
used for the weekly edition. We got over 100 complaints about that change
- people liked things the old way. So we restored the "one big page" as an
option, and it is still used by a (declining) number of LWN readers.
As you can see, LWN has changed format again; see our introductory posting for a description of
what has changed. We'll say here, however, that what has not
changed is LWN's content. The presentation is different, and a number of
new capabilities have been added, but our writing remains as always.
By the standards of 1998, the reaction to this change has been relatively
muted. Some people like the new site, others do not, but there has been no
avalanche of complaints. Which is fine with us. We are certainly
interested in hearing from our readers (at lwn@lwn.net) about ways we could improve the
new site; we do request, however, that commenters be specific about what
they do or do not like. We try to respond to specific complaints, but
there's not much that we can do with a message that just says "I hate the
new site."
There are certainly some rough edges on the new site. Bear with us, and
we'll do our best to straighten them out. Meanwhile, please check out the
new features, and, we hope, enjoy the new LWN experience.
(Note that people who want to see something that resembles the old site can bookmark lwn.net/current, which always gives the current weekly edition, or lwn.net/current/bigpage, which is the "one big page" format).
Comments (20 posted)
Page editor: Jonathan Corbet
Security
Welcome to the new LWN.net Security Page
Our first site code upgrade in nearly four years introduces
an integrated security alert and vulnerability database.
Our archive of security alerts dating back to July, 2001
now lives in a PostgreSQL relational database.
Vulnerabilities and alerts are actually linked to each other.
Recent alerts and vulnerabilities use
Common Vulnerabilities and Exposures (CVE)
numbers to uniquely identify each vulnerability.
Today you can browse alerts and vulnerabilities
using the links at the top of each page.
When viewing an alert, you can view the corresponding
vulnerability description with a mouse click.
In the future expect, and please continue to suggest, ways
for us to better provide you with the security information
you seek.
Comments (none posted)
US TurboLinux Security Severely Out of Date (iDEFENSE Labs)
iDEFENSE Labs has issued a
security
advisory for the US TurboLinux distribution.
The collective security weakness of the outstanding issues listed
below is staggering. The following is a list of the most serious
problems for which most other Linux vendors have provided updates on
their US sites. It represents the outstanding security problems
associated with the limited TurboLinux distributions and updates that
have been available on the US sites only.
LWN has pointed out in the past that Turbolinux has not been serious about security updates. With luck this advisory - or, perhaps, the UnitedLinux effort - will help get this distributor back on track.
Comments (1 posted)
Security news
Unique Preventative IDS for Linux
Scott Wimer, Chief Technology Officer of Cylant, dicusses preventive security in this paper.
The recent vulnerabilities with OpenSSH software demonstrate that even intensive auditing cannot necessarily root out all the defects from software. As software systems become larger and more complex, intensive auditing becomes more expensive and more difficult. Software audits
simply cannot be relied upon to find all of the security vulnerabilities in any given system.
Full Story (comments: 7)
Biometric Access Protection Devices and their Programs Put to the Test (c't)
C't has published
a study of eleven biometric access controls intended to prevent unauthorized access.
"In our attempts at outfoxing the protective programs and devices we have concentrated on the first method: direct attempts at deceiving the systems with the aid of obvious procedures (such as the reactivation of latent images) and obvious feature forgeries (photographs, videos, silicon fingerprints)."
Also see Bruce Schneier's previously published CRYPTO-GRAM
newsletter for May for a look at a technique for fooling fingerprint scanners with fake fingers made of gelatin.
Comments (none posted)
Security reports
Download Sites Hacked, Source Code Backdoored (Security Focus)
Brian McWilliams reports on the recent contamination of Fragroute
with a backdoor.
"According to program developer Dug Song, the source code to the Dsniff, Fragroute, and Fragrouter security tools was contaminated on May 17th after an attacker gained unauthorized access to his site, Monkey.org."
Note: Copies of Dsniff, Fragroute or Fragrouter downloaded
from Monkey.org between May 17th and May 24th are contaminated and
require replacement. For more details, see Dug Song's post to bugtraq about the incident.
Full Story (comments: none)
OpenSSH 3.2.3 released
Following on the heels of the last release, OpenSSH version 3.2.3
has been announced. This version
fixes a few bugs that showed up in version 3.2.2.
Full Story (comments: none)
Ethereal 0.9.4 released
Ethereal 0.9.4
was
released
on May 19, 2002 fixing four potential security issues in Ethereal 0.9.3:
- The SMB dissector could potentially dereference a NULL pointer in two cases.
- The X11 dissector could potentially overflow a buffer while parsing keysyms.
- The DNS dissector could go into an infinite loop while reading a malformed packet.
- The GIOP dissector could potentially allocate large amounts of memory.
No known exploits exist "in the wild" at the present time for any of these issues.
Comments (none posted)
Information Disclosure Vulnerability in IDS 0.8x
IDS is a CGI script that generates a multi-gallery photo album for a website on the fly. IDS 0.8x is reported to have a directory disclosure vulnerability.
Full Story (comments: none)
CGIscript.net - csPassword.cgi has multiple vulnerabilities
Steve Gustin has reported multiple vulnerabilities in the csPassword.cgi
script from
CGIscript.net
"Make sure you only allow trusted users to use the
csPassword application and make sure your web server
in configured to deny requests for .ht* and *.tmp
files."
Full Story (comments: none)
Caldera Security Advisory - Volution Manager
Volution Manager stores the unencrypted Directory Administrator's password
in the /etc/ldap/slapd.conf file. This vulnerability will be corrected in
the next release of Volution Manager.
Full Story (comments: none)
(Proprietary product) Informix SE-7.25 Local Vulnerability
A buffer overflow vulnerability was reported in Informix SE-7.25 if INFORMIXDIR enviroment variable is defined with a size greater than 2023 bytes.
Full Story (comments: none)
New vulnerabilities
Denial of service vulnerability in version 9 of BIND
| Package(s): | bind |
CVE #(s): | CAN-2002-0400
|
| Created: | June 5, 2002 |
Updated: | August 19, 2002 |
| Description: |
Here is an advisory from the Computer Emergency Response Team (CERT)
regarding the denial of service vulnerability in version 9 of the BIND
nameserver, up to 9.2.1. An attacker can send a properly crafted packet
which triggers a check within BIND and causes it to shut down. The
vulnerability can not be exploited for any purpose beyond denial of
service, but that is bad enough; if you are running BIND 9, an upgrade
is probably a good idea.
Note that many or most systems out there will still be running
BIND 8, and thus will not be vulnerable.
News articles on the vulnerability appear in the
Register
and
Network World Fusion News. |
| Alerts: |
|
Comments (none posted)
Ghostscript arbitrary command execution vulnerability
| Package(s): | ghostscript |
CVE #(s): | CAN-2002-0363
|
| Created: | June 5, 2002 |
Updated: | June 12, 2002 |
| Description: |
Ghostscript may be used to execute arbitrary commands with a maliciously formed PostScript file.
Since ghostscript is frequently used while printing documents, updating
is strongly recommended.
The vulnerability has been fixed in the 6.53 source release of GNU Ghostscript. |
| Alerts: |
|
Comments (none posted)
Mailman 2.0.11 fixes two cross-site scripting vulnerabilities
| Package(s): | mailman |
CVE #(s): | CAN-2002-0388
|
| Created: | June 5, 2002 |
Updated: | August 28, 2002 |
| Description: |
Barry A. Warsaw announced
the release of Mailman 2.0.11
"which fixes two
cross-site scripting exploits, one reported by "office" in the admin
login page, and another reported by Tristan Roddis in the Pipermail
index summaries.
It is recommended that all sites upgrade their 2.0.x systems to this
version."
|
| Alerts: |
|
Comments (none posted)
String format bug in pam_ldap logging
| Package(s): | nss_ldap |
CVE #(s): | CAN-2002-0374
|
| Created: | June 5, 2002 |
Updated: | October 29, 2002 |
| Description: |
The nss_ldap package includes the pam_ldap module for
authenticating a user with an LDAP database.
Pam_ldap versions prior to 144 have a string format
bug in the logging mechanism. |
| Alerts: |
|
Comments (none posted)
Malformed NFS packet buffer overflow vulnerability in tcpdump
| Package(s): | tcpdump |
CVE #(s): | CAN-2002-0380
|
| Created: | June 5, 2002 |
Updated: | October 9, 2002 |
| Description: |
A buffer overflow in tcpdump can be triggered by a bad NFS packet when
tracing the network. Unmodified tcpdump versions 3.6.2 and earlier are vulnerable.
|
| Alerts: |
|
Comments (none posted)
Uucp authentication agent, in.uucdp, bad string termination
| Package(s): | uucp |
CVE #(s): | |
| Created: | June 5, 2002 |
Updated: | June 5, 2002 |
| Description: |
The in.uucpd authentication agent in the
uucp package does not properly terminate some long input strings. |
| Alerts: |
|
Comments (none posted)
xchat IC server based dns query vulnerability
| Package(s): | xchat |
CVE #(s): | CAN-2002-0382
|
| Created: | June 5, 2002 |
Updated: | September 24, 2002 |
| Description: |
A malicious IRC server may
return a response to a /dns query that executes arbitrary commands
with the privileges of the user running XChat.
Versions of XChat prior to 1.8.9 are vulnerable. |
| Alerts: |
|
Comments (none posted)
Updated vulnerabilities
Ethereal packet handling vulnerabilities
| Package(s): | ethereal |
CVE #(s): | CAN-2002-0353
|
| Created: | June 5, 2002 |
Updated: | June 12, 2002 |
| Description: |
Ethereal 0.9.3 fixed three
packet handling vulnerabilities present in 0.9.2 when it was released
by the ethereal team on March 30th.
The PROTOS test
suite found some flaws in SNMP and LDAP protocols support.
Malformed packets could also crash ethereal 0.9.2 due to a
ASN.1 zero-length g_malloc problem.
The zlib "double free" vulnerability
was addressed by the updates for that bug from many distributors. (First LWN
report: May 2).
Update: The May 19, 2002 release of Ethereal 0.9.4
fixes four potential security issues in Ethereal 0.9.3.Please see
the new vulnerability for more information. |
| Alerts: |
|
Comments (none posted)
Remotely-exploitable buffer overflow vulnerability in fetchmail
| Package(s): | fetchmail |
CVE #(s): | CAN-2002-0146
|
| Created: | June 5, 2002 |
Updated: | June 18, 2002 |
| Description: |
Fetchmail versions prior to 5.9.10 have a buffer overflow vulnerability
that may be exploited by a malicious IMAP server.
The fetchmail client allocated memory to store the sizes of the
messages it is attempting to retrieve based on
a message count provided by the IMAP server.
A malicious IMAP server could provide an artifically
large message count to force the
fetchmail process to write data outside of the allocated memory. (First LWN
report: May 9). |
| Alerts: |
|
Comments (none posted)
UW imapd remotely exploitable buffer overflow
| Package(s): | imap |
CVE #(s): | CAN-2002-0379
|
| Created: | June 5, 2002 |
Updated: | December 20, 2002 |
| Description: |
UW imapd versions 2000c and prior allow remote authenticated users to execute code via a buffer overflow. A malicious user can craft
a request to run commands on the server under their UID and GID.
(First LWN report: May 23). |
| Alerts: |
|
Comments (2 posted)
OpenSSH 3.2.2 fixes multiple vulnerabilities
| Package(s): | openssh |
CVE #(s): | |
| Created: | June 5, 2002 |
Updated: | June 5, 2002 |
| Description: |
The OpenSSH developers have
released OpenSSH 3.2.2. Security fixes in this release are:
"
- fixed buffer overflow in Kerberos/AFS token passing
- fixed overflow in Kerberos client code
- sshd no longer auto-enables Kerberos/AFS
- experimental support for privilege separation [...]
- only accept RSA keys of size SSH_RSA_MINIMUM_MODULUS_SIZE (768) or larger"
(First LWN report: May 23). |
| Alerts: |
|
Comments (none posted)
UTF8 interaction bug in the perl-Digest-MD5 module
| Package(s): | perl-Digest-MD5 |
CVE #(s): | |
| Created: | June 5, 2002 |
Updated: | June 5, 2002 |
| Description: |
Versions prior to 2.20 of the perl-Digest-MD5 module have a bug
in the UTF8 interaction with perl that produces UTF8 strings
with improper MD5 digests.
(First LWN
report: May 16). |
| Alerts: |
|
Comments (none posted)
Heap corruption vulnerability in at
| Package(s): | at at, sudo, xchat |
CVE #(s): | CAN-2002-0004
|
| Created: | May 20, 2002 |
Updated: | May 15, 2003 |
| Description: |
The at command has a
potentially exploitable heap corruption bug.
(First LWN report: January 17th).
|
| Alerts: |
|
Comments (none posted)
DHCP remotely exploitable format string vulnerability
| Package(s): | dhcp/dhcp-server dhcp |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | June 20, 2002 |
| Description: |
The
May 8, 2000 release of ISC DHCP 3.0p1
fixes this serious
vulnerability in ISC DHCPD 3.0 to 3.0.1rc8 inclusive.
We encourage dhcp users to upgrade, disable dhcp or, at a minimum,
consider
using ingress filtering as described in the CERT advisory.
(First LWN
report: May 16).
Note: Distributions which use version 2 of ISC DHCP, such as Red Hat
Linux,
are not vulnerable.
|
| Alerts: |
|
Comments (none posted)
GNU fileutils race condition
| Package(s): | fileutils ucdsnmp |
CVE #(s): | CAN-2002-0435
|
| Created: | May 20, 2002 |
Updated: | May 16, 2003 |
| Description: |
A race
condition in rm may cause the root user to delete the whole filesystem.
The problem exists in the version of rm in
fileutils
4.1 stable and 4.1.6 development version. A patch
is available.
(First LWN
report: May 2).
|
| Alerts: |
|
Comments (none posted)
Buffer overflow problem in glibc
| Package(s): | glibc glibc/shlibs, glibc, nscd |
CVE #(s): | CAN-2001-0886
|
| Created: | May 20, 2002 |
Updated: | July 14, 2002 |
| Description: |
The glibc filename globbing code has a buffer overflow problem.
For those who are interested, Global InterSec LLC has provided
a detailed description
of this vulnerability.
This problem was first reported by LWN on December 20th.
|
| Alerts: |
|
Comments (2 posted)
Buffer overflow in groff
| Package(s): | groff |
CVE #(s): | CAN-2002-0003
|
| Created: | May 20, 2002 |
Updated: | December 9, 2002 |
| Description: |
The groff package has a buffer overflow
vulnerability; if it is used with the print system, it is conceivably
exploitable remotely.
|
| Alerts: |
|
Comments (none posted)
Problem loading untrusted images in imlib
| Package(s): | imlib |
CVE #(s): | CAN-2002-0167
CAN-2002-0168
|
| Created: | May 20, 2002 |
Updated: | June 5, 2002 |
| Description: |
Versions of
imlib prior to 1.9.13 used the NetPBM package in ways which
"make it possible
for attackers to create image files such that when loaded via software
which uses Imlib, could crash the program or potentially allow arbitrary
code to be executed."
(First LWN
report: March 28).
|
| Alerts: |
|
Comments (none posted)
Cross-site scripting vulnerability in Horde/IMP 2.2.7 and 3.0
| Package(s): | imp horde/imp |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | June 19, 2002 |
| Description: |
Version 2.2.8 of IMP has been released, it
fixes some vulnerabilities. "The Horde team announces the
availability of IMP 2.2.8, which prevents some potential cross-site
scripting (CSS) attacks." Upgrading
to IMP 3.1 or, at least, 2.2.8 is recommended
(First LWN
report: April 11, 2002).
Update: IMP 3.0, which was initially believed to be
immune, is also vulnerable. The problem
is fixed in IMP 3.1. |
| Alerts: |
|
Comments (1 posted)
Mozilla XMLHttpRequest file disclosure vulnerability
| Package(s): | mozilla |
CVE #(s): | CAN-2002-0354
|
| Created: | May 20, 2002 |
Updated: | October 18, 2002 |
| Description: |
This XMLHttpRequest security
bug impacts all Mozilla-based browsers. "The bug is found in versions of
Mozilla from 0.9.7 to 0.9.9 on various operating
system platforms, and in Netscape versions 6.1 and
higher."
(First LWN
report: May 2).
|
| Alerts: |
|
Comments (none posted)
Remotely exploitable vulnerability in pine
| Package(s): | pine |
CVE #(s): | CAN-2002-0014
|
| Created: | May 20, 2002 |
Updated: | November 27, 2002 |
| Description: |
Pine has an
unpleasant
vulnerability in URL handling vulnerability which can lead to
command execution by remote attackers.
(First LWN report: January 17th).
This vulnerability is remotely exploitable; updating is a good idea.
Note: If an update isn't yet available for your distribution,
setting enable-msg-view-urls to "off" in pine's setup will
avoid the vulnerability. (Thanks to Greg Herlein).
|
| Alerts: |
|
Comments (none posted)
Sharutils potential privilege escalation using uudecode
| Package(s): | sharutils |
CVE #(s): | CAN-2002-0178
|
| Created: | May 20, 2002 |
Updated: | October 30, 2002 |
| Description: |
According to the CVE entry,
"uudecode, as available in the sharutils package before 4.2.1, does not
check whether the filename of the uudecoded file is a pipe or symbolic
link, which could allow attackers to overwrite files or execute commands."
(First LWN
report: May 16).
|
| Alerts: |
|
Comments (none posted)
Multiple vulnerabilities in tcpdump
| Package(s): | tcpdump |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | June 5, 2002 |
| Description: |
Version 3.5.2 fixed a
buffer overflow vulnerability in all prior versions. However,
newer versions, including 3.6.2, are vulnerable to another
buffer overflow in the AFS RPC functions that was reported by
Nick Cleaton.
(First LWN
report: May 9).
Both problems appear to have been reported and fixed in FreeBSD some months
ago. The CIAC
report on the vulnerability in versions prior to 3.5.2 is dated October
31, 2000. Nick Cleaton's FreeBSD
security advisory on the AFS RPC bug, and reference to a fix for
FreeBSD, is dated July, 17, 2001. Tcpdump 3.7 was released on January 21,
2002.
|
| Alerts: |
|
Comments (none 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)
Multiple vulnerabilities in SNMP implementations
| Package(s): | ucdsnmp ucd-snmp |
CVE #(s): | CAN-2002-0012
CAN-2002-0013
|
| Created: | May 20, 2002 |
Updated: | September 17, 2002 |
| Description: |
Most SNMP
implementations out there have a variety of buffer overflow vulnerabilities
and should be upgraded at first opportunity. See this CERT advisory for more. (First
LWN report: February 14).
|
| Alerts: |
|
Comments (none posted)
webalizer: reverse DNS buffer overflow vulnerability
| Package(s): | webalizer |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | January 27, 2003 |
| Description: |
The cause is a buffer overflow bug.
This one sounds nasty.
If reverse DNS lookups are enabled in webalizer,
"an attacker with control over the victims DNS may spoof responses thus
triggering a buffer overflow, potentially leading to a root compromise."
Webalizer 2.01-10 "fixes this and a few
other buglets that have been discovered in the last month or so".
(First LWN report: April 18th, 2002).
|
| Alerts: |
|
Comments (none posted)
Webmin/Usermin vulnerabilities
| Package(s): | webmin |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | January 10, 2003 |
| Description: |
Webmin is a web-based interface for
system administration for Unix.
Webmin has cross-site scripting and
session ID spoofing vulnerabilities
which are fixed in the May 6, 2002 release of version 0.970.
(First LWN
report: May 9).
This one is scary. The session ID
spoofing vulnerability allows the "possibility that arbitrary
commands may be executed with root privileges."
Upgrading is strongly recommended. At a minimum avoid the
"preconditions for a successful exploit" by disabling
password timeouts under Webmin->Configuration->Authentication.
|
| Alerts: |
|
Comments (1 posted)
Problems with libgtop_daemon
| Package(s): | wuftpd libgtop |
CVE #(s): | |
| Created: | May 20, 2002 |
Updated: | May 7, 2003 |
| Description: |
The libgtop_daemon package is a GNOME
program which makes system information available remotely.
LWN reported the remotely exploitable format
string and buffer overflow vulnerabilities in that package
on December 6th.
On November 28th
disabling the libgtop_daemon on systems where it is running until
an update is available.
Many Linux systems do not run
libgtop by default, but applying the update is a good idea anyway.
|
| Alerts: |
|
Comments (1 posted)
zlib corrupts malloc data structures via double
free
| Package(s): | zlib rsync libz vnc zlib, cvs, gnupg, rrdtool, libz/zlib packages upgrade security problems cvs recompiled against updated + /tmp |
CVE #(s): | CAN-2002-0059
CAN-2002-0092
CAN-2002-0080
|
| Created: | May 20, 2002 |
Updated: | June 5, 2002 |
| Description: |
This vulnerability impacts all major Linux vendors. It may
impact every Linux installation on Earth.
Updates are required to zlib and any
packages that were statically built with the zlib code.
(First LWN report: March 14).
LinuxSecurity
describes the vulnerability and coordinated distributor efforts
in detail.
"Packages including X11, rsync, the Linux kernel, QT, mozilla, gcc,
vnc, and many other programs that have the ability to use network
compression are potentially vulnerable."
Updating is recommended.
As always, please proceed with caution when applying updates to
the kernel.
|
| Alerts: |
|
Comments (none posted)
Resources
CERT Summary CS-2002-02
The
CERT Coordination Center (CERT/CC) issued their CERT
quaterly summary
"to draw attention to the types of attacks reported to our
incident response team, as well as other noteworthy incident and
vulnerability information."
Full Story (comments: none)
Announcing Fenris 0.06
Fenris 0.06
has been released by Michal Zalewski.
"This release brings you much improved debugging capabilities, from a
console-based debugging GUI [...], to
core functionality fixes, anti-debugger techniques detection, better
performance, or an updated write-up on debugging burneye-protected code."
Full Story (comments: none)
Linux Security Week and Advisory Watch
The
June 3 Linux Security Week from
LinuxSecurity.com is available, as are the Linux Advisory Watch Newsletters
from
May 24 and
May 31.
Comments (none posted)
Book Review: SSH, The Secure Shell - The Definitive Guide
Danny Yee has
reviewed
SSH, The Secure Shell - The Definitive Guide published by
O'Reilly & Associates in 2001.
Full Story (comments: none)
Events
Upcoming Security Events
| Date | Event | Location |
| June 6 - 7, 2002 | Qualys Security Conference | (Hotel Nikko)San Francisco, CA |
| June 17 - 19, 2002 | NetSec 2002 | San Fransisco, California, USA |
| June 24 - 28, 2002 | 14th Annual Computer Security Incident Handling Conference | (Hilton Waikoloa Village)Hawaii |
| June 24 - 26, 2002 | 15th IEEE Computer Security Foundations Workshop | (Keltic Lodge, Cape Breton)Nova Scotia, Canada |
| June 28 - 29, 2002 | Edinburgh Financial Cryptography Engineering 2002 | Edinburgh, Scotland |
| July 31 - August 1, 2002 | Black Hat Briefings 2002 | (Caesars Palace Hotel and Resort)Las Vegas, NV, USA |
| August 2 - 4, 2002 | Defcon | (Alexis Park Hotel and Resort)Las Vegas, Nevada |
| August 5 - 9, 2002 | 11th USENIX Security Symposium | San Francisco, CA, USA |
For additional security-related events, included training courses (which we
don't list above) and events further in the future, check out
Security Focus' calendar,
one of the primary resources we use for building the above list. To
submit an event directly to us, please send a plain-text message to
lwn@lwn.net.
Comments (none posted)
Page editor: Dennis Tenney
Kernel development
Kernel release status
The current development kernel is 2.5.20, which was
released by Linus on June 2. Big changes this time
include a large ACPI merge, a bunch more buffer/VM work, a PowerPC64 merge,
the usual set of IDE patches, various merges from the -dj series, some
device model work, and numerous other fixes and updates. The
long format changelog is also available.
Other releases from Linus since the last LWN Kernel Page include:
- 2.5.19 (short, long). Changes include more block, buffer,
and IDE layer work, some enhancements to the driver model code, more
kbuild tweaks, and many other fixes and updates.
- 2.5.18 (short, long). This one included the software
suspend patch (as covered in the May 23 LWN
Kernel Page), a bunch of kbuild fixes (which are not Keith Owens's
new kbuild system - see below), more IDE reworking, more VFS changes,
and a bunch of other fixes and improvements.
The current prepatch from Dave Jones is 2.5.20-dj3. The most significant feature of
this patch, perhaps, is the merging of some small pieces of the
kbuild 2.5 code.
The latest 2.5 status summary from Guillaume
Boissiere came out on June 5.
The current stable kernel release is 2.4.18. Marcelo's plan had
been to create a 2.4.19 release candidate, but some problems turned up. So
he released 2.4.19-pre10 instead. A very
long list of fixes got into this release. With luck, the next prepatch
from Marcelo will be the first 2.4.19 release candidate.
Alan Cox has released 2.4.19-pre10-ac2; arguably the most interesting change in this prepatch is the inclusion of the "speakup" console module for blind users.
Comments (none posted)
A new way of block queue plugging
Jens Axboe has posted
a patch which, once
again, changes some of the main assumptions underlying the block I/O
subsystem. It is worth a look at what is going on.
A longstanding feature of the block layer has been "queue plugging." If
the request queue for a particular block device has been plugged, that
device's driver will not be invoked to execute the operations in the
queue. The main reason for plugging has been to allow the block layer to
build up a backlog of requests, so that adjacent operations can be merged.
By sometimes waiting a little longer to start an operation, the block layer
can often achieve better performance overall.
With the 2.5 block layer, however, there is less need for this sort of
plugging. The code works harder at not splitting large requests in the
first place, so it is not necessary to merge them again. The new plugging
code actually serves a different purpose: it is a mechanism by which a
block driver can indicate that it is busy and can not handle any more
requests at the moment.
As Jens points out in his patch, the block code is starting to look a
little (a little!) bit more like the networking subsystem. Like network
interfaces, block devices can have multiple requests outstanding. When the
device has been given all the simultaneous requests that it can handle,
there is no point in further troubling the driver until some of those
requests complete. Thus the new plugging code: block devices, too, can ask
to be allowed to work in peace for a while.
There's a couple of other, incidental changes in this patch. One is that
the venerable tq_disk task queue has been removed. Slowly, the
set of standard task queues is shrinking. A block driver's
request ("strategy") function is also now called out of a
tasklet. The block layer that shows up in 2.6 will be vastly different
from what has been seen in previous stable kernels.
Comments (1 posted)
Splitting the kernel stack
The Linux kernel has, for years, run with an 8KB (two page) stack in each
process's address space (at least, on i386 systems). That stack holds the
"task structure" (the kernel's information about the process) and provides
space for automatic variables and call frames when the system is running in
kernel mode. The 8KB stack works, of course, but it is not optimal. The
biggest problem, perhaps, is the need to find two adjacent pages for a new
stack every time a new process is created. On a busy system memory can get
badly fragmented, and allocating two pages together can be a challenge.
So Ben LaHaise has posted a patch which
splits the kernel stack into two 4KB stacks. One of them holds the task
structure and is used by normal kernel code (i.e. handling system calls).
The other stack is set aside and is used only when the kernel is handling
interrupts.
A separate interrupt stack is not a particularly new idea - many operating
systems have had interrupt stacks for decades. There are numerous
advantages to doing things this way. Only one interrupt stack (per CPU) is
needed, so one page of memory per process is freed up. The interrupt stack
is also more likely to stay in the processor cache, improving performance.
Interrupt handlers need not worry about other kernel code having consumed
most of the stack when they get invoked. And, of course, it is no longer
necessary to perform a two-page allocation to set up the regular kernel
stack.
The biggest downside, perhaps, is that non-interrupt kernel code must now
fit into much less stack space. Some
kernel code is not particularly careful about the size of its automatic
variables, and risks overflowing the new, smaller stack. As a way of
tracking down such code, Ben has also posted a
stack checker (followed by a brown paper bag
fix) which monitors stack usage and raises the alarm when
available space on the stack gets too low. The two patches are probably
best used together.
Comments (none posted)
The continuing saga of kbuild 2.5.
The discussion over whether to merge kbuild 2.5 has been covered in this
space before. It is one of those conversations that persists, however. A
few things have happened over the last few weeks.
Keith Owens, the author of kbuild 2.5, has posted a new set of timing comparisons meant to show
the advantages of the new code. The full build process Keith performed
took a bit less than 14 minutes
with kbuild 2.5, and a little over 20 minutes with the existing
kbuild. He also points out that the result is sometimes incorrect with the
existing code.
Daniel Phillips also tried it out and
obtained similar results. For good measure, Daniel took a look at the code
itself: "There is no Python anywhere to be seen in kbuild 2.5, for
those who worry about that. It is coded in C, about 10,000 lines it seems.
It has a simple built in database which I suppose accounts for some of
that. For what it does, it seems quite reasonable."
In general, most (but not all) developers who express an opinion on the
matter seem to feel that kbuild 2.5 is worthwhile and should be
merged. So it has surprised a number of people to see numerous patches to
the existing kbuild system, written by Kai Germaschewski, being merged by
Linus. These patches do worthwhile things, but they are not
kbuild 2.5. Why bother, one might ask, if the whole thing is going to
be replaced?
The answer seems to be that Linus, for now, wants Kai to be the kbuild
maintainer. Kai is willing to do things in small pieces, which has always
been Linus's preferred method; Keith has, so far, refused to break his
kbuild work up in this way. Also, says Linus:
Kai isn't an enthusiastic kbuild-2.5 supporter. In fact, he tends
to be a bit down on some of it. Which is a plus in my book: it
means that whatever Kai tries to push my way I'll feel just that
much more comfortable with as having had critical review.
Meanwhile, a couple of different developers (Sam Ravnborg and "Lightweight
patch manager") have started submitting broken up versions of
kbuild 2.5. Kai has stated that he will look them over and integrate
those which make sense. Some of these patches also found their way into 2.5.20-dj3. It seems like at least a partial victory for the
new kbuild.
So one has to wonder why, after all this, Keith felt the need to post his
call for an email campaign entitled "If you
want kbuild 2.5, tell Linus." It's a full-scale polemic that takes one
back to the old devfs wars. It is also, seemingly, counterproductive. One
would think that would be better to work with the people who are trying to make
kbuild acceptible to Linus than to call for a pressure campaign.
Comments (2 posted)
The value of negative dentries
A "directory entry" (dentry) is an internal data structure used to hold the
results of looking up a file in the filesystem. The Linux "dentry cache"
keeps a number of recently used dentries around; they tend to be useful,
since files are often accessed more than once over a short period of time.
Finding a file in the dentry cache can save a lot of time by avoiding a
full filesystem lookup.
The kernel also hangs on to "negative dentries," which indicate that the
given file does not exist. Andrea Arcangeli recently noted that these negative dentries can take up
quite a bit of memory, and wondered what possible use they could be. His
message included a patch to force negative dentries out of memory quickly.
It turns out, though, that "this file does not exist" can be useful
information. A quick strace run on a GNOME application, for
example, turns up dozens of lookups on nonexistent files as the application
gropes around looking for the unbelievable number of libraries it needs.
Similarly, apache is continually looking for .htaccess files,
shells look for executables, etc. It is more than worthwhile to be able to
determine that a file doesn't exist without an expensive filesystem call -
especially for file names that are often looked up. So negative dentries
will stay.
There is one optimization that can be made, though. In Andrea's case, the
negative dentries were created by deleting a large directory full of
files. When a file is deleted, it is relatively unlikely that it will be
looked up again soon, and keeping a negative dentry around is less useful.
In this case, perhaps, it is better to just forget about the file name
altogether.
Comments (1 posted)
The return of /dev/port
A few weeks ago, LWN reported on the removal of support for
/dev/port from the 2.5 kernel. Since then, a few users have
reported real uses for
/dev/port and a desire that it stay in the
kernel. Martin Dalecki, who create the patch removing
/dev/port,
suggested that users who
really need it can patch it back in
themselves. Linus
disagreed, saying:
So when simplifying, it's not just important to say "we could do
without this". You have to also say "and nobody can reasonably
expect to need it".
Which doesn't seem to be the case with /dev/ports. So it stays.
That is, of course, the definitive end to the discussion.
Comments (1 posted)
Resources
A few other worthwhile notes:
- Kernel Traffic issues 168
and 169
are available.
- The Linux Security Module web
site has been overhauled in a big way. "It's no longer an
endless dribble of old patches. It contains some information about
the project, more navigable patch listing, links to the BK
repositories, and links to all the documentation that I am aware
of."
- Late last April, we mentioned that Pacific Northwest National
Laboratory was seeking an experienced kernel programmer to work on its
new, 1400-node
Linux cluster. The position is still open, so go check
it out if you think you might be interested.
Comments (none posted)
Patches and updates
Kernel trees
- Lightweight patch manager: linux-2.5.20-ct1. Adds a number of "trivial patches" to 2.5.20.
(June 4, 2002)
- Andrea Arcangeli: 2.4.19pre9aa1. Included the integration of the O(1) scheduler - "highly experimental."
(June 4, 2002)
- Paul P Komkoff Jr: 2.4.19-pre9-ac1-s1. kbuild 2.5, EVMS, and a number of fixes.
(June 4, 2002)
- Marc-Christian Petersen: 2.2.21-3-secure. Many goodies for 2.2: OpenWall, ext3, ReiserFS, CryptoAPI, ACLs, USAGI, FreeS/Wan, 2.4 IDE, etc. "<span>The intended purpose is for production/servers.</span>"
(June 4, 2002)
Core kernel code
- Robert Love: scheduler hints. Allow applications to give hints to the scheduler on how they will behave.
(June 4, 2002)
- Russell King: cpufreq core for 2.5. A common (across architectures) interface to CPU clock speed.
(June 4, 2002)
- William Lee Irwin III: lazy_buddy-2.5.19-3. A "bugfix and cleanup release" of the new, deferred coalescing memory allocator.
(June 4, 2002)
- Andrew Morton: direct-to-BIO writeback. Perform filesystem writeouts direct to the block layer via BIO requests - no more buffer heads. At least in simple cases.
(June 5, 2002)
- Andrew Morton: direct-to-BIO readahead. Make the readahead code work without buffer heads. "<span>CPU load for `cat large_file > /dev/null' is reduced by approximately
15%.</span>"
(June 5, 2002)
Development tools
- Randy.Dunlap: kerneltop. A "top"-like display generated from kernel profiling data.
(June 4, 2002)
Device drivers
- Martin Dalecki: 2.5.18 IDE 71. "<span>Scary big patch this time</span>."
(June 4, 2002)
Documentation
- Patrick Mochel: device model documentation 1/3. Documentation of the device model code - part 1 covers the <tt>bus_type</tt> structure.
(June 4, 2002)
Filesystems and block I/O
- Andreas Gruenbacher: Status of 2.5.x port. An initial port of the extended attribute/access control list code to 2.5.
(June 5, 2002)
Janitorial
- Robert Love: remove suser(). The venerable suser() call is gone at last.
(June 5, 2002)
Kernel building
Networking
Architecture-specific
- James Bottomley: i386 arch subdivision into machine types for 2.5.18. "<span>This code rearranges the arch/i386 directory structure to allow for sliding
additional non-pc hardware in here in an easily separable (and thus easily
maintainable) fashion.</span>"
(June 4, 2002)
- Thomas Capricelli: linux zeta-0.2 released. Zeta is a virtual platform to which the group is porting Linux.
(June 4, 2002)
Security-related
- Chris Wright: 2.5.20-lsm1. New version of the Linux Security Module patch.
(June 5, 2002)
- Chris Wright: 2.4.18-lsm3. Linux Security Module patch for 2.4.18.
(June 5, 2002)
- Amon Ott: RSBAC v1.2.0. Rule Set Based Access Control.
(June 4, 2002)
Miscellaneous
- Andrew Morton: "laptop mode". Optimizations for laptop use - mostly minimizing disk spinups.
(June 5, 2002)
- Bartlomiej Zolnierkiewicz: atapci 0.50. Reads information from ATA PCI chipsets.
(June 4, 2002)
- Bartlomiej Zolnierkiewicz: atapci 0.51. Fixes a problem with 0.50.
(June 5, 2002)
Page editor: Jonathan Corbet
Distributions
News and Editorials
Announcement: the AGNULA project
The AGNULA project aims to develop two reference distributions for the
GNU/Linux operating system completely based on Free Software (i.e. under a
FSF approved Free Software license) and dedicated to audio and
multimedia. One distribution will be Debian-based (DeMuDi) and the other
will be Red Hat-based (ReHMuDi).
Full Story (comments: none)
Scyld Beowolf
In the
May 23rd
Distributions page the
Scyld
Beowulf Cluster Operating System was incorrectly identified as hardware
specific. In fact the Scyld distribution supports x86, Alpha, and other
platforms.
Comments (none posted)
Distribution News
Debian GNU/Linux
The Debian Project has
sent out a
release describing what is claimed to be a new intercontinental
Internet performance record: the first Debian Woody CD was transferred from
Fairbanks, Alaska to Amsterdam in 13 seconds. The systems on both ends were
running Debian, of course.
The Debian Weekly News for May 23 is out, with
coverage of MPlayer, Nessus, the fair use status of the fortunes file, and
more.
Here's the Debian Weekly News for May 29. It
looks at the new Debian Flyers, the abortive attempt at packaging WineX,
apt preferences, and more.
In this announcement Josip Rodin discusses woody
release status. "To reiterate the main point from the April 30th mail by Anthony Towns, the
release of woody is being held back because there is no systematic way to
build packages in security advisories on all architectures included in
woody."
Comments (none posted)
Mandrake Linux
Issue #43 of the
Mandrake Linux Community
Newsletter is out. "
This Week's Summary: StarOffice 6.0 Officially
Released; Spotlight on MandrakeExpert; MandrakeClub Activities; Website of
the Week (plf.zarb.org); Online Survey; Ximian GNOME for Mandrake 8.2;
Mandrake in the News; Website Updates; Software Updates; Headlines from
MandrakeForum."
The Mandrake Linux Community Newsletter for
June 1 (issue #44) is out. It covers the MandrakeSoft.com redesign, the
Business Case of the week, recent security alerts, and more.
Comments (none posted)
Red Hat Linux
Red Hat has two bug fixes out for this week. There are new
SANE packages for RH 7.3 which fix a problem
observed when upgrading SANE. There are also new
XFree86 packages are available which fix
various bugs reported since the last erratum update. These are available
for RH 7.1 - alpha, i386, ia64 and RH 7.2 - i386, ia64.
Comments (none posted)
Slackware Linux
On May 25, 2002 Slackware 8.1-rc1 was announced. That was followed by
Slackware 8.1-rc2, announced on June 1, 2002. Since then much progress
has been made on cleaning up the remaining bugs. As always the
Slackware-current
change log contains the details.
Comments (none posted)
Yellow Dog Linux
Terra Soft Solutions, Inc., publishers of Yellow Dog Linux,
announced the Japanese edition of Yellow Dog
Linux 2.2, which will be showcased by Amulet at LinuxWorld Tokyo.
Yellow Dog L