avahi-browse -a breaks with "Invalid service type" if a device sends a malformed service

[ferbar]

What happens
If a device on the network sends a service PTR like "esp32.http.tcp.local" then avahi-browse is broken on every computer on the network:

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

avahi-discover-standalone is not affected (it lists an empty line)

What I expect to happen
avahi-browse -a lists all found services, maybe an error message for the malformed service

How to reproduce it
create a service missing the underscores

[edisno]

Automation based on avahi-browse -a broke for me too, on a network where some Bosch wifi-based smart home devices were added. Presumably they send broken service announcements, however this means avahi-browse -a is fully broken since it does not list the other correct services, it seems to exit as soon as it encounters a broken service record, at a random point in the discovery process.

[ferbar]

I think that if one service is invalid avahi_dbus_respond_error() should not be called at:
https://github.com/lathiat/avahi/blob/master/avahi-daemon/dbus-protocol.c#L606

But I'm not sure if avahi_s_service_browser_prepare() should return an error if a service doesn't start with an _
https://github.com/lathiat/avahi/blob/master/avahi-core/browse-service.c#L106

What about:

-    AVAHI_CHECK_VALIDITY_RETURN_NULL(server, avahi_is_valid_service_type_generic(service_type), AVAHI_ERR_INVALID_SERVICE_TYPE);
+    if(!avahi_is_valid_service_type_generic(service_type)) {
+      service_type="_invalid._tcp";
+    }

The device is still not listet with an invalid service (I don't know why) but a broken device doestn't crash the rest of the mDNS entries

[niwa3836]

I think that if one service is invalid avahi_dbus_respond_error() should not be called at:
https://github.com/lathiat/avahi/blob/master/avahi-daemon/dbus-protocol.c#L606

But I'm not sure if avahi_s_service_browser_prepare() should return an error if a service doesn't start with an _
https://github.com/lathiat/avahi/blob/master/avahi-core/browse-service.c#L106

What about:

-    AVAHI_CHECK_VALIDITY_RETURN_NULL(server, avahi_is_valid_service_type_generic(service_type), AVAHI_ERR_INVALID_SERVICE_TYPE);
+    if(!avahi_is_valid_service_type_generic(service_type)) {
+      service_type="_invalid._tcp";
+    }

The device is still not listet with an invalid service (I don't know why) but a broken device doestn't crash the rest of the mDNS entries

Did you manage to test this? It looks a sensible thing to do in my view. Issue has been around since 2018 and would be lovely if it was fixed in a formal release (and allow peoples scripts to restart) :)

[warthog9]

Resolves the issue for me with Fedora's 0.8 RPM from the upcoming F33 release with your suggested fix.

[playaspec]

My god I hope this fix comes to Ubuntu some day. This bug has gone unaddressed for FIFTEEN YEARS!!!

Despite the bug being in Avahi, Lennart Pottering believes that his code should't be responsible for sanitizing it's inputs, and it is instead the fault of the foreign network device for sending malformed content!. Brain dead 'logic' like this needs to die a horrible death. It only causes DECADES of suffering for those that rely on this software.

[tyilo]

@ferbar's patch has now been integrated into the Arch Linux version of avahi in version 0.8+22+gfd482a7.

[sja1440]

On Fedora 36 I too am encountering the OP's issue.

Whilst awaiting the bug fix, can someone suggest a way of finding out which device is sending an "Invalid service type"? The current error message of:
avahi_service_browser_new() failed: Invalid service type
is not very helpful.

Can someone suggest something?

[kirchmeyer]

how is this still a thing?

[pemensik]

Do we have any PR attempting to fix this issue? Some changes are referenced by the comments, but I do not see matching PR. Do you have @ferbar any change you would like to contribute?

[mbiebl]

@pemensik See #472

[muggenhor]

Seeing as this is effectively a DoS vulnerability shouldn't this issue get a CVE assigned to it?

[evverx]

@muggenhor I kind of lost track of issues like that. I think I mentioned that commit along with some other commits in NixOS/nixpkgs#269599 (comment) but I'm not sure if they were backported. In terms of getting those things fixed I think it would be better to bump avahi to 0.9-rc1. If, say, RH (or any other distro) is interested in getting a CVE assigned personally I have no problem with that. @pemensik what do you think?

[muggenhor]

In terms of getting those things fixed I think it would be better to bump avahi to 0.9-rc1.

Ok, I'll discover whatever approach works to get it into Nix. This is my first attempt at upstreaming anything to Nix.

If, say, RH (or any other distro) is interested in getting a CVE assigned personally I have no problem with that. @pemensik what do you think?

Ah, I didn't know it was the distro assigning CVEs. I just noticed that this issue was one of the few ones missing one.

[darkbasic]

Ah, I didn't know it was the distro assigning CVEs

Anybody can request a CVE and usually the researcher who found the vulnerability does so. If you are interested in doing so I can give you some pointers. It usually helps alot to get things fixed.

[evverx]

I can give you some pointers

It's possible to request a CVE directly from MITRE

[pemensik]

I can request CVE id from our security team, though it seems we will need some process to track those things on upstream. Github has nice Security advisories UI, which is not available to me at least. From that it can be used to request CVE id from github itself, unless we have some already.

I thought I have already fixed this kind of issue. We have requested some CVE ids for some issues reported by @evverx. If it is not already among them or issue #501, we will want to request own CVE for it.

[evverx]

it seems we will need some process to track those things on upstream

It's kind of tracked in #540.

[pemensik]

We would need action from @lathiat to enable reporting security issues in private way, which is how it should be responsible done. At least now I cannot see any vulnerabilities or report a new one. Alternative would be something like systemd, which has external channel to report issues to.

I expect not only our distributions would like to upgrade to fixed versions or backport fixes only to security related issues. If you are able to crash your own instance, it does not need CVE. If you are able to crash somebody else's daemon or program (or your own over network), then it should be tracked and handled as a vulnerability. Ideally it should be published together with a fix for that and not made public before. Unfortunately there are many issues in avahi falling into the security category, which are not handled ideally now.

[evverx]

reporting security issues in private way, which is how it should be responsible done

It's called coordinated these days :-) but I agree it should be addressed one way or another.

there are many issues in avahi falling into the security category, which are not handled ideally now

I think most of those issues have been publicly known for several years so there was nothing to report privately or coordinate anyway.