Mailing List Archive

More information on the recent remote DoS in vty.c?
Hello

With some delay due to holidays I started to prepare the latest
quagga release for Debian when I stumbled across the following
changelog entry:

2003-10-15 Jay Fenlason <fenlason at redhat.com>

* lib/vty.c: (vty_telnet_option) Remote DoS exists if a telnet
end-sub-negotation is sent when no sub-negotation data has been
sent. Return immediately if no sub-negotation is in progress.
(vty_read) do not attempt to process options if no sub-negotation
is in progress.

I do not know what a sub-negotiation is, so could anybody tell if this
is a way to DoS an arbitrary "normal" quagga installation? (with
management ports open to the internet maybe?) Which impact would this DoS
have? I mainly ask because I will have to propose the release of a
Debian Security Advisory if the risk is too high.

bye,

-christian-
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
On Thu, 13 Nov 2003, Christian Hammers wrote:

> I do not know what a sub-negotiation is,

I made a mistake in the changelog it, it should be "sub-command".

> so could anybody tell if this is a way to DoS an arbitrary "normal"
> quagga installation? (with management ports open to the internet
> maybe?)

Yes. Its a potential remote DoS triggerable by anyone who can connect
to vty ports.

> Which impact would this DoS have?

A crash of the process concerned.

> I mainly ask because I will have to propose the release of a Debian
> Security Advisory if the risk is too high.
>
> bye,
>
> -christian-

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
You can be replaced by this computer.
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
On Thu, Nov 13, 2003 at 07:48:22AM +0000, Paul Jakma wrote:
> Yes. Its a potential remote DoS triggerable by anyone who can connect
> to vty ports.
>
> > Which impact would this DoS have?
>
> A crash of the process concerned.

I know, this is always a kind of disgrace but wouldn't it be better
to put a "SECURITY WARNING: Please upgrade if you have ports open to
the net or disable them at all and use ssh!" on the homepage?

(If someones backbone fails due to a DoS and in the NEWS on the homepage
is a big bold "Warning" for some compile issues but do no mention about
a remote DoS nor a bugtraq warning etc. we get a very angry mail on
bugtraq and you can forget Quagga for the next couple of years in the
big ISP league due to bad reputation...)

bye,

-christian-
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
Hello

On Thu, Nov 13, 2003 at 09:51:19AM +0000, Paul Jakma wrote:
> > (If someones backbone fails due to a DoS and in the NEWS on the
> > homepage is a big bold "Warning" for some compile issues but do no
> > mention about a remote DoS nor a bugtraq warning etc. we get a very
> > angry mail on bugtraq and you can forget Quagga for the next couple
> > of years in the big ISP league due to bad reputation...)
>
> Indeed. This is the first security fix I've dealt with, so forgive me
> if i havnt dealt with it correctly.
>
> What would you advise?

- Under News or a "Security" section make an entry for this where the
exact impact and workaround is describes (you know admins sometimes
takes a quick look at the page and want to see as fast as possible if
there were severy bugfixes (security or not) that require them to
upgrade.

- For the same reasons put a note in the Downloads section that
the use of versions prior to 0.96.4 is discouraged due to security
bugs. (upgrade the "last stable version" there btw.)

- Write a short note to bugtraq so that all admins who use linux routers
get aware of the bug.
(even bad news have a good side, they make the project more known *g*)

Oh and check Zebra if it suffers from the same problem.
Writing "The Quagga team found a long consisting bug in the Zebra
routing suite from which its successor, the Quagga project also suffers"
sounds better (only if it's true, of course) ;-)

bye,

-christian-
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
On Thu, Nov 13, 2003 at 10:20:39AM +0000, Paul Jakma wrote:
> I think I will write up an email to disclose the vulnerability,
> advise on impact, workaround and resolution and send it to all the
> relevant lists. Which bugtraq list should i send to do you know? (not
> the general bugtraq list, right?).

A mail to the normal bugtraq address "bugtraq@securityfocus.com" should
work.

bye,

-christian-
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
On Thu, Nov 13, 2003 at 10:20:39AM +0000, Paul Jakma wrote:
> I think I will write up an email to disclose the vulnerability,
> advise on impact, workaround and resolution and send it to all the
> relevant lists. Which bugtraq list should i send to do you know? (not
> the general bugtraq list, right?).

Oh and it would be especially nice if you would make a little patch
so that admins are not forced to upgrade to the latest version (due to
fear that the new features could break something else).

Maybe you could even write a patch for zebra, too?

bye,

-christian-
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
On Thu, 13 Nov 2003, Christian Hammers wrote:

> Oh and it would be especially nice if you would make a little patch
> so that admins are not forced to upgrade to the latest version (due
> to fear that the new features could break something else).
>
> Maybe you could even write a patch for zebra, too?

RedHat already did that :)

I'll reference the RH advisory and bugzilla with the patch in the
advisory.

> bye,
>
> -christian-

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
There are new messages.
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
On Thu, 13 Nov 2003, Paul Jakma wrote:

> I made a mistake in the changelog it, it should be "sub-command".

No, you confused me, it is sub-negotiation. See the telnet RFC(s).

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
Did you hear that there's a group of South American Indians that worship
the number zero?

Is nothing sacred?
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
Hi

On Thu, Nov 13, 2003 at 11:00:58AM +0000, Paul Jakma wrote:
> RedHat already did that :)
>
> I'll reference the RH advisory and bugzilla with the patch in the
> advisory.

