The new Fedora Project
Last July, Red Hat let it be known the Red Hat Linux, as a retail product,
was coming to an end. Red Hat's customers would be steered, instead, at
the company's "enterprise" products, which are aimed at corporate needs
and, incidentally, bring in a lot more revenue to the company. The
company's strategy has had some success; Red Hat's recently
announced
quarterly results show an increase to about 26,000 Enterprise Linux
subscriptions. Those subscriptions brought in almost $15 million in
revenue over the quarter (enterprise services brought in another
$9 million).
What replaced Red Hat Linux at that time was the "Red Hat Linux Project,"
an attempt to transform the process of making Red Hat's core distribution
into a more open, community-oriented project. Now, this distribution has
gone through another change, as announced
on September 22:
Red Hat and Fedora Linux are pleased to announce an alignment of
their mutually complementary core proficiencies leveraging them
synergistically in the creation of the Fedora Project, a paradigm
shift for Linux technology development and rolling early deployment
models.
The rest of the announcement, thankfully, is in English.
The old Fedora Linux
Project was an independent effort to create a set of high-quality
add-on packages for Red Hat Linux. Fedora had managed to put together a
set of policies, a development community, and an initial set of packages.
Red Hat, in its effort to kick-start the Red Hat Linux Project, saw value
in all of those things. So now the two projects have merged into a single
entity called the Fedora project.
The project stuck with the Fedora name, among other reasons, so that the
resulting distribution would not run into trademark problems with the Red
Hat name. (There may yet be confusion with the Fedora Project hosted at Cornell, which is
developing a free digital repository management system.)
Red Hat is still putting together policies and documentation for the new
project, so some of the details are still coming into focus. The project
leadership role will be in the capable hands of Michael K. Johnson, one of
the Red Hat originals. There will be a a steering committee appointed by
Red Hat; it currently consists of Karen Bennet, Cristian Gafton, Michael
K. Johnson, Jeff Law, and Stephen Tweedie. The plan also calls for an
advisory committee, the makeup and duties of which has not yet been
determined. Finally, there will be a "technical committee," which is
simply the union of the steering and advisory committees.
The Fedora project's output will consist of three distinct sets of
packages:
- The Fedora Core will be something that looks like the current
Red Hat Linux distribution. It will be the basic distribution that is
released by the Fedora project; everything that is in the core
distribution will be approved by the steering committee.
- The Fedora Extras is a set of additional packages which
complement the core distribution. The Extras are strict add-ons; they
cannot conflict with or replace packages in the core distribution.
Among other things the Extras will be a sort of staging ground for
packages (and their maintainers) to prove themselves before being
admitted to the Core
distribution. The technical committee will decide which packages get
to be in the Extras.
- The Fedora Alternatives is the "contrib" area of the Fedora
project; just about any package can be in the Alternatives as long as
it is free software and doesn't run into legal problems.
The project planners also foresee a "Fedora Legacy" area for the
maintenance of older packages, and a "third party" area that will become
the Fedora equivalent of Debian's non-free. Red Hat will have nothing to
do with the non-free code, however.
According to the posted schedule, the
"test 2" release of the Fedora core is due on September 25.
There is a third test release planned for October 13, and the final
release should be out on November 3. Then work begins on "Fedora
Core 2", which will be, with luck, based on the 2.6 kernel.
To succeed, Fedora must attract a significant amount of community interest
and input. Red Hat needs external developers to help with the maintenance
of the distribution and bring in new packages. It also very much needs
an active user community which will test and deploy the Fedora
distribution; to a great extent, Fedora will be part of the quality control
process that packages go through before becoming part of the enterprise
products.
Bringing in developers will require making them feel like something other
than unpaid Red Hat employees. That means giving Fedora a life outside of
the company. Red Hat seems to understand that need;
for example, Red Hat's Havoc Pennington says:
Red Hat will be doing a lot of development and other work on the
Fedora Project, but it's not a product that you can buy from
us. We're working on the Fedora Project in the same way that we
work on other projects such as Mozilla or the Linux kernel.
Of course, this claim is not entirely true: Red Hat does not name, by fiat,
the members of any "steering committees" for Mozilla or the kernel. But
the idea the company is trying to get across is clear: Fedora, as a
project, is separate from Red Hat and its products.
The
degree to which that is true, and to which Red Hat can step back and let
Fedora find its own path will
be crucial to Fedora's success. Letting go could be hard for Red Hat to do;
almost anybody who has done business with that company will attest that Red
Hat, while well-intentioned, very much likes to retain control over the
projects it works on. Red Hat also has a history of working well with the
free software community, however; they understand well how the free
development process works. So when the company says
something like:
Anyway, it's not just about what Red Hat developers work on
anymore. Anybody can drive the project in a different direction by
developing the code and making a case for including it.
There is a good chance that things will work out that way.
Comments (19 posted)
The European software patent vote
Members of the European Parliament (MEPs) passed
Arlene
McCarthy's proposed patent directive this Wednesday, with numerous amendments
that may mean a victory for the open source community and others opposed
to software and business practice patents. The
full text of the passed directive is available for those who are interested (thanks to James Heald). As a result of the
Foundation for a Free Information
Infrastructure (FFII) and many others, software patents in Europe
have been staved off -- for now.
However, we have miles to go with regards to the directive. This vote is
not the final say in the matter. The European Parliament will vote again
on the directive, but after it has been addressed by the European
Commission (EC). It's entirely possible that the directive passed by the
parliament will be rejected by the EC, or that the original directive
without the amendments will be approved by the EC. LWN reader Ciaran
O'Riordan notes that in the
event that the original is approved, Parliament will not have a second
chance to address the directive and McCarthy's original draft will be
enacted.
Under the amended directive, an inventor may patent a "programmed
device," but patents on software and business methods are specifically
excluded. Amendment 3a specifically disallows any patents in the field
of data processing, while 2b specifically requires an invention to be
"susceptible of industrial application." Amendment 2d specifies
"industry" as the "automated production of material goods." Presumably
this means that one cannot patent entertainment devices or other goods
specifically targed for consumer use.
Further, patent applications for programmed devices must include "a
well-functioning and well documented reference implementation of such a
program is published as part of the patent description without any
restricting licensing terms." This means that, should the amended
directive go through, inventors will not be able to prevent
interoperability with their devices through obscurity. Readers in the
United States may be interested to know that the U.S. government has chimed
in with opposition to article 6a, which states that patents can not be
used to block interoperability:
Member States shall ensure that, wherever the use of a patented
technique is needed for a significant purpose such as ensuring
conversion of the conventions used in two different computer systems or
networks so as to allow communication and exchange of data content
between them, such use is not considered to be a patent infringement.
The amended directive is a vast improvement over McCarthy's original
proposal. However, Jonas Maebe, a Belgian FFII representative, says the
approved draft still needs work:
The recitals were not amended thouroughly. One of them still claims
algorithms to be patentable when they solve a technical problem. But we
have all the ingredients for a good directive. We've been able to do the
rough sculpting work. Now the patching work can begin. The spirit of the
European Patent Convention is 80% reaffirmed, and the Parliament is in a
good position to remove the remaining inconsistencies in the second
reading.
That assumes, of course, that there is a second reading to be had. When
speaking to Parliament during the Plenary Debate the day before the
vote, EC Commissioner Frits Bolkestein issued (PDF format) a not-too-veiled threat to remove parliament from the process entirely:
If we fail in our efforts to achieve a harmonisation of patent law
relating to computer-implemented inventions in the European Union, we
may well be confronted with a renegotiation of the European Patent
Convention. The process of renegotiation of the European Patent
Convention would not require any contribution from this parliament. So
the situation is clear: there is a single objective but a choice of
means. Either we proceed using the community method, or we take a back
seat and watch while member states go via the route of an
intergovernmental treaty. It is clear that proceeding via this
Parliament would give European citizens a greater say in patent
legislation, an area which is so crucial to our economy.
A renegotiation of the European Patent Convention could be a worst-case
scenario for users of open source. While those who stood in opposition
to the original draft deserve congratulations and the opportunity to
enjoy their victory, they'll have little time to rest.
Comments (4 posted)
HP offers indemnification
On September 23, HP held a press conference in which it extended an
indemnification offer to its Linux customers. If you buy a Linux system
from HP, the company will take on any liability that may eventually be
incurred toward SCO for the use of Linux. HP will also take on defense
against lawsuits filed by SCO. All a customer has to do (beyond buying
the system from HP) is to have a support contract and refrain from making
changes to the code.
To some, this move appears to have vindicated SCO's claims. Certainly SCO
didn't miss the opportunity rush out an even stranger
than usual press release on the subject:
HP's actions this morning reaffirm the fact that enterprise end
users running Linux are exposed to legal risks. Rather than deny
the existence of substantial structural problems with Linux as many
Open Source leaders have done, HP is acknowledging that issues
exist and is attempting to be responsive to its customers' request
for relief. HP's actions are driving the Linux industry towards a
licensing program. In other words, Linux is not free.
It is classic SCO to claim that indemnification supports its claims, after
arguing for months that the lack of indemnification supports it claims.
The market, in any case, read things slightly differently; SCO's stock fell
almost 10% after HP's announcement and SCO's PR.
In fact, a different interpretation makes a great deal of sense. HP, as a
company, has certainly made its share of mistakes. But HP is smart enough
not to wander into the path of a company prone to billion-dollar lawsuits
without being sure of its ground. HP is a Unix licensee; it has everything
it needs to verify for itself whether Unix code has truly been copied into
Linux or not. The obvious conclusion is that HP has decided that it has
little to fear. It would appear that SCO's bluff has been called.
Comments (1 posted)
SCO to Red Hat: you have no complaint
Red Hat filed suit against the SCO group back at the beginning of August.
At that time,
SCO's
response was nothing if not aggressive:
Be advised that our response will likely include counterclaims for
copyright infringement and conspiracy. I must say that your
decision to file legal action does not seem conducive to the
long-term survivability of Linux.
That response was filed on September 15; thanks to Groklaw, the text
of SCO's response is now available online. It reads rather differently
than Darl McBride's preview had suggested. Rather than escalate the fight
with counterclaims and conspiracy charges, SCO is now trying to make the whole
thing go away.
The core of SCO's argument is that it has never actually threatened to sue
Red Hat, so Red Hat cannot ask for relief. There is nothing to be relieved
from.
There are no allegations that SCO has contacted Red Hat and
informed it that its product violates SCO's copyrights. Nor has SCO
done so. There are no allegations that SCO has conveyed to Red Hat
either expressly or implicitly that it intends to sue Red Hat to
enforce its copyrights. Nor has SCO done so. There are no
allegations that SCO has sued any other entity for infringement. -
Nor has SCO done so.
If you go back to SCO's response to the suit, the company quotes a letter
saying:
At the time of your letter, we had expected the possibility of a
global resolution of SCO's intellectual property claims against all
Linux-related companies that would have likely included Red Hat. This
effort has apparently stalled, through no fault of SCO.
SCO's Linux license
FAQ contains this statement:
All distributions of Linux 2.4 and later versions of the kernel
contain major infringments, regardless of whether Linux is being
used in a commercial or non-commercial environment.
Since Red Hat is unarguably a "Linux-related company," the first statement
above could certainly be read to imply the existence of intellectual
property claims against it. Since Red Hat's products include 2.4 and later
kernels, the second statement is a clear claim that Red Hat's products
contain "major infringements." But now SCO is trying to say that such
claims do not exist.
This quote is also worth noting:
Red Hat, however, has never had any license from SCO providing
access to SCO's trade secrets or other confidential information
and, to SCO's knowledge, has not stolen or otherwise
misappropriated any of SCO's trade secrets or confidential
information. Therefore, unlike companies that have contractual
obligations to SCO, Red Hat has no legal or factual basis for
apprehension of suit by SCO with respect to trade secrets or
confidential information it has licensed from SCO, and its claims
in Count II can be summarily dismissed.
So, if you work with Linux, and you have never signed a contract with SCO,
you should have little to worry about. SCO states here that it has never
claimed that Red Hat Linux (at least) infringes upon its copyrights, and
SCO states explicitly that Red Hat cannot have stolen its trade secrets.
If nothing else, SCO's statements serve as another warning against signing
contracts with that company.
SCO goes on to say that, even if Red Hat could prove that it is right to be
worried about being sued, the court still should not hear the case.
The previously filed SCO v. IBM Case addresses most, if not all, of
the issues of copyright infringement and misappropriation. If these
issues are decided against SCO in that case, then Red Hat's lawsuit
becomes unnecessary.
One wonders how the IBM case can handle "most, if not all, of the issues of
copyright infringement" when, as stated earlier in SCO's response, "There
are no allegations that SCO has sued any other entity for infringement.
Nor has SCO done so."
The IBM case is a breach of contract case which has nothing to do with
copyright infringement. One presumes that
the judge in the Red Hat case will notice that.
SCO claims that the rest of Red Hat's complaints (mostly variations on
violations of fair trade laws) should be dismissed because SCO's behavior
is a simple exercise of its first amendment ("freedom of speech") rights.
SCO's Public Statements fall outside the scope of the Lanham Act
and related state law claims and are protected under the First
Amendment to the U.S. Constitution. The Public Statements also
address or relate to pending or potential litigation and are
privileged under the common law doctrine of litigation immunity.
According to SCO, even its "Linux license" is actually speech related to
ongoing litigation, and thus protected. A footnote in SCO's filing makes
the interesting additional claim that "SCO has never asserted in any
statement that individual, non-corporate users of Linux may be liable to
SCO, or otherwise would need to purchase a right to-use-license."
The filing finishes out with this fun little argument:
Indeed, SCO's Public Statements are also part of a wider debate in
the technology and music industries about the scope of intellectual
property protection in a digital age. As open source software
development becomes prevalent and digital music can be downloaded
for free, many people are simply ignoring copyright and patent
laws. Many public commentators recognize this disintegration of
property rights as a danger to our economic system. In a small way,
SCO's Public Statements are part of this debate. This is an
additional factor that weighs in favor of holding SCO's Public
Statements as fully-protected speech, not subject to the Lanham Act
or associated state law claims. It would pervert the First
Amendment to allow the Lanham Act to chill broad debate about the
relative merits, and problems, with open source software.
Free software developers are, in other words, the moral equivalent of those
who distribute copyrighted music over the net. And it is SCO's right to
be "part of this debate" by making its claims against Linux.
The conclusion that comes from a thorough reading of SCO's response is
clear: SCO does not want this fight, and is doing what it can to make it go
away. This is not a surprising position; a company which has picked an
intellectual property fight with IBM has little need or desire for other
legal distractions. SCO's move for dismissal looks weak, however,
especially when one considers that it has contradicted many of its own
claims in public statements elsewhere. The Red Hat suit is not good news
for SCO, and it is unlikely to be shrugged off so easily.
SCO is also weakening any case it might have against any other
Linux-related company. After going to such lengths to state that Red Hat
has nothing to fear from SCO, and that the IBM case covers everything, SCO
will will have to find some truly compelling "new evidence" before it can
turn around and file another Linux-related lawsuit. As SCO backs away from
its increasingly indefensible claims of direct infringement, all it really
has left is a contract dispute with IBM. It is not surprising that SCO
wants to free itself of the Red Hat suit and concentrate on its one, big
fight.
Comments (16 posted)
Page editor: Jonathan Corbet
Security
Security news
A different kind of bad week
Another week, another email worm. Your editor initially wondered how he
had managed to get put on a Microsoft security mailing list, but it didn't
take too long to figure out what was really going on. A quick tweak to a
SpamAssassin rule made the visible part of the problem go away; after all,
very few messages of interest contain Microsoft executables anyway. But,
of course, the "Swen" worm continues to chew up bandwidth.
Swen seems to have two ways of attacking a system:
As we have warned many times in this space, Linux is not immune to worms
and viruses. We will almost certainly have a bad security day sooner or
later. But Swen is a classic Microsoft worm, and, perhaps, Linux users
have the right to feel just a little smug.
Exposed Linux systems with two-year-old vulnerabilities are rare. Fixing
problems is sufficiently easy, and Linux administrators are sufficiently
aware that vulnerabilities tend to be closed quickly. Keeping patching
levels high
as Linux expands into more desktop and consumer-oriented uses will be a
challenge, however. We have all the tools we need to keep such systems
current; it's mostly a matter of ensuring that those tools get used.
Imagine, however, that a widespread bug exists which, when exploited, could
allow the running of arbitrary code from malicious email. The variety of
mail user agents in the Linux world will restrict any such exploit to a
fraction of the deployed Linux systems. The number of distributions in use
will also make a universal exploit difficult. But, even if the attacker
succeeds in running code on a target system, that code will be unable to
kill the system's defensive processes, make "registry" (i.e. configuration
file) changes, or engage in most of the other unpleasant activities carried
out by Swen. To obtain that level of access to the system, the exploit
code would have to find and take advantage of another, different
vulnerability.
Then, there is the issue of convincing users to run a malicious executable
sent to them in the mail.
One of the real strengths of the Linux development model is that
it is highly unlikely to result in the creation of mail utilities which
allow the direct execution of programs received as email attachments. Any
developer or distributor who tried to release a tool with that sort of
vulnerability would not soon forget the reception they would get on the
net. There is simply no excuse for extending such trust to the world as a
whole. A Linux utility that was so trusting would be fixed within hours.
Microsoft systems have remained vulnerable - in the face of overwhelming
proof of the damage caused - for years.
Linux systems suffer from a constant stream of vulnerabilities, like other
systems out there. The real difference, perhaps, is that our problems get
fixed - almost always before they ever reach a point where they can be widely
exploited. As a happy result, it is, once again, not Linux systems which
are spamming the net with worm-laden email.
Comments (21 posted)
New vulnerabilities
gopherd: buffer overflow
| Package(s): | gopher |
CVE #(s): | CAN-2003-0805
|
| Created: | September 24, 2003 |
Updated: | September 24, 2003 |
| Description: |
The University of Minnesota gopherd daemon has a set of remotely exploitable buffer overflows which can allow an attacker to execute code as the "gopher" user. Both remaining gopher servers are advised to upgrade in the near future. |
| Alerts: |
|
Comments (3 posted)
hztty: buffer overflow vulnerability
| Package(s): | hztty |
CVE #(s): | CAN-2003-0783
|
| Created: | September 24, 2003 |
Updated: | September 24, 2003 |
| Description: |
hztty (a program for translating Chinese character encodings) has a pair of buffer overflow vulnerabilities which can be exploited by a local attacker. This problem is compounded on Debian systems by the fact that hztty is (unnecessarily) installed setuid root. Version 2.0-6 has the fix. |
| Alerts: |
|
Comments (none posted)
ipmasq: insecure packet filtering rules
| Package(s): | ipmasq |
CVE #(s): | CAN-2003-0785
|
| Created: | September 22, 2003 |
Updated: | September 24, 2003 |
| Description: |
ipmasq is a package which simplifies configuration of Linux IP
masquerading, a form of network address translation which allows a
number of hosts to share a single public IP address. Due to use of
certain improper filtering rules, traffic arriving on the external
interface addressed for an internal host would be forwarded,
regardless of whether it was associated with an established
connection. This vulnerability could be exploited by an attacker
capable of forwarding IP traffic with an arbitrary destination address
to the external interface of a system with ipmasq installed. |
| Alerts: |
|
Comments (none posted)
openssh: multilple PAM vulnerabilities in Portable OpenSSH versions 3.7p1
and 3.7.1p1
| Package(s): | openssh |
CVE #(s): | |
| Created: | September 23, 2003 |
Updated: | October 1, 2003 |
| Description: |
Portable OpenSSH versions 3.7p1 and 3.7.1p1 contain multiple
vulnerabilities in the new PAM code. At least one of these bugs is remotely
exploitable (under a non-standard configuration, with privsep disabled).
See this advisory for details. |
| 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)
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)
perl-MailTools: remote command execution
| Package(s): | MailTools |
CVE #(s): | CAN-2002-1271
|
| Created: | November 5, 2002 |
Updated: | September 19, 2003 |
| Description: |
The SuSE Security Team reviewed critical Perl modules, including the
Mail::Mailer package. This package contains a security hole which allows
remote attackers to execute arbitrary commands in certain circumstances.
This is due to the usage of mailx as default mailer which allows commands
to be embedded in the mail body.
Note that mail processing programs which use this package can be affected by this vulnerability; in particular, SpamAssassin is vulnerable if you use the -r or -w flags.
|
| Alerts: |
|
Comments (none posted)
OpenSSH: buffer management error
| Package(s): | OpenSSH |
CVE #(s): | CAN-2003-0693
|
| Created: | September 16, 2003 |
Updated: | October 1, 2003 |
| Description: |
All versions of
OpenSSH's sshd prior to 3.7.1 contain a buffer management error. It is
uncertain whether these errors are exploitable. Note that most distributors have issued two updates, since the first fix was found to be incomplete.
See the second advisory for details.
CAN-2003-0693 |
| Alerts: |
|
Comments (none posted)
Multiple-use vulnerability in Safe.pm
| Package(s): | Safe.pm |
CVE #(s): | CAN-2002-1323
|
| Created: | October 9, 2002 |
Updated: | February 20, 2004 |
| Description: |
usePerl has a
description of a vulnerability in the Safe.pm Perl module. It seems
that if a Safe compartment is used more than once, it ceases to be safe.
The problem is fixed in Safe 2.08. |
| Alerts: |
|
Comments (none posted)
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)
apache: multiple vulnerabilities in Apache HTTP server
| Package(s): | apache |
CVE #(s): | CAN-2003-0192
CAN-2003-0253
CAN-2003-0254
|
| Created: | July 11, 2003 |
Updated: | September 22, 2003 |
| Description: |
The Apache Software Foundation and
the Apache HTTP Server Project have announced
the release of the Apache HTTP Server 2.0.47. This release fixes four
security vulnerabilities:
- Certain sequences of per-directory renegotiations and the
SSLCipherSuite directive being used to upgrade from a weak ciphersuite to
a strong one could result in the weak ciphersuite being used in place of
the strong one. [CAN-2003-0192]
- Certain errors returned by accept() on rarely accessed ports could
cause temporal denial of service, due to a bug in the prefork MPM. [CAN-2003-0253]
- Denial of service was caused when target host is IPv6 but ftp proxy
server can't create IPv6 socket. [CAN-2003-0254]
- The server would crash when going into an infinite loop due to too
many subsequent internal redirects and nested subrequests. [VU#379828]
|
| Alerts: |
|
Comments (none posted)
autorespond: buffer overflow
| Package(s): | autorespond |
CVE #(s): | CAN-2003-0654
|
| Created: | August 18, 2003 |
Updated: | October 1, 2003 |
| Description: |
Christian Jaeger discovered a buffer overflow in autorespond, an email
autoresponder used with qmail. This vulnerability could potentially
be exploited by a remote attacker to gain the privileges of a user who
has configured qmail to forward messages to autorespond. This
vulnerability is currently not believed to be exploitable due to
incidental limits on the length of the problematic input, but there
may be situations in which these limits do not apply.
CAN-2003-0654 |
| Alerts: |
|
Comments (none posted)
bind buffer overflow vulnerability in DNS resolver libraries
| Package(s): | bind glibc |
CVE #(s): | CAN-2002-0651
CAN-2002-0684
|
| Created: | July 8, 2002 |
Updated: | October 1, 2003 |
| Description: |
The BIND 4.9.8-OW2 patch and BIND 4.9.9 release (and thus 4.9.9-OW1)
include fixes for a libc related vulnerability which does not
affect Linux. Updates from
the Internet Software Consortium (ISC)
are available from here.
No release or branch of Openwall GNU/*/Linux (Owl) is known to be
affected, due to Olaf Kirch's fixes for this problem getting into the
GNU C library more than two years ago.
Unfortunatly that does not mean that Linux systems are not vulnerable.
Similar code, without Olaf Firch's fixes,
is in the glibc getnetbyXXX functions.
These functions are described in the SuSE alert as
"
used by very few applications only, such as ifconfig and ifuser,
which makes exploits less likely."
CERT Advisory: CA-2002-19
Buffer Overflow in Multiple DNS Resolver Libraries
CAN-2002-0651
CAN-2002-0684 |
| Alerts: |
|
Comments (1 posted)
Canna server: exploitable buffer overrun
| Package(s): | canna |
CVE #(s): | CAN-2002-1158
CAN-2002-1159
|
| Created: | December 10, 2002 |
Updated: | October 1, 2003 |
| Description: |
Canna is a kana-kanji conversion server which is necessary for Japanese
language character input.
A buffer overflow bug in the Canna server up to and including version 3.5b2
allows a local user to gain the privileges of the user 'bin' which could
lead to further exploits. The Common Vulnerabilities and Exposures project
(cve.mitre.org) has assigned the name CAN-2002-1158 to this issue.
A lack of validation of requests has been found that affects Canna version
3.6 and earlier. A malicious remote user could exploit this vulnerability
to leak information, or cause a denial of service attack. (CAN-2002-1159)
See also
http://canna.sourceforge.jp/sec/Canna-2002-01.txt
CAN-2002-1158
CAN-2002-1159 |
| Alerts: |
|
Comments (none posted)
eroaster: insecure temporary file
| Package(s): | eroaster |
CVE #(s): | CAN-2003-0656
|
| Created: | August 19, 2003 |
Updated: | October 1, 2003 |
| Description: |
A vulnerability was discovered in eroaster where it does not take any
security precautions when creating a temporary file for the lockfile. This
vulnerability could be exploited to overwrite arbitrary files with the
privileges of the user running eroaster.
CAN-2003-0656 |
| 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)
exim: buffer overflows
| Package(s): | exim exim-tls |
CVE #(s): | CAN-2003-0743
|
| Created: | September 4, 2003 |
Updated: | October 1, 2003 |
| Description: |
A buffer overflow exists in exim, which is the standard mail transport
agent in Debian. By supplying a specially crafted HELO or EHLO
command, an attacker could cause a constant string to be written past
the end of a buffer allocated on the heap. This vulnerability is not
believed at this time to be exploitable to execute arbitrary code.
CAN-2003-0743 |
| 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)
fdclone: insecure temporary directory
| Package(s): | fdclone |
CVE #(s): | CAN-2003-0596
|
| Created: | July 23, 2003 |
Updated: | October 1, 2003 |
| Description: |
fdclone creates a temporary directory in /tmp as a workspace.
However, if this directory already exists, the existing directory is
used instead, regardless of its ownership or permissions. This would
allow an attacker to gain access to fdclone's temporary files and
their contents, or replace them with other files under the attacker's
control.
CAN-2003-0596 |
| 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)
libpam-smb: exploitable buffer overflow
| Package(s): | libpam-smb, pam-smb |
CVE #(s): | CAN-2003-0686
|
| Created: | August 26, 2003 |
Updated: | October 1, 2003 |
| Description: |
libpam-smb is a PAM authentication module which makes it possible to
authenticate users against a password database managed by Samba or a
Microsoft Windows server. If a long password is supplied, this can cause a
buffer overflow which could be exploited to execute arbitrary code with the
privileges of the process which invokes PAM services. See this advisory for more information.
CAN-2003-0686 |
| Alerts: |
|
Comments (1 posted)
libpng, libpng3: buffer overflow
| Package(s): | libpng, libpng3 |
CVE #(s): | CAN-2002-1363
|
| Created: | December 19, 2002 |
Updated: | July 14, 2004 |
| Description: |
Glenn Randers-Pehrson discovered a problem in connection with 16-bit
samples from libpng, an interface for reading and writing PNG
(Portable Network Graphics) format files. The starting offsets for
the loops are calculated incorrectly which causes a buffer overrun
beyond the beginning of the row buffer. |
| Alerts: |
|
Comments (none posted)
lynx: CRLF injection vulnerability
| Package(s): | lynx |
CVE #(s): | CAN-2002-1405
|
| Created: | November 19, 2002 |
Updated: | October 1, 2003 |
| Description: |
If lynx is given a url with some special characters on the command line, it
will include faked headers in the HTTP query. This feature can be used to
force scripts (that use Lynx for downloading files) to access the wrong
site on a web server with multiple virtual hosts.
CAN-2002-1405 |
| Alerts: |
|
Comments (none posted)
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)
mindi: insecure file creations
| Package(s): | mindi |
CVE #(s): | CAN-2003-0617
|
| Created: | September 2, 2003 |
Updated: | October 1, 2003 |
| Description: |
Mindi versions prior to 0.86 creates files in /tmp which could allow local
user to overwrite arbitrary files.
CAN-2003-0617 |
| Alerts: |
|
Comments (none posted)
mpg123 - buffer overflow
| Package(s): | mpg123 |
CVE #(s): | CAN-2003-0577
|
| Created: | July 16, 2003 |
Updated: | September 30, 2003 |
| Description: |
The mpg123 utility contains a buffer overflow vulnerability which can allow an attacker to execute arbitrary code by way of a malicious MP3 file. |
| 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)
netris: buffer overflow
| Package(s): | netris |
CVE #(s): | CAN-2003-0685
|
| Created: | August 18, 2003 |
Updated: | October 1, 2003 |
| Description: |
Shaun Colley discovered a buffer overflow vulnerability in netris, a
network version of a popular puzzle game. A netris client connecting
to an untrusted netris server could be sent an unusually long data
packet, which would be copied into a fixed-length buffer without
bounds checking. This vulnerability could be exploited to gain the
priviliges of the user running netris in client mode, if they connect
to a hostile netris server.
CAN-2003-0685 |
| 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)
pam-pgsql: format string vulnerability
| Package(s): | pam-pgsql |
CVE #(s): | CAN-2003-0672
|
| Created: | August 11, 2003 |
Updated: | October 1, 2003 |
| Description: |
Florian Zumbiehl reported a vulnerability in pam-pgsql whereby the
username to be used for authentication is used as a format string when
writing a log message. This vulnerability may allow an attacker to
execute arbitrary code with the privileges of the program requesting
PAM authentication.
CAN-2003-0672 |
| Alerts: |
|
Comments (none posted)
perl: cross site scripting vulnerability in CGI.pm module
| Package(s): | perl |
CVE #(s): | CAN-2003-0615
|
| Created: | July 29, 2003 |
Updated: | October 1, 2003 |
| Description: |
obscure@eyeonsecurity.org reported a
cross site scripting vulnerability in the CGI.pm perl module. This module
is used to facilitate the creation of web forms and is part of the
perl-modules RPM package.
CAN-2003-0615 |
| Alerts: |
|
Comments (none posted)
PHP: vulnerability in mail function
| Package(s): | php |
CVE #(s): | CAN-2002-0985
CAN-2002-0986
|
| Created: | November 13, 2002 |
Updated: | October 1, 2003 |
| Description: |
Two vulnerabilities exists in the mail() PHP function. The first one allows
the execution of any program/script bypassing safe_mode restriction, the
second one may give an open-relay script if the mail() function is not
carefully used in PHP scripts. See this Bugtraq
report for more details. Note that this is a different vulnerability than the previous PHP mail() problem, which affected versions through 4.1.0.
CAN-2002-0985
CAN-2002-0986 |
| Alerts: |
|
Comments (none posted)
phpgroupware - cross-site scripting and other exploits
| Package(s): | phpgroupware |
CVE #(s): | CAN-2003-0504
CAN-2003-0582
|
| Created: | July 16, 2003 |
Updated: | October 1, 2003 |
| Description: |
Several vulnerabilities were discovered in all versions of phpgroupware
prior to 0.9.14.006. This latest version fixes an exploitable condition in
all versions that can be exploited remotely without authentication and can
lead to arbitrary code execution on the web server. This vulnerability is
being actively exploited.
Version 0.9.14.005 fixed several other vulnerabilities including cross-site
scripting issues that can be exploited to obtain sensitive information such
as authentication cookies.
See this
Security Corportation report for more information.
CAN-2003-0504
CAN-2003-0582 |
| Alerts: |
|
Comments (none posted)
pine: remote exploits
| Package(s): | pine |
CVE #(s): | CAN-2003-0720
CAN-2003-0721
|
| Created: | September 11, 2003 |
Updated: | September 17, 2003 |
| Description: |
Pine, developed at the University of Washington, is a tool for reading,
sending, and managing electronic messages (including mail and news).
A buffer overflow exists in the way unpatched versions of Pine prior to
4.57 handle the 'message/external-body' type. The Common Vulnerabilities
and Exposures project has assigned the name
CAN-2003-0720 to this issue.
An integer overflow exists in the Pine MIME header parsing in versions
prior to 4.57. The Common Vulnerabilities and Exposures project
has assigned the name
CAN-2003-0721 to this issue.
Both of these flaws could be exploited by a remote attacker sending a
carefully crafted email to the victim that will execute arbitrary code when
the email is opened using Pine. |
| Alerts: |
|
Comments (1 posted)
postfix: denial of service vulnerabilities