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]
Message-id: <201105280158.58927.matare@lih.rwth-aachen.de>
Date:	Sat, 28 May 2011 01:58:58 +0200
From:	Victor Mataré <matare@....rwth-aachen.de>
To:	Julian Anastasov <ja@....bg>
Cc:	David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
	netdev@...r.kernel.org, bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org
Subject: Re: [Bugme-new] [Bug 35862] New: arp requests from wrong src IP

On Friday, 27.05.2011 07:27:23 Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Thu, 26 May 2011, Victor Mataré wrote:
> 
> > Examining the host which now has 137.226.164.2 (used to have 137.226.164.13):
> > 
> > # ip addr show dev eth0
> > 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
> >      link/ether 00:e0:81:41:1f:e4 brd ff:ff:ff:ff:ff:ff
> >      inet 137.226.164.2/24 brd 137.226.164.255 scope global eth0
> >      inet 192.168.23.2/24 brd 137.226.164.255 scope global eth0:0
> > [...]
> > 
> > Sorry, got confused with all the swapping. I'm *not* keeping the old address around, it's completely *gone*, from both ifconfig and ip. But still it's being used as arp src address. That's what this bug is about. Sorry for the confusion.
> 
> 	It looks strange. Can you confirm the following things:
> 
> - the kernel version

This host runs 2.6.36-hardened-r9. I'm not sure which vanilla release that's based on, but it's patched with grsec and PAX. However another host which exhibits the exact same behaviour runs 2.6.29-gentoo-r5. This one does not have hardened or grsec, but gentoo patches, so I'd assume this is neither a version- nor a patch-specific problem.

> 
> - the order of 'ip' command used to add and change IPs on this box

ok - starting situation was 2 IPs: 137.226.164.13/24 (eth0) and 192.168.23.13/24 (eth0:0)
then I did "ifconfig eth0 137.226.164.2 netmask 255.255.255.0"
I'm not exactly sure what happened then, but the result was that "ip addr show dev eth0" showed that eth0 still had the old IP address, while ifconfig didn't. Ifconfig was misbehaving in some kind of way, that's why I checked the situation with the ip tool. Then I used ip to configure everything as intended and now I have the situation described in this bug. Note that the server has been in productive use for a week now despite of that.

> 
> - output of 'ip route list table local' after IPs are changed and
> before starting arping

broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1 
broadcast 192.168.23.0 dev eth0  proto kernel  scope link  src 192.168.23.2 
local 192.168.23.2 dev eth0  proto kernel  scope host  src 192.168.23.2 
local 137.226.164.2 dev eth0  proto kernel  scope host  src 137.226.164.2 
local 137.226.164.13 dev eth0  proto kernel  scope host  src 137.226.164.13 
broadcast 192.168.23.255 dev eth0  proto kernel  scope link  src 192.168.23.2 
broadcast 137.226.164.255 dev eth0  proto kernel  scope link  src 137.226.164.2 
broadcast 137.226.164.255 dev eth0  proto kernel  scope link  src 192.168.23.2 
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1 

I guess that entry "local 137.226.164.13" shouldn't be there? But shouldn't that be removed automatically when I delete the IP from eth0?

> 
> - output of 'strace arping', I assume it is using getsockname
> after UDP connect

# strace arping 137.226.164.13
[...]
socket(PF_PACKET, SOCK_DGRAM, 0)        = 3
setuid(0)                               = 0
ioctl(3, SIOCGIFINDEX, {ifr_name="eth0", ifr_index=4}) = 0
ioctl(3, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
setsockopt(4, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0", 5) = 0
setsockopt(4, SOL_SOCKET, SO_DONTROUTE, [1], 4) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("137.226.164.13")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(44125), sin_addr=inet_addr("137.226.164.13")}, [16]) = 0
close(4)                                = 0
bind(3, {sa_family=AF_PACKET, proto=0x806, if4, pkttype=PACKET_HOST, addr(0)={0, }, 128) = 0
getsockname(3, {sa_family=AF_PACKET, proto=0x806, if4, pkttype=PACKET_HOST, addr(6)={1, 00e081411fe4}, [18]) = 0
[...] no reply [...]

compare that with:

# strace arping 137.226.164.3
[...]
socket(PF_PACKET, SOCK_DGRAM, 0)        = 3
setuid(0)                               = 0
ioctl(3, SIOCGIFINDEX, {ifr_name="eth0", ifr_index=4}) = 0
ioctl(3, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
setsockopt(4, SOL_SOCKET, SO_BINDTODEVICE, "eth0\0", 5) = 0
setsockopt(4, SOL_SOCKET, SO_DONTROUTE, [1], 4) = 0
connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("137.226.164.3")}, 16) = 0
getsockname(4, {sa_family=AF_INET, sin_port=htons(45467), sin_addr=inet_addr("137.226.164.2")}, [16]) = 0
close(4)                                = 0
bind(3, {sa_family=AF_PACKET, proto=0x806, if4, pkttype=PACKET_HOST, addr(0)={0, }, 128) = 0
getsockname(3, {sa_family=AF_PACKET, proto=0x806, if4, pkttype=PACKET_HOST, addr(6)={1, 00e081411fe4}, [18]) = 0
[...] reply [...]

So that's the change in source address, and I guess it's due to the table above? Then this is more like a bug in the "ip" utility?

> 
> - any reason to use broadcast 137.226.164.255 for all addresses?

Nope, none at all. I didn't see that because I thought ifconfig and ip use sensible defaults. Well...

So thanks, looks like you're pointing in the right direction.

Victor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