Bug 31865

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-38712
CVE: CVE-2023-30570 => CVE-2023-30570,CVE-2023-38710,CVE-2023-38711,CVE-2023-38712
Status comment: Fixed upstream in version 4.11 => Fixed upstream in version 4.12

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.rpm
Assignee: smelror => qa-bugs
CC: (none) => nicolas.salguero
Status: NEW => ASSIGNED
Whiteboard: MGA8TOO => (none)
Status comment: Fixed upstream in version 4.12 => (none)

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.

Validating on base of clean install/uninstall

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (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 => RESOLVED
Resolution: (none) => FIXED