A vulnerability has been reported in iputils, which can be exploited by malicious people to cause a DoS (Denial of Service). The vulnerability is caused due to an unspecified error within rarpd when handling certain packets. This can be exploited to stop the rarpd from responding by sending specially crafted replies. Solution: Use in trusted network environments only. Provided and/or discovered by: Reported in a SUSE advisory.
cc'ing herd and setting status (It's upstream, but it seems Suse has already fixed it: http://lists.suse.com/archive/suse-security-announce/2007-Apr/0007.html )
According to SUSE changelog: - ipsec-tools remote denial of service A bug in the IKE daemon "racoon" allowed remote attackers to shut down established tunnels (CVE-2007-1841). Somehow Secunia missed the CVE reference. *** This bug has been marked as a duplicate of bug 173219 ***
jaervosz: wrt this is not about the "ipsec-tools remote DoS" but the "rarpd minor DoS". Given that rarpd is part of iputils, this issue still stands I think.
Oh, it was further down in the Changelog. I mixed up iputils and ipsec-tools somehow. Thanks for pointing this out Pierre. base-system please advise and bump as necessary.
Suse has already patched this.
the rarpd in iputils is fine ... the suse report is talking about net-misc/rarpd
i'm not sure we're affected ... the code in question is based on changes that suse wrote when updating from libnet-1.0 to libnet-1.1 ... either way, rarpd-1.1-r3 in portage with all of SuSE's fixes
oops, didnt mean to close
Thx for the clarification Vapier. If someone have the time I have a POC to test wether we're affected before calling arches, just poke me.
(In reply to comment #9) > Thx for the clarification Vapier. > > If someone have the time I have a POC to test wether we're affected before > calling arches, just poke me. > i fail to perform any interesting thing with this PoC and rarpd-1.1-r2. The rarpd daemon memory doesn't grow at all, and it goes on responding. (either the targetted ether address is in /etc/ethers or not). I added an adequate entry in /etc/ethers, then i ran rarpd -v, and: while ((1)) do; ./a.out; done all it is doing is flooding my syslog. x86, libnet-1.0.2a-r3, libpcap-0.9.5
Since we can't reproduce I call a vote and vote NO GLSA.
/vote no, can't reproduce (and rarpd is pretty rare in actual use as it is).
Fixing severity level. Two NO votes -> Closing with NO GLSA. Feel free to reopen if you disagree.