linux-kernel - Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 16 Nov 2007 14:26:19 -0500
From:	Bill Fink <billfink@...dspring.com>
To:	David Miller <davem@...emloft.net>
Cc:	the.sator@...il.com, kuznet@....inr.ac.ru,
	linux-kernel@...r.kernel.org, jmorris@...ei.org,
	netdev@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [PATCH] net/ipv4/arp.c: Fix arp reply when sender ip 0

On Fri, 16 Nov 2007, David Miller wrote:

> From: "Jonas Danielsson" <the.sator@...il.com>
> Date: Fri, 16 Nov 2007 09:30:11 +0100
> 
> > 2007/11/16, David Miller <davem@...emloft.net>:
> > > From: "Jonas Danielsson" <the.sator@...il.com>
> > > Date: Thu, 15 Nov 2007 22:40:13 +0100
> > >
> > > > Is there a reason that the target hardware address isn't the target
> > > > hardware address?
> > 
> > > Because of this, in cases where a choice can be made Linux will
> > > advertise what is most likely to result in successful communication.
> > >
> > > This is likely why we are changing that target address to the one of
> > > the interface actually sending back the reply rather than the zero
> > > value you used.
> > >
> > > In fact I think this information can be useful to the sender of
> > > the DAD request.
> > >
> > 
> > There seem to be some confusion about what my patch really does. It
> > does not set the hardware address to a zero value.
> 
> I knew you were talking about the IP address not the hardware
> address.
> 
> > The reply from the Linux kernel in computer A, before the patch would look like:
> > 
> > Reply:
> > Opcode: reply (0x0002)
> > Sender HW: 00:AA.00:AA:00:AA
> > Sender IP:   192.168.0.1
> > Target HW:  00:AA:00:AA:00:AA
> > Target IP:    192.168.0.1
> 
> And this is exactly a sensible response in my opinion.

I don't see how you can say that, since it appears to be in violation
of RFC 826:

	"The target hardware address is included for completeness and
	network monitoring.  It has no meaning in the request form,
	since it is this number that the machine is requesting.  Its
	meaning in the reply form is the address of the machine making
	the request.  In some implementations (which do not get to look
	at the 14.byte ethernet header, for example) this may save some
	register shuffling or stack space by sending this field to the
	hardware driver as the hardware destination address of the
	packet."

Since the MAC address of the machine making the request is
00:BB:00:BB:00:BB, and not 00:AA:00:AA:00:AA, Linux appears to
be in violation of the ARP RFC.

Regarding the Target IP, RFC 826 says:

	"The target protocol address is necessary in the request form
	of the packet so that a machine can determine whether or not
	to enter the sender information in a table or to send a reply.
	It is not necessarily needed in the reply form if one assumes
	a reply is only provoked by a request.  It is included for
	completeness, network monitoring, and to simplify the suggested
	processing algorithm described above (which does not look at
	the opcode until AFTER putting the sender information in a
	table).

So it's ambiguous about the target IP address in an ARP reply packet,
but a value of 0.0.0.0 makes more logical sense to me than using
192.168.0.1 in this example case, since it should reflect the requestor
IP address, which is unknown in this case.

						-Bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/