Unbound - CVE-2023-50387 and CVE-2023-50868
-
Was just reading about CVE-2023-50387 which seems to affect all DNS resolvers that support DNSSec. It seems NLnetlabs has released an Unbound patch today.
https://www.nlnetlabs.nl/projects/unbound/security-advisories/Is Netgate aware and working on a patch? I did a search and can't seem to find anything.
-
@Griffo said in Unbound - CVE-2023-50387 and CVE-2023-50868:
can't seem to find anything
Before a software author publishes a page like this : https://www.nlnetlabs.nl/projects/unbound/security-advisories/ with a numbered CVE, they were already aware/informed. They analyzed the issue, created a solution, tested the solution.
pfSense is a "user" of unbound was already aware (that is : I truly believe this, I can't affirm) of upcoming issues.
Btw : have a look at this list : all the versions of unbound used by all the known platforms : https://repology.org/project/unbound/versions : Even FreeBSD own port is at 1.19.0 - not 1.19.1.
This tells me that this isn't a zero day major issue,The issue :The KeyTrap vulnerability works by using a combination of Keys (also colliding Keys), Signatures and number of RRSETs on a malicious zone. Answers from that zone can force a DNSSEC validator down a very CPU intensive and time costly validation path.
So, a malicious person needs to have access to a domain name server.
That's easy : it takes a couple of minutes to rent and activate a domain name like sjddffgsjkhfskjhfskjfhsjkdskjdfhsdfhsd.com, have it pointing (the A record) to DNS domain server, set up DNSSEC, and now wait until 'who ever' uses the domain name to look for some content.
He'll be waiting a long time.Ok, the malicious one needs a more exposed known web site, one that actually uses DNSSEC.
Not microsoft.com and facebook.com etc, I fpund this one : https://dnsviz.net/d/defense.gov/dnssec/ (Ok, not a site everybody visits daily).
So, first he has to gain access the the main DNS master domain name zone ....But wait : if he has access to that DNS domain name server, the entire site falls.
TLS (certificates) (HTTPS) falls.
Planet earth; or society, is already in the shut down process. Internet just died."DNSSEC unbound bug" just became a very minor issue
Recap : the bad guy has to have access to a very known domain name server, the master, the one with the zones.
If that is the case : who cares about DNSSEC ??Final note : I'm just a pfSense like you, and as such, not aware of the Netgate <=> Netgate relations.
I also have my own web server, and more important: mail server, and my domains have DNSSEC activated. This is one of them https://dnsviz.net/d/test-domaine.fr/dnssec/.
I'm waiting ....extra : as I have a domain name server with DNSSEC set up, I'm ready to 'test' this specially crafted RRSET zone. I probably would have to recompile 'bind' so it accepts this malicious entry.
-
pfSense Redmine Issue Tracker is always a place to check when you have questions like this. There is a new Redmine Issue for this reported CVE. Here is the link: https://redmine.pfsense.org/issues/15256.
Looks like plans are to make the updated package available to users without needing to update pfSense itself. Of course this will require users to perform a manual package update when it becomes available.
-
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. -
@Gertjan said in Unbound - CVE-2023-50387 and CVE-2023-50868:
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.
-
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-50387John
Lex parsimoniae
-
@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-50387John
Just a guess as I'm not a Netgate employee nor involved in such decisions, but perhaps because
bindis an optional add-on package it is not treated with the same urgency. Theunboundpackage is part of the base install of pfSense, thus it can be considered a core package in my view. Things likebind,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. -
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] Othat'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 ^^ -
@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
unboundupdate from FreeBSD-ports, they can also just pull in thebindupdate 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 thepkgutility. -
@bmeeks
So, I switched to DNS forwarding. Is forwarding going to be a workaround? -
@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. -
@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.
-
[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 -
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: -
@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?
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
@johnpoz
hehe I was in a hurry. Just posted the output, probably nothing special, like you say :) -
@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.
-
@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.1thanks (and to @MoonKnight as well) for the upgrade confidence nudge.
-
@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
manpages 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 theMakefilefor 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.
-
@Gertjan said in Unbound - CVE-2023-50387 and CVE-2023-50868:
[23.09.1-RELEASE][root@pfSense.bhf.tld]/root: pkg upgradeShould we all run this package upgrade?
