Unbound - CVE-2023-50387 and CVE-2023-50868

bmeeks

@Gertjan said in Unbound - CVE-2023-50387 and CVE-2023-50868:

@bmeeks

Still, I would think twice before going from 1.18.0, the one I'm using right now, to a newer 1.19.x.
As always, 1.19.x might bring in a solution for a (this) CVE problem, and introduce other, not known issues.

Yeah, not advocating for an upgrade to unbound. Just pointing the OP to a good place to search for how Netgate is responding to a particular CVE when someone has questions. If the CVE has application to pfSense, then it will be addressed.

Sometimes, depending on the CVE, the "fix" Redmine Issue ticket might not be immediately public until the actual fix is ready and/or the CVE mitigated. This is normal practice for all software distros.

serbus

Hello!

These CVEs would also appear to affect the bind9 package offered in the Package Manager (?). I dont see bind9 mentioned in the redmine issue.

https://kb.isc.org/v1/docs/cve-2023-50868
https://kb.isc.org/v1/docs/cve-2023-50387

John

bmeeks

@serbus said in Unbound - CVE-2023-50387 and CVE-2023-50868:

Hello!

These CVEs would also appear to affect the bind9 package offered in the Package Manager (?). I dont see bind9 mentioned in the redmine issue.

https://kb.isc.org/v1/docs/cve-2023-50868
https://kb.isc.org/v1/docs/cve-2023-50387

John

Just a guess as I'm not a Netgate employee nor involved in such decisions, but perhaps because bind is an optional add-on package it is not treated with the same urgency. The unbound package is part of the base install of pfSense, thus it can be considered a core package in my view. Things like bind, suricata, snort, and others are optional add-ons not directly supported by Netgate. For those they may just depend on the updates working themselves into the FreeBSD-ports tree upstream.

Gertjan

@serbus

I just visited my servers, and yes :

root@ns311465:~# apt-get upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
Les paquets suivants seront mis à jour :
  bind9 bind9-dnsutils bind9-host bind9-libs bind9-utils bind9utils dnsutils libunbound-dev libunbound8
9 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 4 720 ko dans les archives.
Après cette opération, 27,6 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] O

that's a bind9 security update coming right out the oven this morning.

And yes : bind9 (Debian) is updates : https://www.debian.org/security/ => https://lists.debian.org/debian-security-announce/2024/msg00028.html

That includes "CVE-2023-50387 and CVE-2023-50868" and other stuff.
So : no fooling around for me anymore.

The pfSense (FreeBSD) bind9 ? => https://www.freshports.org/dns/bind916 =>

Now it has to be back ported into the pfSense package repository ...
For those using bind9 on pfSense : don't let the bad guys accessing your pfSense so they can edit the zone files ^^

bmeeks

@Gertjan said in Unbound - CVE-2023-50387 and CVE-2023-50868:

The pfSense (FreeBSD) bind9 ? => https://www.freshports.org/dns/bind916 =>

Hopefully, when the Netgate team pulls in the unbound update from FreeBSD-ports, they can also just pull in the bind update at the same time. Then both packages can be rebuilt in the pfSense package builder system and be available for users to manually update via the CLI using the pkg utility.

coxhaus

@bmeeks
So, I switched to DNS forwarding. Is forwarding going to be a workaround?

Gertjan

@coxhaus said in Unbound - CVE-2023-50387 and CVE-2023-50868:

So, I switched to DNS forwarding. Is forwarding going to be a workaround?

The forwarder, dnsmasq, doesn't know or handle DNSSEC at all. So no risk for sure.

But, IMHO, no need to stop using unbound for this issue.
I've said above whats needed to be done so "CVE-2023-50387 and CVE-2023-50868" can hit you : the domain name server needs to be controlled by a 'bad guy' so bad zone 'DNSSEC' info can get injected. In that case, the issue won't be "CVE-2023-50387 and CVE-2023-50868" but far worse, as the bad guy could redirect you to its own controlled web server via the A record, etc etc etc. The only 'good' solution would be now : not visiting that site - but how could you know ? - so, by default, not using the Internet until this is resolved.

