Bugzilla Bug 132353

RIPd accepts RIPv1 RESPONSE packets and updates its routing state, even when
RIPv2 authentication has been enabled.

This can occur where:

- both version 1 and 2 are allowed
- no version control is specified (default version control allows both)

Best practice ought to be to at least to refuse to update routing state via
unauthenticated packets when authentication is enabled, however we can still
honour REQUESTs safely.


The RFCs suggest disabling RIPv1 altogether when v2 authentication

Patches at URL, please bump ?

bumped to 0.98.6. 
I didn't had the time to test it on my router yet.

Arches please test and mark stable.

I've installed it on my router (x86) and it works as expected.
However, I don't use RIP, only BGP.

This sounds buggy.

I got bgp, ospf, ospf6 and ripv2 running on my hppa and rip doesn't work
anymore.

My config being the following :

router rip
 version 2
 network eth1
 passive-interface eth0

I've this in my debug :
RIP: RECV packet from 172.21.1.250 port 520 on eth1
RIP: RECV RESPONSE version 2 packet size 44
RIP:   172.24.0.0/24 -> 0.0.0.0 family 2 tag 0 metric 1
RIP:   172.24.0.0/16 -> 0.0.0.0 family 2 tag 0 metric 1
RIP: RIPv2 dropped because authentication enabled

after receiving the following packet :
IP (tos 0x0, ttl  64, id 25922, offset 0, flags [none], proto: UDP (17),
length: 72) 172.21.1.250.520 > 172.21.1.255.520: [udp sum ok] 
        RIPv2, Response, length: 44, routes: 2
          AFI: IPv4:      172.24.0.0/24, tag 0x0000, metric: 1, next-hop: self
          AFI: IPv4:      172.24.0.0/16, tag 0x0000, metric: 1, next-hop: self
        0x0000:  0202 0000 0002 0000 ac18 0000 ffff ff00
        0x0010:  0000 0000 0000 0001 0002 0000 ac18 0000
        0x0020:  ffff 0000 0000 0000 0000 0001




And of course the route doesn't get used. This was working fine before.

Maybe I'm missing something but this sounds wrong.

Back to ebuild to resolve this.

Alin any comments?

try to add "no ip rip authentication" to your configuration.

I went back to 0.98.5-r3 and it worked again.

I receive the correct debug :

RIP: SEND UPDATE to eth1 ifindex 4
RIP: multicast announce on eth1 
RIP: update routes on interface eth1 ifindex 4
RIP: RECV packet from 172.21.1.250 port 520 on eth1
RIP: RECV RESPONSE version 2 packet size 44
RIP:   172.24.0.0/24 -> 0.0.0.0 family 2 tag 0 metric 1
RIP:   172.24.0.0/16 -> 0.0.0.0 family 2 tag 0 metric 1


I've looked to disable authentication of course but by default it's disabled.

hulk(config-if)# no ip rip authentication 
% Command incomplete.
hulk(config-if)# no ip rip authentication key-chain 
  LINE  name of key-chain
  <cr>  
hulk(config-if)# no ip rip authentication key-chain 
hulk(config-if)# no ip rip authentication mode 
  md5   Keyed message digest
  text  Clear text authentication
  <cr>  
hulk(config-if)# no ip rip authentication mode 
hulk(config-if)# no ip rip authentication string 
  LINE  Authentication string
  <cr>  
hulk(config-if)# no ip rip authentication string 
hulk(config-if)# 


After this, my config was unchanged. Will try with the -0.98.6 once it's merged
again :)

I'm discussing with the quagga devs.

Normally, we should see that authentication is set to md5 by default.
However this doesn't appear in sh run and in the file when you save it.

The default authentication has been changed in this release.


Alin, as you sugested, issuing "no ip rip authentication mode" on the interface
fix the issue and my routes get updated. However, accoring quagga devs, it
should display it in the config.


I'm still investigating right now. A workaround would be to change the default
authentication to RIP_NO_AUTH in rip_interface_new() and rip_interface_reset().
This way, not having authentication information in the config match what we
expect.

Yeah, I've saw it too. The strange thing is 0.98.5 has the exact same
rip_interface_new() and rip_interface_reset().
Please change default authentication set in those function to RIP_NO_AUTH and
tell me if it worked.

Created an attachment (id=86611) [details]
Always show interfaces in ripd

This is the diff that paul from #quagga@freenode came with.

It's working fine and fully fix all the aspects of the issue.

Fixed in 0.98.6-r1. (thanks for your help, Guy!)
Arches, please do your thing.

Working like a charm on hppa.

Its a nice pizza pie of stablility on x86. (^.^) I need to not play mario while
commiting.

alpha stable.

ppc stable

I tend to vote no, I don't understand it :)

Put it simple, the RIP daemon (responsible with route exchange with other RIP
routers) could accept IP routes without properly authenticate the source of
those routes.
It is pretty big if your network works on RIP. This protocol is the simplest of
its kind, much more simpler to setup than OSPF or BGP, therefore I assume the
RIP users are more numerous than other the users of other 2 protocols put
together.

Also note that 0.98.6 don't solve only this security issue, it also solve a BGP
DoS problem (see http://www.quagga.net):
  - bgpd Telnet Interface DoS (OSVDB ID 25245).

Please issue a GLSA on this one.

(In reply to comment #18)
> Please issue a GLSA on this one.
Ok, you'Ve got my vote: yes for a glsa

i would vote a half-no :
- the configuration needed is very specific (unless i'm wrong)
- internet routing is known to be sensitive : RIPd administrators are usually
very advanced users. This kind of configuration might not happen.
- the bug says that RFC discourages such a configuration.

Even the BGP bug alone (http://www.osvdb.org/displayvuln.php?osvdb_id=25245)
would be more than enough to justify a GLSA.

Lets have a GLSA on this one.

I didn't really get a grip on the version bump; so 0.98.6-r1 is supposed to fix
all three CVEs 2223, 2224 and 2276?

Sorry for spamming here, but this is hard to figure out with the sources
supplied. To me it looks like the default ripd configuration is to allow RIPv1
_and_ RIPv2, even if v2 MD5 auth is on. Thus the problem would be that v1 is
not automatically disabled once authentication has been configured?

GLSA 200605-15

Thanks everybody

*** Bug 134003 has been marked as a duplicate of this bug. ***