Bugzilla Bug 176558

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.