[Bug 1015452] [NEW] tcpdump/avahi extremely odd-- but perhaps a security issue
jb
1015452 at bugs.launchpad.net
Wed Jun 20 08:30:49 UTC 2012
Public bug reported:
Not sure if/what aspect of the program between avahi and tcpdump is causing this.. but i get this with tcpdump only when i dont use options with it..
"
tcpdump<enter>
21:56:52.211512 IP6 fe80::201:4aff:fe08:415.mdns > ff02::fb.mdns: 0 PTR (QM)? 1.1.168.192.in-addr.arpa. (42)
"
(linux distro may be irrelevant-- it's on a 32bit 2.6 kernel- ubuntu 10.10 .)
tcpdump is 2009 and i dont know if this bug carried over
I've sent a copy of this message to both avahi and tcpdump upstream
--
Simulation to imitate for symptoms to appear
I have all my interfaces down on a laptop (wifi nic and wired)
There's no network configuration to this laptop.. it only has a link rj45 (ethernet) cable to its eth0 port-- An ethertap ingress port is connected to eth0..
(optionally I do ifdown -a, and NetworkManager doesnt need to be used-- nmcli/nmtool shows there are no connection profiles used)
I simply type "tcpdump<enter>"
now.. What is on this ingress cable? It's only traffic of 1-direction
from some suspecting machine.. The laptop is essentially undetected with
the help of an ethertap device(the ethertap device is connected to the
eth0 port-- there are 4 ports for connecting the ethertap device-- 2 for
the suspecting host, and 2 for the monitoring host-- but I'm only
interested in 1 direction so i'm only connecting 1 port to the laptop ->
eth0)
fe80::201:4aff:fe08: << is an address on the laptop (ifconfig -a shows
this -- it is an ip6 address for the eth0-- being a realtek which uses
8139too)..
It is possible it may be an 8139too module issue.. but i'm no expert you
guys are :)
..HOWEVER...
"tcpdump -i eth0" or using "tcpdump <params".. doesn't ever exhibit
that above IP6 line.. (it's the only IP6 type of line showing up anyways
and all others are IPv4 as expected as it's the only traffic used on the
suspecting machine)..
Yes it is being used in promiscious mode the tcpdump.. but it makes no
sense why tcpdump behaves differently when I try it with "tcpdump -i
eth0" vs "tcpdump"... Something is broken somewhere making it behave
like this..
.. This problem does not appear of course when I have nothing in the
eth0 port.. If there really is a problem somewhere down to the ether
link related matters, it may be relevant for me to tell my kernel
edition.. which is.-- > kernel is 2.6.35-22-generic i686 2010 -- ubuntu
10.10 (modinfo 8139too-> version 0.9.28)
route<enter>
routel show no routing links to nowhere.. so I'm only speculating it is related to LLMNR code in the kernel at my best guess..
..
route<enter>
-----
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
routel<enter>
-----
target gateway source proto scope dev tbl
127.255.255.255 broadcast 127.0.0.1 kernel link lo local
127.0.0.0 broadcast 127.0.0.1 kernel link lo local
127.0.0.1 local 127.0.0.1 kernel host lo local
127.0.0.0 8 local 127.0.0.1 kernel host lo local
fe80:: 64 kernel eth0
default unreachable kernel lo unspec
::1 :: none lo local
fe80::201:4aff:fe08:415 :: none lo local
ff00:: 8 eth0 local
default unreachable kernel lo unspec
..
in /etc/host.conf i have
"
order hosts,bind
multi on
"
..
and in /etc/avahi/avahi-daemon.conf
"
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
# See avahi-daemon.conf(5) for more information on this configuration
# file!
[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
#publish-hinfo=yes
#publish-workstation=yes
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no
[reflector]
#enable-reflector=no
#reflect-ipv=no
[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3
"
..
and ifconfig -a
"
eth0 Link encap:Ethernet HWaddr 00:01:4a:08:04:15
inet6 addr: fe80::201:4aff:fe08:415/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1512 (1.5 KB) TX bytes:4837 (4.8 KB)
Interrupt:3 Base address:0x9000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 B) TX bytes:240 (240.0 B)
wlan0 Link encap:Ethernet HWaddr 00:0e:9b:55:c6:7a
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
"
..
nm-tool<enter>
"
NetworkManager Tool
State: disconnected
- Device: wlan0 ----------------------------------------------------------------
Type: 802.11 WiFi
Driver: ath5k
State: disconnected
Default: no
HW Address: 00:0E:9B:55:C6:7A
Capabilities:
Wireless Properties
WEP Encryption: yes
WPA Encryption: yes
WPA2 Encryption: yes
Wireless Access Points
<.. a list of scanned wifi AP's>
- Device: eth0 -----------------------------------------------------------------
Type: Wired
Driver: 8139too
State: disconnected
Default: no
HW Address: 00:01:4A:08:04:15
Capabilities:
Carrier Detect: yes
Speed: 10 Mb/s
Wired Properties
Carrier: on
"
Obviously the thing for me to try out is to have "use-ipv6=no" and the
problem may go away.. but makes no sense to me as to why using "eth0"
passed to tcpdump is sticking to ipv4 -- The objective is not to have
any traffic recording from the local monitoring machine (I know I can
using extra filter parameters), but something seems very wrong. For
extra trivial information possibly, I don't login to the desktop to
avoid triggering any dbus/network related events.. but simply leave X on
its logon screen.. ( i think avahi has a dbus related entry but i'm no
sure)
Sorry if this bug is already addressed but I couldn't find any
information on this.. though similar sounding ones.. If what I'm seeing
is normal, I'd like an explanation about why the fe80 ip6 address doesnt
apply when "tcpdump eth0" is being used.. (stopping network-manager
service disables inet6 from showing up in ifconfig -a, tcpdump then
won't catch anything, but trying to start network-manager later causes
freezes, so i avoid stopping network-manager on ubuntu 10.10-- trivial
wonder if this is any generic linux behavior)
I hope this is interesting and worth-while. This is not going to be easy
I guess, you guys are the experts and I thank you for any feedback given
:)
** Affects: avahi (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to avahi in Ubuntu.
https://bugs.launchpad.net/bugs/1015452
Title:
tcpdump/avahi extremely odd-- but perhaps a security issue
Status in “avahi” package in Ubuntu:
New
Bug description:
Not sure if/what aspect of the program between avahi and tcpdump is causing this.. but i get this with tcpdump only when i dont use options with it..
"
tcpdump<enter>
21:56:52.211512 IP6 fe80::201:4aff:fe08:415.mdns > ff02::fb.mdns: 0 PTR (QM)? 1.1.168.192.in-addr.arpa. (42)
"
(linux distro may be irrelevant-- it's on a 32bit 2.6 kernel- ubuntu 10.10 .)
tcpdump is 2009 and i dont know if this bug carried over
I've sent a copy of this message to both avahi and tcpdump upstream
--
Simulation to imitate for symptoms to appear
I have all my interfaces down on a laptop (wifi nic and wired)
There's no network configuration to this laptop.. it only has a link rj45 (ethernet) cable to its eth0 port-- An ethertap ingress port is connected to eth0..
(optionally I do ifdown -a, and NetworkManager doesnt need to be used-- nmcli/nmtool shows there are no connection profiles used)
I simply type "tcpdump<enter>"
now.. What is on this ingress cable? It's only traffic of 1-direction
from some suspecting machine.. The laptop is essentially undetected
with the help of an ethertap device(the ethertap device is connected
to the eth0 port-- there are 4 ports for connecting the ethertap
device-- 2 for the suspecting host, and 2 for the monitoring host--
but I'm only interested in 1 direction so i'm only connecting 1 port
to the laptop -> eth0)
fe80::201:4aff:fe08: << is an address on the laptop (ifconfig -a shows
this -- it is an ip6 address for the eth0-- being a realtek which uses
8139too)..
It is possible it may be an 8139too module issue.. but i'm no expert
you guys are :)
..HOWEVER...
"tcpdump -i eth0" or using "tcpdump <params".. doesn't ever exhibit
that above IP6 line.. (it's the only IP6 type of line showing up
anyways and all others are IPv4 as expected as it's the only traffic
used on the suspecting machine)..
Yes it is being used in promiscious mode the tcpdump.. but it makes no
sense why tcpdump behaves differently when I try it with "tcpdump -i
eth0" vs "tcpdump"... Something is broken somewhere making it behave
like this..
.. This problem does not appear of course when I have nothing in the
eth0 port.. If there really is a problem somewhere down to the ether
link related matters, it may be relevant for me to tell my kernel
edition.. which is.-- > kernel is 2.6.35-22-generic i686 2010 --
ubuntu 10.10 (modinfo 8139too-> version 0.9.28)
route<enter>
routel show no routing links to nowhere.. so I'm only speculating it is related to LLMNR code in the kernel at my best guess..
..
route<enter>
-----
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
routel<enter>
-----
target gateway source proto scope dev tbl
127.255.255.255 broadcast 127.0.0.1 kernel link lo local
127.0.0.0 broadcast 127.0.0.1 kernel link lo local
127.0.0.1 local 127.0.0.1 kernel host lo local
127.0.0.0 8 local 127.0.0.1 kernel host lo local
fe80:: 64 kernel eth0
default unreachable kernel lo unspec
::1 :: none lo local
fe80::201:4aff:fe08:415 :: none lo local
ff00:: 8 eth0 local
default unreachable kernel lo unspec
..
in /etc/host.conf i have
"
order hosts,bind
multi on
"
..
and in /etc/avahi/avahi-daemon.conf
"
# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.
# See avahi-daemon.conf(5) for more information on this configuration
# file!
[server]
#host-name=foo
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=yes
#allow-interfaces=eth0
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000
[wide-area]
enable-wide-area=yes
[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
#publish-hinfo=yes
#publish-workstation=yes
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no
[reflector]
#enable-reflector=no
#reflect-ipv=no
[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3
"
..
and ifconfig -a
"
eth0 Link encap:Ethernet HWaddr 00:01:4a:08:04:15
inet6 addr: fe80::201:4aff:fe08:415/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:21 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1512 (1.5 KB) TX bytes:4837 (4.8 KB)
Interrupt:3 Base address:0x9000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:240 (240.0 B) TX bytes:240 (240.0 B)
wlan0 Link encap:Ethernet HWaddr 00:0e:9b:55:c6:7a
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
"
..
nm-tool<enter>
"
NetworkManager Tool
State: disconnected
- Device: wlan0 ----------------------------------------------------------------
Type: 802.11 WiFi
Driver: ath5k
State: disconnected
Default: no
HW Address: 00:0E:9B:55:C6:7A
Capabilities:
Wireless Properties
WEP Encryption: yes
WPA Encryption: yes
WPA2 Encryption: yes
Wireless Access Points
<.. a list of scanned wifi AP's>
- Device: eth0 -----------------------------------------------------------------
Type: Wired
Driver: 8139too
State: disconnected
Default: no
HW Address: 00:01:4A:08:04:15
Capabilities:
Carrier Detect: yes
Speed: 10 Mb/s
Wired Properties
Carrier: on
"
Obviously the thing for me to try out is to have "use-ipv6=no" and the
problem may go away.. but makes no sense to me as to why using "eth0"
passed to tcpdump is sticking to ipv4 -- The objective is not to have
any traffic recording from the local monitoring machine (I know I can
using extra filter parameters), but something seems very wrong. For
extra trivial information possibly, I don't login to the desktop to
avoid triggering any dbus/network related events.. but simply leave X
on its logon screen.. ( i think avahi has a dbus related entry but i'm
no sure)
Sorry if this bug is already addressed but I couldn't find any
information on this.. though similar sounding ones.. If what I'm
seeing is normal, I'd like an explanation about why the fe80 ip6
address doesnt apply when "tcpdump eth0" is being used.. (stopping
network-manager service disables inet6 from showing up in ifconfig -a,
tcpdump then won't catch anything, but trying to start network-manager
later causes freezes, so i avoid stopping network-manager on ubuntu
10.10-- trivial wonder if this is any generic linux behavior)
I hope this is interesting and worth-while. This is not going to be
easy I guess, you guys are the experts and I thank you for any
feedback given :)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/1015452/+subscriptions
More information about the foundations-bugs
mailing list