avahi_service_browser_new() failed: Invalid service type

Bug #2002891 reported by Hadmut Danisch
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
avahi (Ubuntu)
New
Undecided
Unassigned

Bug Description

Hi,

on a network, where the router offers DHCP, but does not put the DHCP clients in a DNS domain, thus where it is necessary to use mdns/avahi instead, I ran into several problems with avahi.

One is
avahi-browse -a -t
avahi_service_browser_new() failed: Invalid service type

No other output. i.e. it just does not work.

In this network, all Ubuntu machines show this behaviour.

In my other network (with working DHCP-DNS, different router, different brand, therefore not depending on mdns) the problem does not occur

Since the debugging output of avahi software is – if at all – very poor, I cannot see what causes this problem. However, dbus-monitor --system showed

...

method call time=1673742811.321042 sender=:1.692 -> destination=org.freedesktop.Avahi serial=10 path=/; interface=org.freedesktop.Avahi.Server; member=ServiceBrowserNew
   int32 -1
   int32 -1
   string "_ipp._tcp"
   string "local"
   uint32 0
method return time=1673742811.321093 sender=:1.479 -> destination=:1.692 serial=557 reply_serial=10
   object path "/Client29/ServiceBrowser3"
method call time=1673742811.321259 sender=:1.692 -> destination=org.freedesktop.Avahi serial=11 path=/; interface=org.freedesktop.Avahi.Server; member=ServiceBrowserNew
   int32 -1
   int32 -1
   string "_scanner._tcp"
   string "local"
   uint32 0
method return time=1673742811.321301 sender=:1.479 -> destination=:1.692 serial=558 reply_serial=11
   object path "/Client29/ServiceBrowser4"
method call time=1673742811.321391 sender=:1.692 -> destination=org.freedesktop.Avahi serial=12 path=/; interface=org.freedesktop.Avahi.Server; member=ServiceBrowserNew
   int32 -1
   int32 -1
   string ""
   string ""
   uint32 0
error time=1673742811.321479 sender=:1.479 -> destination=:1.692 error_name=org.freedesktop.Avahi.InvalidServiceTypeError reply_serial=12
   string "Invalid service type"

So it seems as if the client (browser) queries one services after the other, which works, but then an empty string as a name, which is rejected by the daemon, which then makes the client to spit out this error message and then terminate immediately.

Since I have similar (i.e. very similar, both created with puppet) machines, and all machines in one network fail, while similar machines in another don't, I guess that the problem is caused by some network reply, maybe a printer.

This, however, could be a security problem, because if someone can cause avahi and thus mdns resolution to fail in networks like this here, where the router and dhcp server does not offer the host names in a DNS domain (Huawei glass fiber router), a malformed packet could cause the mdns resolution of avahi to fail and therefore could be used for an attack, effectively blocking certain kinds of mdns service resolution. But since I have not yet understood what really causes this problem, it is just an assumption.

regards

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: avahi-utils 0.8-5ubuntu5
ProcVersionSignature: Ubuntu 5.15.0-58.64-generic 5.15.74
Uname: Linux 5.15.0-58-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu82.3
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: XFCE
Date: Sun Jan 15 02:35:24 2023
InstallationDate: Installed on 2022-12-25 (20 days ago)
InstallationMedia: Xubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 (20220809.1)
SourcePackage: avahi
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Hadmut Danisch (hadmut) wrote :
information type: Private Security → Public
Revision history for this message
Seth Arnold (seth-arnold) wrote :

Hello Hadmut, my first inclination is that this isn't a security issue:

- services should use cryptographic verification of both peers, if this is important
- network administrators can use port security settings on their equipment to restrict which hosts can communicate in which fashions

If I've overlooked something, please do let us know.

Thanks

Revision history for this message
Hadmut Danisch (hadmut) wrote :

Yes. You've missed a point.

If avahi-browse completely fails because of one invalid answer, this could allow what we call DoS, Denial of Service (Attack).

All those cryptographic verification, bells, whistles can protect you from communicating with the wrong one, but none of them can help you if you don't find the right peer because you don't get an answer to a dns query. You cannot verify a communication peer, if you can't communicate with the peer because you don't know its IP address.

This is not about forgery, spoofing, where cryptography would help. This is about turning off avahi-browse's functionality by sending some answer avahi-browse considers as invalid, for whatever reason.

Although applications would rather not use the command line tool avahi-browse as a binary, maybe in shell-scripts, they could use libavahi-client, in order to find services on the local network. Lots of services and devices in the LAN are nowadays found that way, e.g. Printers, TVs, sound devices. Lots of other stuff. And libavahi-client most probably shows the same effect.

And if you can't find the service providers, because avahi completely refuses to work because of an invalid packet, this is a denial of service, and btw., it is poor software, because software should be robust against malformed packages of any kind.

And this is not easy to solve, because avahi does not give any hint about what service type is considered as invalid or from which IP address it came from.

So it is a security issue. Although security is not the primary problem, because this doesn't need an attacker to fail and it does fail in complete absence of an attacker. But it could be abused in certain cases to sabotage programs mking use of mdns service discovery.

regards

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.