BTW: We're speaking about one problem, what about the second one, RedHat
mentions in the just released advisory? Does it apply to Quagga, too?
If not you should explicitly say that as people wo run quagga will
surely read the zebra, too, and will start wondering like I do now...

: Jonny Robertson reported that Zebra can be remotely crashed if a Zebra
: password has been enabled and a remote attacker can connect to the Zebra
: telnet management port. The Common Vulnerabilities and Exposures
: project (cve.mitre.org) has assigned the name CAN-2003-0795 to this
: issue.
:
: Herbert Xu reported that Zebra can accept spoofed messages sent on the
: kernel netlink interface by other users on the local machine. This
: could lead to a local denial of service attack. The Common
: Vulnerabilities and Exposures project (cve.mitre.org) has assigned the
: name CAN-2003-0858 to this issue.

bye,

-christian-
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
On Thu, 13 Nov 2003, Christian Hammers wrote:

> BTW: We're speaking about one problem, what about the second one,
> RedHat mentions in the just released advisory? Does it apply to
> Quagga, too? If not you should explicitly say that as people wo run
> quagga will surely read the zebra, too, and will start wondering
> like I do now...

Yes indeed.

I need further details on the second problem, I know what RedHat's
fix is for it, I just dont understand why it is needed. I'm trying to
get in touch with the RH person who originally contacted me about the
vty problem to try find out why the second problem is in fact a
problem.

(the RH fix is to check the nl_pid field of incoming netlink messages
and discard any which are not 0. however, AFAIK, in order to send
messages to netlink listeners one must have privileges. Which
suggests this perhaps isnt a real problem).

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
All great ideas are controversial, or have been at one time.
Re: More information on the recent remote DoS in vty.c? [ In reply to ]
Replying to myself.

On Thu, 13 Nov 2003, Paul Jakma wrote:

> (the RH fix is to check the nl_pid field of incoming netlink
> messages and discard any which are not 0. however, AFAIK, in order
> to send messages to netlink listeners one must have privileges.

Well, this is only true for multicast netlink messages. unicast
requires 0 privileges on the part of the sender. (fun). The following
fix from RedHat is in CVS, anyone running zebra on boxes with
untrusted users should consider applying below until 0.96.5 comes
out.

---------------------
PatchSet 370
Date: 2003/11/17 10:31:01
Author: paul
Branch: HEAD
Tag: (none)
Log:
2003-11-17 Jay Fenlason <fenlason@redhat.com>

* zebra/rt_netlink.c: netlink_parse_info() ignore messages which are
not from kernel. Reported to RH by Herbert Xu. See
http://rhn.redhat.com/errata/RHSA-2003-307.html and CAN-2003-0858.

Members:
zebra/rt_netlink.c:1.15->1.16

Index: quagga/zebra/rt_netlink.c
diff -u quagga/zebra/rt_netlink.c:1.15 quagga/zebra/rt_netlink.c:1.16
--- quagga/zebra/rt_netlink.c:1.15 Mon Sep 29 20:54:54 2003
+++ quagga/zebra/rt_netlink.c Mon Nov 17 10:31:01 2003
@@ -290,6 +290,13 @@
nl->name, msg.msg_namelen);
return -1;
}
+
+ /* JF: Ignore messages that aren't from the kernel */
+ if ( snl.nl_pid != 0 )
+ {
+ zlog ( NULL, LOG_ERR, "Ignoring message from pid %u", snl.nl_pid );
+ continue;
+ }

for (h = (struct nlmsghdr *) buf; NLMSG_OK (h, status);
h = NLMSG_NEXT (h, status))

regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam@dishone.st
Fortune:
The notion of a "record" is an obsolete remnant of the days of the 80-column
card.
-- Dennis M. Ritchie