The issue always existed, and will always exist : if the bad guy control the domain (server), things go down fast and hard. The good new sis : the guy (admin) that handle domain name servers are the ones that all know about 'DNS' (as it it a well known kept secret : it's dead simple 'late last century' technology), it's only DNSSEC that is what I would call 'hard core DNS' and that's the reason it isn't very wide spread implemented.

If the issue was remotely important, the Netgate (pfSense) tam would have made a blog post, or forum notification about it, or pushed an upgrade/update.
They didn't. Which tells me : not a real issue for me.

johnpoz

@coxhaus While I haven't spent much time looking into this.. I have browsed over some of the info, and it seems this is more of an issue for public resolvers..

For this to happen, your resolver would have to query a bad domain. Why would it do that unless one of your clients asked for it?

Sure one of your clients that knows a bad site to query, could query your unbound and cause the problem.. But why/how would one of your clients do that? Guess they could go to some other bad site that has a link to one of these bad sites and then your client would query your dns for it.

if that is something your worried about, the simple mitigation is to just turn off dnssec in unbound. There is no reason to forward, just turn off dnssec if your concerned.

I personally have not done this, I am not too concerned that one of my devices on my network would query such a domain to cause this problem.. Is there even any out there? I have not seen a score assigned to these cve's as of yet.. The write ups I have read, don't list any active exploits as of yet, etc.

And while such a dos to a public resolver could be bad, and some bad actor might think hey lets take down X resolver, etc.. I don't see that happening with my local resolver.. And if it did, it would be simple enough to mitigate.. And I would be more interested in the client on my network doing it and tracking them down, or what sites might have instigated the client to do the query, etc.

While sure its good to be informed on such issues, I don't see anything requiring immediate action on my part, nor do I personally think it requires me to disable dnssec or forward on the off chance, etc.. But you do you.

Gertjan

[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: pkg upgrade
Updating pfSense-core repository catalogue...
Fetching meta.conf:   0%
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
Fetching meta.conf:   0%
pfSense repository is up to date.
All repositories are up to date.
Checking for upgrades (19 candidates): 100%     19 B   0.0kB/s    00:01
Processing candidates (19 candidates): 100%     19 B   0.0kB/s    00:01
The following 2 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        curl: 8.5.0 -> 8.6.0 [pfSense]
        unbound: 1.18.0_1 -> 1.19.1 [pfSense] 

Number of packages to be upgraded: 2

3 MiB to be downloaded.

Proceed with this action? [y/N]: y

MoonKnight

@Gertjan

Number of packages to be upgraded: 2

3 MiB to be downloaded.

Proceed with this action? [y/N]: y
[1/2] Fetching unbound-1.19.1.pkg: 100%    1 MiB   1.5MB/s    00:01    
[2/2] Fetching curl-8.6.0.pkg: 100%    1 MiB   1.2MB/s    00:01    
Checking integrity... done (0 conflicting)
[1/2] Upgrading unbound from 1.18.0_1 to 1.19.1...
===> Creating groups.
Using existing group 'unbound'.
===> Creating users
Using existing user 'unbound'.
[1/2] Extracting unbound-1.19.1: 100%
unbound-1.18.0_1: missing file /usr/local/man/man1/unbound-host.1.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/libunbound.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_cancel.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_add_ta.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_add_ta_file.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_async.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_config.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_create.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_data_add.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_data_remove.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_debuglevel.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_debugout.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_delete.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_get_option.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_hosts.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_print_local_zones.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_resolvconf.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_set_fwd.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_set_option.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_trustedkeys.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_zone_add.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_ctx_zone_remove.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_fd.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_poll.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_process.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_resolve.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_resolve_async.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_resolve_free.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_result.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_strerror.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man3/ub_wait.3.gz
unbound-1.18.0_1: missing file /usr/local/man/man5/unbound.conf.5.gz
unbound-1.18.0_1: missing file /usr/local/man/man8/unbound-anchor.8.gz
unbound-1.18.0_1: missing file /usr/local/man/man8/unbound-checkconf.8.gz
unbound-1.18.0_1: missing file /usr/local/man/man8/unbound-control-setup.8.gz
unbound-1.18.0_1: missing file /usr/local/man/man8/unbound-control.8.gz
unbound-1.18.0_1: missing file /usr/local/man/man8/unbound.8.gz
[2/2] Upgrading curl from 8.5.0 to 8.6.0...
[2/2] Extracting curl-8.6.0: 100%
[23.09.1-RELEASE][admin@pfSense.home.arpa]/root:

johnpoz

@MoonKnight are you asking why those are missing, or you just showing that you updated? None of the packages that pf installs include the man pages that I am aware of..

Possible that they forgot to update the pkg list of what is included so it doesn't show that?

MoonKnight

@johnpoz
hehe I was in a hurry. Just posted the output, probably nothing special, like you say :)

TheNarc

@MoonKnight I got the same output, but 1.19.1 started fine with no warnings/errors in the log output when I restarted the service.

tinfoilmatt

@TheNarc same. and successful package update notice printed to the System log:

2024-03-06 10:58:05.404047-05:00 	pkg-static 	80765 	unbound upgraded: 1.18.0_1 -> 1.19.1

thanks (and to @MoonKnight as well) for the upgrade confidence nudge.

bmeeks

@johnpoz said in Unbound - CVE-2023-50387 and CVE-2023-50868:

Possible that they forgot to update the pkg list of what is included so it doesn't show that?

Yes. Those files are generated for use when you consult man pages from the CLI. But none of the pfSense packages are compiled with those pages in order to save space. Normally there is a command added to the Makefile for the package that suppresses generation of the man pages. Apparently that got left out of the pfSense build (those man pages default to "on" in the normal FreeBSD ports tree).

Not having the files is harmless.

Edit: checked GitHub, and in this particular case it seems a change was made to the location where the man files (docs) were to be stored. Here is the commit: https://github.com/pfsense/FreeBSD-ports/commit/0abb4aa51d10dadd60c11278b91616d1f689f8ac. Apparently something is either not finished in the change or the location is wrong.

pfpv

@Gertjan said in Unbound - CVE-2023-50387 and CVE-2023-50868:

[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: pkg upgrade

Should we all run this package upgrade?

bmeeks

@pfpv said in Unbound - CVE-2023-50387 and CVE-2023-50868:

@Gertjan said in Unbound - CVE-2023-50387 and CVE-2023-50868:
[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: pkg upgrade
Should we all run this package upgrade?

Depends upon whether you think your network is really vulnerable to the exploit described in the CVE reports.

For my case, with a home LAN, I'm just waiting until I update to pfSense Plus 24.03 in the future as I suspect it is going to be released soon. If I ran a business critical network that was perhaps vulnerable to the CVE exploits, then I would update.