[Security] Mitigation & Patch

marav · 10-23-2023, 11:09 AM

Vim

CVE-2023-5535

Code:

Use After Free in GitHub repository vim/vim prior to v9.0.2010.

https://www.cve.org/CVERecord?id=CVE-2023-5535

marav · 10-25-2023, 06:12 AM

Xorg & Xwayland

Security advisory:
Issues in X.Org X server prior to 21.1.9 and Xwayland prior to 23.2.2
https://lists.x.org/archives/xorg-an...er/003430.html

opty · 11-07-2023, 09:22 AM

sudo 1.9.15:

Quote:

The sudoers plugin has been modified to make it more resilient to ROWHAMMER attacks on authentication and policy matching. This addresses CVE-2023-42465.

The sudoers plugin now constructs the user time stamp file path name using the user-ID instead of the user name. This avoids a potential problem with user names that contain a path separator ('/') being interpreted as part of the path name. A similar issue in sudo-rs has been assigned CVE-2023-42456.

marav · 11-12-2023, 02:14 PM

egl-wayland

Code:

--- egl-wayland.SlackBuild      2023-11-12 21:13:01.309687241 +0100
+++ egl-wayland.SlackBuild.1    2023-11-12 21:12:45.620969219 +0100
@@ -99,7 +99,7 @@
 cd ..
 
 # Install the NVidia ICD file:
-mkdir $PKG/usr/share/egl/egl_external_platform.d/
+mkdir -p $PKG/usr/share/egl/egl_external_platform.d/
 cp -a $CWD/10_nvidia_wayland.json $PKG/usr/share/egl/egl_external_platform.d/
 chown root:root $PKG/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json
 chmod 644 $PKG/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json

marav · 11-13-2023, 08:08 AM

tigervnc

I think TigerVNC needs to be rebuilt against the fixed Xorg for CVE 2023-5367 and 2023-5380

Code:

x/xorg-server-21.1.9-x86_64-1.txz:  Upgraded.
  This update fixes security issues:
  OOB write in XIChangeDeviceProperty/RRChangeOutputProperty.
  Use-after-free bug in DestroyWindow.
  For more information, see:
    https://lists.x.org/archives/xorg-announce/2023-October/003430.html
    https://www.cve.org/CVERecord?id=CVE-2023-5367
    https://www.cve.org/CVERecord?id=CVE-2023-5380
  (* Security fix *)

Aeterna · 11-13-2023, 03:17 PM

Nothing can be done now but users should be aware of this problem
https://arstechnica.com/security/202...g-edge-attack/

henca · 11-14-2023, 12:43 AM

Quote:

Originally Posted by Aeterna

Nothing can be done now but users should be aware of this problem
https://arstechnica.com/security/202...g-edge-attack/

What could be done by users before openssh is updated is to stop using rsa keys. From "man ssh-keygen":

Code:

     -t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
             Specifies the type of key to create.  The possible values are
             “dsa”, “ecdsa”, “ecdsa-sk”, “ed25519”, “ed25519-sk”, or “rsa”.

regards Henrik

Petri Kaukasoina · 11-14-2023, 03:57 AM

The article told that openssh "has deployed a countermeasure for decades". "The researchers traced the keys they compromised to devices that used custom, closed-source SSH implementations that didn’t implement the countermeasures found in OpenSSH and other widely used open source code libraries. The devices came from four manufacturers: Cisco, Zyxel, Hillstone Networks, and Mocana."

jmccue · 11-14-2023, 07:52 AM

Quote:

Originally Posted by Petri Kaukasoina

The article told that openssh "has deployed a countermeasure for decades". "The researchers traced the keys they compromised to devices that used custom, closed-source SSH implementations that didn’t implement the countermeasures found in OpenSSH and other widely used open source code libraries. The devices came from four manufacturers: Cisco, Zyxel, Hillstone Networks, and Mocana."

FWIW, on an OpenBSD System (7.4) I have, I had to re-create my ssh keys. sshing into it would either hang or it would take a very long time to login in. Once in it was very slow.

IIRC I saw that OpenBSD recommended to recreate the ssh keys. They said having an old RSA key will cause issues, which happened to me. IIRC, they recommended using ed25519 keys. So I re-created the keys using ed25519 on Slackware and other systems then removed the rsa keys.

henca · 11-16-2023, 11:48 AM

Slackware current has gotten the latest gimp 2.10.36 as an "upgrade". However, maybe also Slackware 15.0 should get gimp 2.10.36 as a "Security fix"?

According to https://www.gimp.org/news/2023/11/07...ulnerabilities 2.10.36 fixed some vulnerabilities. According to https://www.zerodayinitiative.com/advisories/published/ the fixed vulnerabilities

CVE-2023-44441
CVE-2023-44442
CVE-2023-44443
CVE-2023-44444

are all about remote code execution caused by buffer overflow when reading broken/malicious files in the following formats:

DDS (Microsoft format often used for textures)
PSD (Photoshop files)
PSP (Paint Shop Pro files).

Slackware 15.0 has gimp version 2.10.30, Slackware 14.2 and older have gimp version 2.8.18 and older which might be less compatible. Besides, all those 14 versions of Slackware will soon be EOL.

regards Henrik

marav · 11-24-2023, 04:46 AM

Vim

CVE-2023-48231
CVE-2023-48232
CVE-2023-48233
CVE-2023-48234
CVE-2023-48235
CVE-2023-48236
CVE-2023-48237

Fixed in: Vim >= 9.0.2120

opty · 12-07-2023, 01:14 PM

Consider changing

Code:

patches/packages/rdfind-1.6.0-x86_64-1_slack15.0.txz:  Upgraded.

to

Code:

patches/packages/rdfind-1.6.0-x86_64-1_slack15.0.txz:  Added.

in ChangeLog.txt so

Code:

slackpkg install-new

will find it.

volkerdi · 12-07-2023, 01:29 PM

Quote:

Originally Posted by opty

Consider changing

But marav will get mad at me lol

drumz · 12-07-2023, 02:13 PM

Quote:

Originally Posted by volkerdi

But marav will get mad at me lol

Solution:

Code:

Xxx Dec xx xx:xx:xx UTC 2023
patches/packages/rdfind-1.6.0-x86_64-1_slack15.0.txz:  Removed.
  If I edit the Changelog marav will find me in my sleep.  So let's just remove this for now.

then...

Code:

Xxx Dec xx xx:xx:xx UTC 2023
patches/packages/rdfind-1.6.0-x86_64-2_slack15.0.txz:  Added.
  slackpkg doesn't know what to do with a new "upgraded" package, so "add" it instead.

This is entirely untested. I don't use slackpkg.

marav · 12-08-2023, 07:10 AM

Quote:

Originally Posted by volkerdi

But marav will get mad at me lol

Nope

I've completely rewritten this script part, and I no longer use a diff between the new and the previous changelog
Now I just cut everything after the first +--------------------------+

Code:

awk '/^\+--------------------------+/{exit}1' < <(cat ${_changelog_txt}))

So, no matter what you do with the latest changelog, once it's been modified, I always catch the right one