Upstream have released a patch to fix CVE-2023-30570 https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570.txt Fixed in version 4.11. Cauldron updated.
Status comment: (none) => Fixed upstream in version 4.11CVE: (none) => CVE-2023-30570
RedHat has issued an advisory for this today (May 4): https://access.redhat.com/errata/RHSA-2023:2120
Fedora has issued an advisory for this on May 12: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/APPXJHIVUBS4I2AVIB6C36ED6XNUYVC2/
Severity: normal => critical
New security fixes in version 4.12 https://github.com/libreswan/libreswan/blob/26f713c76db27cfd8498c560cac5eade46165155/CHANGES#L28 * SECURITY IKEv2: Fixes https://libreswan.org/security/CVE-2023-38710 * SECURITY IKEv1: Fixes https://libreswan.org/security/CVE-2023-38711 * SECURITY IKEv1: Fixes https://libreswan.org/security/CVE-2023-38712
Summary: libreswan new security issue - CVE-2023-30570 => libreswan new security issue - CVE-2023-30570,CVE-2023-38710,CVE-2023-38711,CVE-2023-38712CVE: CVE-2023-30570 => CVE-2023-30570,CVE-2023-38710,CVE-2023-38711,CVE-2023-38712Status comment: Fixed upstream in version 4.11 => Fixed upstream in version 4.12
Version: 8 => 9Whiteboard: (none) => MGA8
Whiteboard: MGA8 => MGA8_TOO
CC: (none) => luigiwalserWhiteboard: MGA8_TOO => MGA8TOO
updating to 4.12 in mga8 will break atleast networkmanager-l2tp (it's already broken in mga9 with 4.11) so bug 32211 needs to be validated before this can be pushed...
Depends on: (none) => 32211
Suggested advisory: ======================== The updated package fixes security vulnerabilities: pluto in Libreswan before 4.11 allows a denial of service (responder SPI mishandling and daemon crash) via unauthenticated IKEv1 Aggressive Mode packets. (CVE-2023-30570) An issue was discovered in Libreswan before 4.12. When an IKEv2 Child SA REKEY packet contains an invalid IPsec protocol ID number of 0 or 1, an error notify INVALID_SPI is sent back. The notify payload's protocol ID is copied from the incoming packet, but the code that verifies outgoing packets fails an assertion that the protocol ID must be ESP (2) or AH(3) and causes the pluto daemon to crash and restart. (CVE-2023-38710) An issue was discovered in Libreswan before 4.12. When an IKEv1 Quick Mode connection configured with ID_IPV4_ADDR or ID_IPV6_ADDR receives an IDcr payload with ID_FQDN, a NULL pointer dereference causes a crash and restart of the pluto daemon. (CVE-2023-38711) An issue was discovered in Libreswan 3.x and 4.x before 4.12. When an IKEv1 ISAKMP SA Informational Exchange packet contains a Delete/Notify payload followed by further Notifies that act on the ISAKMP SA, such as a duplicated Delete/Notify message, a NULL pointer dereference on the deleted state causes the pluto daemon to crash and restart. (CVE-2023-38712) References: https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570.txt https://access.redhat.com/errata/RHSA-2023:2120 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/APPXJHIVUBS4I2AVIB6C36ED6XNUYVC2/ https://libreswan.org/security/CVE-2023-38710 https://libreswan.org/security/CVE-2023-38711 https://libreswan.org/security/CVE-2023-38712 ======================== Updated package in core/updates_testing: ======================== libreswan-4.12-1.mga9 from SRPM: libreswan-4.12-1.mga9.src.rpm
Source RPM: (none) => libreswan-4.11-1.mga9.src.rpmAssignee: smelror => qa-bugsCC: (none) => nicolas.salgueroStatus: NEW => ASSIGNEDWhiteboard: MGA8TOO => (none)Status comment: Fixed upstream in version 4.12 => (none)
Keywords: (none) => advisory
MGA9-64 Plasma Wayland on HP-Pavillion No installation issues Networking on my home network works apparently OK (checked via access to NFS-shares on my desktop PC), but nevertheless something strange comes up: $ nslookup mach1 Server: 192.168.2.1 Address: 192.168.2.1#53 Non-authoritative answer: Name: mach1.fritz.box Address: 45.76.93.104 Name: mach1.fritz.box Address: 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828 That I have never seen before, but $ nslookup mach1.hviaene.thuis Server: 192.168.2.1 Address: 192.168.2.1#53 Name: mach1.hviaene.thuis Address: 192.168.2.1 is the response I get from my own DNS-server, and normally I get the response whether it is the machine name or the FQDN. It is the same for any other name in my DNS-setup.
CC: (none) => herman.viaene
RH mageia 9 x86_64 Install current package LC_ALL=C urpmi libreswan To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (distrib1)") lib64ldns3 1.8.3 1.mga9 x86_64 libreswan 4.11 1.mga9 x86_64 4.8MB of additional disk space will be used. 1.3MB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) y https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/lib64ldns3-1.8.3-1.mga9.x86_64.rpm https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/libreswan-4.11-1.mga9.x86_64.rpm installing lib64ldns3-1.8.3-1.mga9.x86_64.rpm libreswan-4.11-1.mga9.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ###################################################################################### 1/2: lib64ldns3 ###################################################################################### 2/2: libreswan ###################################################################################### Update to testing version LC_ALL=C urpmi --auto --auto-update medium "QA Testing (32-bit)" is up-to-date medium "QA Testing (64-bit)" is up-to-date medium "Core Release (distrib1)" is up-to-date medium "Core Updates (distrib3)" is up-to-date medium "Nonfree Release (distrib11)" is up-to-date medium "Nonfree Updates (distrib13)" is up-to-date medium "Tainted Release (distrib21)" is up-to-date medium "Tainted Updates (distrib23)" is up-to-date medium "Core 32bit Release (distrib31)" is up-to-date medium "Core 32bit Updates (distrib32)" is up-to-date medium "Nonfree 32bit Release (distrib36)" is up-to-date medium "Tainted 32bit Release (distrib41)" is up-to-date medium "Tainted 32bit Updates (distrib42)" is up-to-date installing libreswan-4.12-1.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64 Preparing... ###################################################################################### 1/1: libreswan ###################################################################################### 1/1: removing libreswan-4.11-1.mga9.x86_64 ###################################################################################### Remove packages LC_ALL=C urpme libreswan lib64ldns3 removing lib64ldns3-1.8.3-1.mga9.x86_64 libreswan-4.12-1.mga9.x86_64 removing package libreswan-4.12-1.mga9.x86_64 1/2: removing libreswan-4.12-1.mga9.x86_64 ###################################################################################### removing package lib64ldns3-1.8.3-1.mga9.x86_64 2/2: removing lib64ldns3-1.8.3-1.mga9.x86_64 ###################################################################################### Not issues
Removing libreswan makes nslookup giving the normal answer from my DNS-server. So as far as I am concerned, I don't want this package on my machines.
Sorry, jumping to conclusions too quick when I had changed two things at the same time. Getting the correct response from the nslookup was triggered by explicitely declaring the search domain in MCC - Internet - setup internet connection. So as far as my knowledge goes, there is nothing wrong with libreswan.
CC: (none) => andrewsfarm
Validating on base of clean install/uninstall
CC: (none) => sysadmin-bugsKeywords: (none) => validated_updateWhiteboard: (none) => MGA9-64-OK
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2024-0085.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED