Date: Fri, 17 Oct 2003 22:30:10 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Conectiva Updates <secure@...ectiva.com.br>
Cc: bugtraq@...urityfocus.com
Subject: Re: [CLA-2003:765] Conectiva Security Announcement - ircd


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.

Powered by blists - more mailing lists