Summary: | net-misc/rarpd Denial of Service | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Pierre-Yves Rofes (RETIRED) <py> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://secunia.com/advisories/25061/ | ||
Whiteboard: | B3 [noglsa] p-y | ||
Package list: | Runtime testing required: | --- |
Description
Pierre-Yves Rofes (RETIRED)
2007-04-30 12:02:54 UTC
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. |