ISC has issued advisories on June 21: https://kb.isc.org/docs/cve-2023-2828 https://kb.isc.org/docs/cve-2023-2911 The issues are fixed upstream in 9.18.16: https://downloads.isc.org/isc/bind9/9.18.16/doc/arm/html/notes.html#notes-for-bind-9-18-16 Patches are here: https://downloads.isc.org/isc/bind9/9.16.42/patches/ https://downloads.isc.org/isc/bind9/9.18.16/patches/ Mageia 8 is also affected by CVE-2023-2828.
Status comment: (none) => Fixed upstream in 9.18.16Whiteboard: (none) => MGA8TOO
guillomovitch is the registered maintainer, and put up v9.8.15. So it seems sensible to assign this update to you.
Assignee: bugsquad => guillomovitch
Ubuntu has issued an advisory for this on June 21: https://ubuntu.com/security/notices/USN-6183-1
Debian has issued an advisory for this on June 25: https://www.debian.org/security/2023/dsa-5439
patches pushed into cauldron
Whiteboard: MGA8TOO => (none)Version: Cauldron => 8CC: (none) => mageia
Slackware has issued an advisory for CVE-2023-3341 on September 21: http://www.slackware.com/security/viewer.php?l=slackware-security&y=2023&m=slackware-security.348276
Whiteboard: (none) => MGA9TOO, MGA8TOOCC: (none) => nicolas.salgueroVersion: 8 => CauldronStatus comment: Fixed upstream in 9.18.16 => Fixed upstream in 9.18.19Summary: bind new security issues CVE-2023-2828 and CVE-2023-2911 => bind new security issues CVE-2023-2828, CVE-2023-2911 and CVE-2023-3341Assignee: guillomovitch => qa-bugsSource RPM: bind-9.18.15-1.mga9.src.rpm => bind-9.18.15-2.mga9.src.rpm
Assignee: qa-bugs => pkg-bugs
Ubuntu has issued an advisory for this on September 20: https://ubuntu.com/security/notices/USN-6390-1
Summary: bind new security issues CVE-2023-2828, CVE-2023-2911 and CVE-2023-3341 => bind new security issues CVE-2023-3341 and CVE-2023-4236Version: Cauldron => 9Whiteboard: MGA9TOO, MGA8TOO => (none)
Blocks: (none) => 32323
Suggested advisory: ======================== The updated packages fix security vulnerabilities: The code that processes control channel messages sent to `named` calls certain functions recursively during packet parsing. Recursion depth is only limited by the maximum accepted packet size; depending on the environment, this may cause the packet-parsing code to run out of available stack memory, causing `named` to terminate unexpectedly. Since each incoming control channel message is fully parsed before its contents are authenticated, exploiting this flaw does not require the attacker to hold a valid RNDC key; only network access to the control channel's configured TCP port is necessary. (CVE-2023-3341) A flaw in the networking code handling DNS-over-TLS queries may cause `named` to terminate unexpectedly due to an assertion failure. This happens when internal data structures are incorrectly reused under significant DNS-over-TLS query load. (CVE-2023-4236) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-3341 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4236 https://ubuntu.com/security/notices/USN-6390-1 ======================== Updated packages in core/updates_testing: ======================== bind-9.18.15-2.2.mga9 bind-chroot-9.18.15-2.2.mga9 bind-devel-9.18.15-2.2.mga9 bind-dlz-filesystem-9.18.15-2.2.mga9 bind-dlz-ldap-9.18.15-2.2.mga9 bind-dlz-mysql-9.18.15-2.2.mga9 bind-dlz-sqlite3-9.18.15-2.2.mga9 bind-dnssec-utils-9.18.15-2.2.mga9 bind-utils-9.18.15-2.2.mga9 lib(64)bind9.18.15-9.18.15-2.2.mga9 from SRPM: bind-9.18.15-2.2.mga9.src.rpm
Status: NEW => ASSIGNEDAssignee: pkg-bugs => qa-bugsStatus comment: Fixed upstream in 9.18.19 => (none)
MGA9-64 Xfce on Acer Aspire 5253 No installation issues Ref bug 29427 Comment 4 for testing Followed that not completely successful, in that a few steps are needed: In /etc/named.conf comment out the line "listen-on-v6 port 53 { ::1; };" and add a line "listen-on port 53 { W.X.Y.Z; };" W.X.Y.Z being the real IP address of the server. Then I can # systemctl restart named # systemctl -l status named ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/usr/lib/systemd/system/named.service; disabled; preset: disabled) Active: active (running) since Wed 2023-09-27 17:58:46 CEST; 7s ago Process: 121174 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/bin/named-checkconf -z "$NAMEDCONF"; e> Process: 121176 ExecStart=/usr/sbin/named -u named -c ${NAMEDCONF} $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 121177 (named) Tasks: 4 (limit: 4317) Memory: 6.1M CPU: 351ms CGroup: /system.slice/named.service └─121177 /usr/sbin/named -u named -c /etc/named.conf Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './DNSKEY/IN': 2001:dc3::35#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './NS/IN': 2001:dc3::35#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './DNSKEY/IN': 2001:500:2d::d#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './NS/IN': 2001:500:2d::d#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './DNSKEY/IN': 2001:500:a8::e#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './NS/IN': 2001:500:a8::e#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './DNSKEY/IN': 2001:7fe::53#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: network unreachable resolving './NS/IN': 2001:7fe::53#53 Sep 27 17:58:46 mach7.hviaene.thuis named[121177]: managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete) Sep 27 17:58:47 mach7.hviaene.thuis named[121177]: resolver priming query complete: success But I still have a niggle I have to correct for: $ nslookup mach2 Server: 192.168.2.7 Address: 192.168.2.7#53 ** server can't find mach2: NXDOMAIN Using the FQDN gives the same result. Investgating further ......
CC: (none) => herman.viaene
Uploaded the Advisory from comment 7 Please remove the advisory keyword and obsolete comment 7, if for some reason the bind packages need another update before being validated.
Keywords: (none) => advisoryCC: (none) => marja11
Tx to the help I got from the Mageia forum, I can now confirm that the named service works OK on M9. It was a question of having the exact syntax for the zone files. BTW, neither MCC nor webmin generate correct zone files, but that's a separate issue.
Whiteboard: (none) => M9-64-OK
Whiteboard: M9-64-OK => MGA9-64-OK
Validating.
Keywords: (none) => validated_updateCC: (none) => andrewsfarm, sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2023-0303.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED