| 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
| ||
|
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