On 2017/06/13 08:24, [email protected] wrote:
> >Synopsis:    spoofed icmp6 echo reply for link local address
> >Category:    system
> >Environment:
>       System      : OpenBSD 6.1
>       Details     : OpenBSD 6.1 (GENERIC.MP) #7: Mon Jun 12 20:41:01 CEST 2017
>                        
> [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> 
>       Architecture: OpenBSD.amd64
>       Machine     : amd64
> >Description:
>       If I send an icmp6 echo request to the OpenBSD box' link local address 
>       from another host, then it creates an icmp6 echo reply using ::1 as the
>       sender address. 
> 
>       This spoofed sender address is blocked by the default packet filer 
>       configuration.
> >How-To-Repeat:
>       # network interface to examin
>       if=re0
> 
>       # Enable IPv6 link local address
>       ifconfig ${if} inet6 eui64
>       ifconfig ${if}
> 
>       # disable the firewall (just to show)
>       pfctl -d
> 
>       # move to another host to send icmp6 echo requests to the link-local 
>       # address, e.g.
>       ping6 -n fe80::82ee:73ff:fea7:6729%br0
> 
>       # monitor the network interface via tcpdump while ping6 is running
>       tcpdump -i ${if} -env icmp6
>       08:19:09.438965 54:be:f7:09:30:bd 80:ee:73:a7:67:29 86dd 118: 
> fe80::56be:f7ff:fe09:30bd > fe80::82ee:73ff:fea7:6729: icmp6: echo request 
> (id:5072 seq:7) [flowlabel 0x34b7c] (len 64, hlim 64)
>       08:19:09.438989 80:ee:73:a7:67:29 54:be:f7:09:30:bd 86dd 118: ::1 > 
> fe80::56be:f7ff:fe09:30bd: icmp6: echo reply (id:5072 seq:7) (len 64, hlim 64)
...

Confirmed on various machines here, including -current.
I don't even need to look at tcpdump:

$ ping6 ff02::1%vlan11 
PING ff02::1%vlan11 (ff02::1%vlan11): 56 data bytes
64 bytes from ::1: icmp_seq=0 hlim=64 time=0.107 ms
64 bytes from fe80::3a63:bbff:fe04:2897%vlan11: icmp_seq=0 hlim=64 time=0.296 
ms (DUP!)
64 bytes from fe80::8a51:fbff:feea:bd9b%vlan11: icmp_seq=0 hlim=64 time=0.396 
ms (DUP!)
64 bytes from fe80::230:18ff:fead:31fc%vlan11: icmp_seq=0 hlim=64 time=0.462 ms 
(DUP!)
64 bytes from fe80::3a63:bbff:fe04:f772%vlan11: icmp_seq=0 hlim=64 time=0.497 
ms (DUP!)
64 bytes from fe80::220:6bff:fe99:573a%vlan11: icmp_seq=0 hlim=64 time=0.532 ms 
(DUP!)
64 bytes from fe80::d685:64ff:fe1c:d841%vlan11: icmp_seq=0 hlim=64 time=0.557 
ms (DUP!)
64 bytes from fe80::121f:74ff:fe44:5df3%vlan11: icmp_seq=0 hlim=64 time=0.650 
ms (DUP!)
64 bytes from fe80::5a20:b1ff:fef2:480d%vlan11: icmp_seq=0 hlim=64 time=0.694 
ms (DUP!)
^C
--- ff02::1%vlan11 ping statistics ---
1 packets transmitted, 1 packets received, 8 duplicates, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.107/0.466/0.694/0.171 ms

The one with ::1 source was sent by an OpenBSD host, in this case it is
running "OpenBSD 6.0-current (GENERIC.MP) #0: Wed Nov  9 12:58:15 MST 2016",
the others are mostly Windows.

Since you have a 6.0 system handy, are you able to apply
https://github.com/openbsd/src/commit/3e4bd4b41d124df8849a234977327b543297783e.patch
to the kernel to see if this is what introduces the breakage?

Reply via email to