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 attachment 86611 [details, diff] 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. ***