Bug 30235 - 389-ds-base new security issues CVE-2022-0918 and CVE-2022-0996
Summary: 389-ds-base new security issues CVE-2022-0918 and CVE-2022-0996
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA8-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2022-04-01 20:58 CEST by David Walser
Modified: 2024-10-22 14:04 CEST (History)
6 users (show)

See Also:
Source RPM: 389-ds-base-1.4.0.26-8.2.mga8.src.rpm
CVE: CVE-2022-0918, CVE-2022-0996
Status comment:


Attachments

Description David Walser 2022-04-01 20:58:22 CEST
Fedora has issued an advisory today (April 1):
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/PYT2IQJFHQWZENJJRY6EJB3XIFZGNT7F/

Mageia 8 is also affected.
David Walser 2022-04-01 20:58:35 CEST

Whiteboard: (none) => MGA8TOO

Comment 1 Lewis Smith 2022-04-03 09:16:45 CEST
Assigning to NicolasS, you did the most recent security fixes for this, so know where you are.

Assignee: bugsquad => nicolas.salguero

Comment 2 Nicolas Salguero 2022-04-04 09:58:49 CEST
Suggested advisory:
========================

The updated packages fix a security vulnerability:

A vulnerability was found in the 389 Directory Server that allows expired passwords to access the database to cause improper authentication. (CVE-2022-0996)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0996
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/PYT2IQJFHQWZENJJRY6EJB3XIFZGNT7F/
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.4.0.26-8.3.mga8
389-ds-base-snmp-1.4.0.26-8.3.mga8
cockpit-389-ds-1.4.0.26-8.3.mga8
lib(64)389-ds-base0-1.4.0.26-8.3.mga8
lib(64)389-ds-base-devel-1.4.0.26-8.3.mga8
lib(64)svrcore0-1.4.0.26-8.3.mga8
lib(64)svrcore-devel-1.4.0.26-8.3.mga8

from SRPM:
389-ds-base-1.4.0.26-8.3.mga8.src.rpm

CC: (none) => nicolas.salguero
Assignee: nicolas.salguero => qa-bugs
Whiteboard: MGA8TOO => (none)
CVE: (none) => CVE-2022-0996
Version: Cauldron => 8
Source RPM: 389-ds-base-1.4.0.26-11.mga9.src.rpm => 389-ds-base-1.4.0.26-8.2.mga8.src.rpm
Status: NEW => ASSIGNED

Comment 3 Herman Viaene 2022-04-04 16:14:54 CEST
MGA8-64 Plasma on Lenovo B50 in Dutch
No installation issues.
Following steps as in bug 22466 Comment 3 gives:
Your new DS instance 'mach5' was successfully created.
Exiting . . .
Log file is '/tmp/setupZvP0oz.log'

But then
# systemctl start dirsrv@localhost
Job for dirsrv@localhost.service failed because of unavailable resources or another system error.
See "systemctl status dirsrv@localhost.service" and "journalctl -xe" for details.
[root@mach5 ~]# systemctl -l status dirsrv@localhost
● dirsrv@localhost.service - 389 Directory Server localhost.
     Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; disabled; vendor preset: disabled)
     Active: failed (Result: resources)
        CPU: 0

apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: /usr/lib/systemd/system/dirsrv@.service:28: PIDFile= references a path below legacy directory /var/run/, updating /var/run/dirsrv/slapd-localhost.pid → /run/dirsrv/>
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: /usr/lib/systemd/system/dirsrv@.service:39: Missing '=', ignoring line.
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed to load environment files: No such file or directory
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed to run 'start-pre' task: No such file or directory
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed with result 'resources'.
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: Failed to start 389 Directory Server localhost..
[root@mach5 ~]# journalctl -xe | grep dirsrv
apr 04 15:56:27 mach5.hviaene.thuis systemd[1]: /usr/lib/systemd/system/dirsrv@.service:28: PIDFile= references a path below legacy directory /var/run/, updating /var/run/dirsrv/slapd-mach5.pid → /run/dirsrv/slapd-mach5.pid; please update the unit file accordingly.
apr 04 15:56:27 mach5.hviaene.thuis systemd[1]: /usr/lib/systemd/system/dirsrv@.service:39: Missing '=', ignoring line.
apr 04 15:56:27 mach5.hviaene.thuis systemd[1]: Created slice Slice /system/dirsrv.
░░ Subject: A start job for unit system-dirsrv.slice has finished successfully
░░ A start job for unit system-dirsrv.slice has finished successfully.
░░ Subject: A start job for unit dirsrv@mach5.service has begun execution
░░ A start job for unit dirsrv@mach5.service has begun execution.
apr 04 15:56:27 mach5.hviaene.thuis ds_systemd_ask_password_acl[15912]: ERROR: ld.so: object '/usr/lib64/dirsrv/lib/libjemalloc.so.2' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
apr 04 15:56:27 mach5.hviaene.thuis ds_systemd_ask_password_acl[15914]: ERROR: ld.so: object '/usr/lib64/dirsrv/lib/libjemalloc.so.2' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
apr 04 15:56:27 mach5.hviaene.thuis ds_systemd_ask_password_acl[15915]: ERROR: ld.so: object '/usr/lib64/dirsrv/lib/libjemalloc.so.2' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
apr 04 15:56:27 mach5.hviaene.thuis ds_systemd_ask_password_acl[15916]: ERROR: ld.so: object '/usr/lib64/dirsrv/lib/libjemalloc.so.2' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
apr 04 15:56:27 mach5.hviaene.thuis ns-slapd[15917]: ERROR: ld.so: object '/usr/lib64/dirsrv/lib/libjemalloc.so.2' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
░░ Subject: A start job for unit dirsrv@mach5.service has finished successfully
░░ A start job for unit dirsrv@mach5.service has finished successfully.
apr 04 15:56:31 mach5.hviaene.thuis audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dirsrv@mach5 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: /usr/lib/systemd/system/dirsrv@.service:28: PIDFile= references a path below legacy directory /var/run/, updating /var/run/dirsrv/slapd-localhost.pid → /run/dirsrv/slapd-localhost.pid; please update the unit file accordingly.
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: /usr/lib/systemd/system/dirsrv@.service:39: Missing '=', ignoring line.
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed to load environment files: No such file or directory
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed to run 'start-pre' task: No such file or directory
apr 04 15:57:00 mach5.hviaene.thuis systemd[1]: dirsrv@localhost.service: Failed with result 'resources'.
░░ The unit dirsrv@localhost.service has entered the 'failed' state with result 'resources'.
░░ Subject: A start job for unit dirsrv@localhost.service has failed
░░ A start job for unit dirsrv@localhost.service has finished with a failure.

Checked the offending line 39, but that is an include statement, and in the refered file I see only two non-commented statements which look OK.

CC: (none) => herman.viaene

Comment 4 Len Lawrence 2022-04-04 17:28:16 CEST
@Herman, comment 3
Not testing this but I installed the core packages to see what was what.  I must say it was very confusing and I am not sure exactly what I did following your procedure.  Lost track of the various names and labels and experimented as root and got it running.  I still do not know what it a directory server is.

