[CLA-2003:765] Conectiva Security Announcement - ircd

[Conectiva Updates]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --------------------------------------------------------------------------
CONECTIVA LINUX SECURITY ANNOUNCEMENT
- --------------------------------------------------------------------------

PACKAGE : ircd
SUMMARY : Local denial of service vulnerability
DATE : 2003-10-17 15:46:00
ID : CLA-2003:765
RELEVANT
RELEASES : 9

- -------------------------------------------------------------------------

DESCRIPTION
The ircd package contains an Internet Relay Chat (IRC) server[1].

Piotr Kucharski reported[2] a buffer overflow vulnerability that may
allow an attacker to crash the ircd server, thus causing a denial of
service condition. The package released with this advisory includes a
patch[3] that fixes the problem.

The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2003-0864[4] to this issue.


SOLUTION
All users of the ircd package should upgrade.

IMPORTANT: After the update, it is necessary to restart the ircd
server manually in order to load the new, non-vulnerable version. In
order to do that, please run the following command as ro

# /sbin/service ircd restart


REFERENCES
1.ftp://ftp.irc.org/irc/server
2.http://www.securityfocus.com/archive/1/341099
3.http://akson.sgh.waw.pl/~chopin/ircd...es/m_join.diff
4.http://cve.mitre.org/cgi-bin/cvename...=CAN-2003-0864


UPDATED PACKAGES
ftp://atualizacoes.conectiva.com.br/...0_2cl.i386.rpm
ftp://atualizacoes.conectiva.com.br/...90_2cl.src.rpm


ADDITIONAL INSTRUCTIONS
The apt tool can be used to perform RPM packages upgrades:

- run: apt-get update
- after that, execute: apt-get upgrade

Detailed instructions reagarding the use of apt and upgrade examples
can be found at http://distro.conectiva.com.br/atual...#apt?idioma=en

- -------------------------------------------------------------------------
All packages are signed with Conectiva's GPG key. The key and instructions
on how to import it can be found at
http://distro.conectiva.com.br/segur...ave/?idioma=en
Instructions on how to check the signatures of the RPM packages can be
found at http://distro.conectiva.com.br/segur...ica/?idioma=en

- -------------------------------------------------------------------------
All our advisories and generic update instructions can be viewed at
http://distro.conectiva.com.br/atualizacoes/?idioma=en

- -------------------------------------------------------------------------
Copyright (c) 2003 Conectiva Inc.
http://www.conectiva.com

- -------------------------------------------------------------------------
subscribe: conectiva-updates-subscribe@papaleguas.conectiva.com.br
unsubscribe: conectiva-updates-unsubscribe@papale...nectiva.com.br
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/kCr442jd0JmAcZARAmHEAJ4tbplU1AtkDnTHujxJ/a0pW8tyXQCg65z5
FNengchSmW4c7fYsrR+LIMg=
=4ESy
-----END PGP SIGNATURE-----

[Florian Weimer]

Conectiva Updates wrote:

> PACKAGE : ircd
> SUMMARY : Local denial of service vulnerability

Actually it's *remote* in the usual terminology on this list.

Let me elaborate a bit because this shows an important point which is
often neglected by advisory writers.

Many of the interesting protocols (SMTP, DNS, NetNews, but also IRC)
create an application-specific network on top of the IP network (or
another kind of underlying transport network). If a protocol
implementation has a security defect, there are two possibilities:

o the application network can relay the attack

o the application network does NOT relay the attack

Let's look at typical SMTP server defects. A defect in the SMTP HELO
argument parser can only be exploited by a server that passes mail to
the defective server directly over SMTP (which means that you only have
to patch your incoming mail relays to stop attacks from the Internet).
However, a defective message header parser code can likely be exploited
by anyone because it passes through mail relays. Patching your incoming
relays is not very helpful in such cases, and you'll probably start with
the final destination servers. (Since anybody can run an SMTP server
and lure others into sending mail to it, defects in the server-to-server
communcation are not less severe than other implementation errors.)

For another example, let's suppose that there is a security defect in an
IRC client. Attackers might be able to send requests to the broken
client across the network, or it might be necessary that the server
administrator has modified the server software specifically to exploit
this defect. Obviously, defects of the first kind are far more severe
because attackers can more easily fullfil the requirements. If we look
at IRC servers, there are even more possibilities: directly connected
clients, directly connected servers, any client, or any server on the
network might be able carry out attacks. Usually, there is some kind of
trust relationship between server operators, so the server-to-server
exploits are considered less severe.

If you need more examples, try to figure out the attack requirements for
the last few BIND resolver vulnerabilities. It's a nice exercise.

As you can see, the impact of a security defect can vary, depending on
the ability of the application network to relay attacks. Therefore,
it's extremely important to accurately describe the attack requirements
in this context. Without such a description, system administrators
cannot adequately plan for recovery from a vulnerbility because it's not
clear which systems have to be addressed first. If you assume there
aren't many administrators who can make use of this information, you are
wrong. Not everyone who isn't able to immediately roll out a patch to
tens of thousands of machines for which he is responsible in some way or
other is a moron who doesn't care about security and, as a result,
deserves anything what he receives. Unfortunately, you can't even buy
the necessary information. For example, wgile Slammer was bringing down
entire networks, all alerts stilled called for patching the servers,
even though it was too late for that. A more helpful suggestion would
have been to power-cycle entire floors with Slammer-infected hosts and
non-critical systems (a technique at least one company applied as a
measure of last resort).

But I digress, so back to the vulnerability at hand. When IRC server
developers talk about "local vulnerabilities" vs. "remote
vulnerabilities", they mean the distinction given above (exploit over
local connection vs. exploit over the IRC network). In the terminology
with which most readers of this list are familiar, both attack vectors
are "remote". "Local" attacks come from authenticated users or users
with shell access.

PS: irc2.10.3p4 fixed additional forced crash bugs besides the JOIN
issue. The JOIN bug is just the only one that is/was actively
exploited.