Checked server status using the named directory manager (canopus I think which might correspond to your mach5).
# systemctl status dirsrv@canopus
● dirsrv@canopus.service - 389 Directory Server canopus.
     Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2022-04-04 16:05:09 BST; 4min 29s ago
    Process: 596602 ExecStartPre=/usr/libexec/ds_systemd_ask_password_acl /etc/dirsrv/slapd-canopus/dse.ldif (code=exited, status=0/SUC>
   Main PID: 596607 (ns-slapd)
     Status: "slapd started: Ready to process requests"
      Tasks: 65 (limit: 38132)
     Memory: 76.6M
        CPU: 2.359s
     CGroup: /system.slice/system-dirsrv.slice/dirsrv@canopus.service
             └─596607 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-canopus -i /var/run/dirsrv/slapd-canopus.pid

No idea if that helps.  Leaving this to you anyway.  It makes my head hurt.

CC: (none) => tarazed25

Comment 5 David Walser 2022-04-04 22:41:41 CEST
openSUSE has issued an advisory today (April 4):
https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/WUT5CGHERM6PDXKCM7Z3IJLGIYJ6V6AO/

It fixes this issue and one additional issue.

Version: 8 => Cauldron
Summary: 389-ds-base new security issue CVE-2022-0996 => 389-ds-base new security issues CVE-2022-0918 and CVE-2022-0996
Status comment: (none) => Patch available from openSUSE (for CVE-2022-0918)
Assignee: qa-bugs => nicolas.salguero
Whiteboard: (none) => MGA8TOO

Comment 6 Nicolas Salguero 2022-04-05 10:42:26 CEST
Suggested advisory:
========================

The updated packages fix security vulnerabilities:

A vulnerability was discovered in the 389 Directory Server that allows an unauthenticated attacker with network access to the LDAP port to cause a denial of service. The denial of service is triggered by a single message sent over a TCP connection, no bind or other authentication is required. The message triggers a segmentation fault that results in slapd crashing. (CVE-2022-0918)

A vulnerability was found in the 389 Directory Server that allows expired passwords to access the database to cause improper authentication. (CVE-2022-0996)

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0918
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0996
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/PYT2IQJFHQWZENJJRY6EJB3XIFZGNT7F/
https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/WUT5CGHERM6PDXKCM7Z3IJLGIYJ6V6AO/
========================

Updated packages in core/updates_testing:
========================
389-ds-base-1.4.0.26-8.4.mga8
389-ds-base-snmp-1.4.0.26-8.4.mga8
cockpit-389-ds-1.4.0.26-8.4.mga8
lib(64)389-ds-base0-1.4.0.26-8.4.mga8
lib(64)389-ds-base-devel-1.4.0.26-8.4.mga8
lib(64)svrcore0-1.4.0.26-8.4.mga8
lib(64)svrcore-devel-1.4.0.26-8.4.mga8

from SRPM:
389-ds-base-1.4.0.26-8.4.mga8.src.rpm

CVE: CVE-2022-0996 => CVE-2022-0918, CVE-2022-0996
Assignee: nicolas.salguero => qa-bugs
Status comment: Patch available from openSUSE (for CVE-2022-0918) => (none)
Version: Cauldron => 8
Whiteboard: MGA8TOO => (none)

Comment 7 Herman Viaene 2022-04-05 14:16:53 CEST
Doing  a complete reinstallation of this test setup. To be sure to get rid of all left-overs from previous tries.
Comment 8 Herman Viaene 2022-04-05 15:49:20 CEST
Sorry, this Comment 7 applies to the mediawiki update.
Comment 9 Herman Viaene 2022-04-05 16:47:28 CEST
Tested this new version in the same way and got the samee failure.
But looking back at bug 22466 Comment 4, it seems that this procedure fails all over,and it better is:
# start-dirsrv
Starting instance "mach5"
There is an ns-slapd running: 17274
[root@mach5 ~]# netstat -pant | grep 389 
tcp6       0      0 :::389                  :::*                    LISTEN      17274/ns-slapd      
[root@mach5 ~]# ldapsearch -x -h localhost -s base -b ""  "objectclass=*"
returning
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: objectclass=*
# requesting: ALL
#

#
dn:
objectClass: top
defaultnamingcontext: dc=hviaene,dc=thuis
dataversion: 020220405143559
netscapemdsuffix: cn=ldap://dc=mach5,dc=hviaene,dc=thuis:389

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

So OK'ing on the same basis ass the older update mentioned above.

Whiteboard: (none) => MGA8-64-OK

Comment 10 Thomas Andrews 2022-04-06 18:28:52 CEST
Validating. Advisory in Comment 6.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm, sysadmin-bugs

Dave Hodgins 2022-04-07 20:47:46 CEST

CC: (none) => davidwhodgins
Keywords: (none) => advisory

Comment 11 Mageia Robot 2022-04-09 23:21:52 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2022-0134.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

Comment 12 Gerald Boyle 2023-10-10 09:37:43 CEST Comment hidden (spam)

CC: (none) => peanutsunless

Comment 13 dorothy connor 2023-11-01 10:49:16 CET Comment hidden (spam)

CC: (none) => dorothyconnor456

Comment 14 tobi asss 2024-05-18 15:35:05 CEST Comment hidden (spam)

CC: (none) => tobias

Dave Hodgins 2024-05-18 17:04:19 CEST

CC: tobias => (none)

Comment 15 Lauren Waters 2024-10-21 17:34:12 CEST Comment hidden (spam)

CC: (none) => waniya.ultimateleather

katnatek 2024-10-21 19:45:11 CEST

CC: waniya.ultimateleather => (none)

Dave Hodgins 2024-10-22 14:02:00 CEST

CC: dorothyconnor456 => (none)

Dave Hodgins 2024-10-22 14:04:13 CEST

CC: peanutsunless => (none)


Note You need to log in before you can comment on or make changes to this bug.