The officially official Devuan Forum!

Altoid

Member

Registered: 2017-05-07

Posts: 1,581  

X.Org Security Advisory: Security issue in the X server

Hello:

Got this today in my inbox:

-----------------------------------------------------------

X.Org Security Advisory: February 07, 2023

Security issue in the X server
==============================

This issue can lead to local privileges elevation on systems
where the X server is running privileged and remote code execution for
ssh X forwarding sessions.

* CVE-2023-0494/ZDI-CAN-19596: X.Org Server DeepCopyPointerClasses
use-after-free

A dangling pointer in DeepCopyPointerClasses can be exploited by
ProcXkbSetDeviceInfo() and ProcXkbGetDeviceInfo() to read/write into
freed memory.

Patches
-------
A patch for this issue has been committed to the xorg server git
repository. xorg-server 21.1.7 will be released shortly and will include
this patch.

- commit 0ba6d8c37071131a49790243cdac55392ecf71ec

  Xi: fix potential use-after-free in DeepCopyPointerClasses
 
  CVE-2023-0494, ZDI-CAN 19596

Thanks
======

The vulnerabilities have been discovered by Jan-Niklas Sohn working with
Trend Micro Zero Day Initiative.

-----------------------------------------------------------

Best,

A.

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: X.Org Security Advisory: Security issue in the X server

Phoronix have covered this:

https://www.phoronix.com/news/X.Org-Ser … -2023-0494

Some salient quotes from that piece:

The X.Org Server keeps on giving when it comes to security vulnerabilities with its massive, aging, and ill-maintained code-base.
[...]
It's been ten years already since a security researcher commented that the X.Org Server codebase security is "worse than it looks" and it continues to be the source of new security vulnerabilities for this still commonly used component to the Linux desktop.

Which is why I switched to Wayland some time ago :-)

And especially relevant for Devuan users:

Thankfully for many modern X.Org Server environments these days, the X.Org Server is no longer run as root / elevated privileges but for older systems and in other select configurations unfortunately remains running in such a vulnerable configuration.

The default Xfce desktop for Devuan uses SLiM or LightDM and both run X under the root user so both are vulnerable to this exploit.

Starting the desktop via GDM or startx will cause X to be run under the normal user and so avoid this vulnerability completely.

To switch to startx either remove or disable (eg, update-rc.d slim disable) the display manager and add this line to the end of ~/.profile (or ~/.bash_profile if you use bash and have that file already) to start the desktop automatically after log in at TTY1:

[ "$(tty)" = /dev/tty1 ] && exec startx

To change the default desktop for all users run this command:

# update-alternatives --config x-session-manager

To change the default desktop on a per-user basis create a file at ~/.xsession containing the commands needed to start that desktop, as per https://wiki.debian.org/Xsession.

Or just switch to Wayland :-)

---

Brianna Ghey — Rest In Power

aluma

Member

Registered: 2022-10-26

Posts: 646  

Re: X.Org Security Advisory: Security issue in the X server

Debian buster fixed this bug.
Maybe it's easier to wait until the queue is up to us?
https://security-tracker.debian.org/tra … -2023-0494

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: X.Org Security Advisory: Security issue in the X server

This vulnerability has been discovered but I'm sure there are *many* others lurking in that massively bloated code base. Running X under the root user really is a terrible decision. I am shocked that the Devuan developers consider this situation acceptable in any way.

---

Brianna Ghey — Rest In Power

andyprough

Member

Registered: 2019-10-19

Posts: 327  

Re: X.Org Security Advisory: Security issue in the X server

To switch to startx either remove or disable (eg, update-rc.d slim disable) the display manager

Or just 'sudo sysv-rc-conf' and disable slim or lightdm, which is what I did, what I like to call 'the easy way'.

and add this line to the end of ~/.profile (or ~/.bash_profile if you use bash and have that file already) to start the desktop automatically after log in at TTY1:

[ "$(tty)" = /dev/tty1 ] && exec startx

Or just be a normal person and write a ~/.xinitrc file with 'exec dwm' (or whatever your wm/desktop is), or with xfce4 just use the 'startxfce4' command instead of 'startx'.

Or just switch to Wayland :-)

... in another 15 years when Wayland is ready for most use cases ...

Last edited by andyprough (2023-02-07 20:01:30)

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: X.Org Security Advisory: Security issue in the X server

Or just be a normal person and write a ~/.xinitrc file with 'exec dwm' (or whatever your wm/desktop is), or with xfce4 just use the 'startxfce4' command instead of 'startx'.

Using ~/.xinitrc is actually not recommended for De{bi,vu}an systems, ~/.xsession should be used instead; see startx(1) for more on this.

Using startx with no ~/.xinitrc or ~/.xsesssion will start either /usr/bin/x-session-manager or /usr/bin/x-window-manager (if the former is not present) which allows the default desktop to be changed with update-alternatives without having to mess around editing text files like a cave person.

---

Brianna Ghey — Rest In Power

thierrybo

Member

Registered: 2017-11-11

Posts: 107  

Re: X.Org Security Advisory: Security issue in the X server

Well,

this xinitrc / xsession always messes me up.

On a basic X11 system installation, if you have no Display Manager, you usually have to run dbus , xrdb , dbus, ssh agent , gpg agent in your .xinitrc then start your Window Manager.

On Debian what is confusing is that even on a bare installation you can't experience a full straight X11 experience as it would be with Arch or Void Linux for example, because with Debian policy you have many helpers that runs everything for you:

-> xinit -> /etc/X11/xinit/xinitrc -> /etc/X11/Xsession

that runs everything for you.

On top of that if the Window Manager Debian maintainer add the WM to Debian alternatives /usr/bin/x-session-manager and/or /usr/bin/x-window-manager , you even don't need .xinitrc because /usr/bin/x-window-manager is ran by /etc/X11/Xsession .

HOWEVER if you want to use several Windows Managers, you HAVE TO use .xinitrc to specify the WM to launch. BUT if you do use .xinitrc , the whole /etc/X11/Xsession script that does all the magic is not used anymore.

So what to do? Copying the whole /etc/X11/Xsession in ~/.xsession ? No, THE RIGHT ANSWER ON DEBIAN IS:

In your .xinitrc, replace:

exec /usr/bin/<WM>

with

exec /etc/X11/Xsession /usr/bin/<WM>

This way you run yourself the system Xsession script. And if you read Xsession / Xsession.d script flow, you can discover that Xsession look for one parameter. If one is provided, it will run it at the end of the script as the WM to launch, instead of searching all other places it usually look for. This way you continue to benefit from all the "automation" Debian provides.

Now about .xinitrc or .xsession .

The main difference is that if you use a Display Manager, usually .xsession is read by the DM, not .xinitrc, so if you use one, I would only use .xsession.

If you do not use any DM, you can use one or the other, it will work evenly, PROVIDED THAT you do not enter the exact same line in both file :

If you have to use

exec /etc/X11/Xsession /usr/bin/<WM>

in .xinitrc to fully use system Xsession magic, if you do NOT use .xinitrc, /etc/X11/Xsession will be used. So you can't run /etc/X11/Xsession in your .xsession. AND inside its code flow, it will look for your .xsession file and exec it as the last command to run the Window Manager.

So the last line of your .xsession should just be:

exec /usr/bin/<WM>

andyprough

Member

Registered: 2019-10-19

Posts: 327  

Re: X.Org Security Advisory: Security issue in the X server

cave person

Very important that we not misgender any of our trans Cro-Magnon friends. Good on you hoas.

Using ~/.xinitrc is actually not recommended for De{bi,vu}an systems, ~/.xsession should be used instead

Believe it or not, even though it often probably seems as if I know everything and have magical sed and awk powers, this was a new one for me. Very interesting.

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: X.Org Security Advisory: Security issue in the X server

On a basic X11 system installation

For clarity: my original post in this thread was mostly about launching full desktop environments with startx. Simple window manager based desktops are a whole different kettle of bananas and I would presume that anybody interested in those would know enough to be able to configure them manually.

---

Brianna Ghey — Rest In Power

Kelsoo

Member

Registered: 2016-12-09

Posts: 56  

Re: X.Org Security Advisory: Security issue in the X server

startx /usr/bin/wm or startx /usr/local/bin/wm then chuck it in my .bashrc with an one letter alias then fire up "auto" again another alias auto=/path/to/autostart.sh. At least until I'm happy everything works as it should... I guess I'm a Cave Man. :-)

hunter0one

Member

Registered: 2021-12-31

Posts: 71  

Re: X.Org Security Advisory: Security issue in the X server

I would use Wayland but in the latest stable its buggy as hell on KDE, especially with Flatpaks.

Head_on_a_Stick

Member

From: London

Registered: 2019-03-24

Posts: 3,125  

Website

Re: X.Org Security Advisory: Security issue in the X server

GNOME works fine with flatpaks, they're even recommended by the developers. The Wayland desktop is the default for Debian bullseye. Everybody loves GNOME, right?

---

Brianna Ghey — Rest In Power

hunter0one

Member

Registered: 2021-12-31

Posts: 71  

Re: X.Org Security Advisory: Security issue in the X server

Everybody loves GNOME, right?

LOL, don't we all?

Really, I've been having a desktop identity crisis the past 2 weeks. I just stuck with KDE.

jue-gen

Member

Registered: 2022-07-07

Posts: 120  

Re: X.Org Security Advisory: Security issue in the X server

... I just stuck with KDE.

I always had trouble with KDE Plasma and Wayland. I've cursed it and wished it to hell. But your post triggered me yesterday to try it again (Daedalus). At least no crashes I noticed. And Wayland runs. I'm still reluctant, but I'm also optimistic and hope that it will be a usable and recommendable system when Dadalus becomes stable....

hunter0one

Member

Registered: 2021-12-31

Posts: 71  

Re: X.Org Security Advisory: Security issue in the X server

... I just stuck with KDE.

I always had trouble with KDE Plasma and Wayland. I've cursed it and wished it to hell. But your post triggered me yesterday to try it again (Daedalus).

I should rephrase my use of KDE. I like KDE applications, I do not like KDE Plasma. I can't stand the flat Breeze theme and similar to GNOME's Adwaita it sticks to everything. Trying to make Plasma look a bit more like pre-Plasma is hopeless. I hope LiquidShell gets developed more and makes its way into Devuan one day (who knows, I could package it). I typically use Trinity desktop, but the really old Qt version and inability to keep up like MATE has driven me away.

The newer Plasma versions after Chimaera have improved Wayland support by a lot. I'm ready to see what Daedulus will bring, if I'm still running Plasma by then..

jue-gen

Member

Registered: 2022-07-07

Posts: 120  

Re: X.Org Security Advisory: Security issue in the X server

... I like KDE applications, I do not like KDE Plasma. ...

Yes, I can understand that very well.
Wayland is apparently more secure. By the way, I liked to use KDE applications in LXDE or Xfce. Of course it was also very nice in LXQt. Now I came back to KDE (I started with KDE in 2001 [SuSE 7.2]) because I wanted Wayland and I like the KDE applications. Right now I like it quite a bit.
Have a nice rest of the weekend - best regards
Addendum: in continuous use, however, I now actually notice some problems. For example, the taskbar is gone from time to time, nothing can be inserted from the cache, etc. In LXQt, which I use in parallel on the same computer, these problems do not occur ... but there again I have no Wayland

Last edited by jue-gen (2023-02-14 20:40:11)

jue-gen

Member

Registered: 2022-07-07

Posts: 120  

Re: X.Org Security Advisory: Security issue in the X server

... The default Xfce desktop for Devuan uses SLiM or LightDM and both run X under the root user so both are vulnerable to this exploit.

Starting the desktop via GDM or startx will cause X to be run under the normal user and so avoid this vulnerability completely. ... )

Perhaps I have not understood the problem correctly. SLiM or LightDM is clear. But I am thinking about it:
How is it with SDDM?
When I start Plasma Wayland, that is o.k.
But if I start e.g. LXDE with SDDM, how is that.

fsmithred

Administrator

Registered: 2016-11-25

Posts: 2,486  

Re: X.Org Security Advisory: Security issue in the X server

... The default Xfce desktop for Devuan uses SLiM or LightDM and both run X under the root user so both are vulnerable to this exploit.

Starting the desktop via GDM or startx will cause X to be run under the normal user and so avoid this vulnerability completely. ... )

Perhaps I have not understood the problem correctly. SLiM or LightDM is clear. But I am thinking about it:
How is it with SDDM?
When I start Plasma Wayland, that is o.k.
But if I start e.g. LXDE with SDDM, how is that.

lxdm and sddm both run X as root. To check that, run

ps aux |grep X

jue-gen

Member

Registered: 2022-07-07

Posts: 120  

Re: X.Org Security Advisory: Security issue in the X server

lxdm and sddm both run X as root. To check that, run

ps aux |grep X

Thanks for this! It looks like I'll have to give it some thought. I would be interested in more information on this topic and strategies for improvement.

GlennW

Member

From: Brisbane, Australia

Registered: 2019-07-18

Posts: 644  

Re: X.Org Security Advisory: Security issue in the X server

This is my third time reading through this thread and I'd like to THANK YOU ALL!

Some of this tech has escaped me for a long time and I'm slowly putting the jigsaw puzzle pieces into position.

I like the bling but I want the security.

regards Glenn

---

pic from 1993, new guitar day.

stopAI

Member

Registered: 2023-04-04

Posts: 186  

Re: X.Org Security Advisory: Security issue in the X server

So the last line of your .xsession should just be:

exec /usr/bin/<WM>

Hello. Should not be

.xsession

but

.xsessionrc

The Debian reference manual describes how the defaults work:

If the user has a ~/.xsessionrc file, read it.
If a specific session was selected in the DM (GDM, KDM, WDM, LightDM, ...) , run it.

Otherwise, if the user has a ~/.xsession or ~/.Xsession file, run it.

Otherwise, if the /usr/bin/x-session-manager command exists, run it.

Otherwise, if the /usr/bin/x-window-manager command exists, run it.

Otherwise, if the /usr/bin/x-terminal-emulator command exists, run it.

This file should be executable. Here is example of

.xsessionrc 

#!/bin/bash

# Load resources

xrdb ~/.Xresources

setxkbmap -layout "us,lt,ru" -option "grp:menu_toggle"

picom --config ~/.config/picom/picom.conf &

exec xmonad

GlennW

Member

From: Brisbane, Australia

Registered: 2019-07-18

Posts: 644  

Re: X.Org Security Advisory: Security issue in the X server

Well, I got stuck this time, no tty's and a non-responsive keys and screen.

Why do I have no tty's?

Even now after a re-config to get the gui again and still no tty's. ona day at a time...

---

pic from 1993, new guitar day.

MLEvD

Member

Registered: 2021-02-14

Posts: 141  

Re: X.Org Security Advisory: Security issue in the X server

Well, I got stuck this time, no tty's and a non-responsive keys and screen.

Why do I have no tty's?

Even now after a re-config to get the gui again and still no tty's. ona day at a time...

Please post a copy of your

 /etc/inittab 

?

GlennW

Member

From: Brisbane, Australia

Registered: 2019-07-18

Posts: 644  

Re: X.Org Security Advisory: Security issue in the X server

TIA,

/etc/inittab

# /etc/inittab: init(8) configuration.
# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.
id:2:initdefault:

# Boot-time system configuration/initialization script.
# This is run first except when booting in emergency (-b) mode.
si::sysinit:/etc/init.d/rcS

# What to do in single-user mode.
~~:S:wait:/sbin/sulogin --force

# /etc/init.d executes the S and K scripts upon change
# of runlevel.
#
# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin --force

# What to do when CTRL-ALT-DEL is pressed.
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

# Action on special keypress (ALT-UpArrow).
#kb::kbrequest:/bin/echo "Keyboard Request--edit /etc/inittab to let this work."

# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
#  <id>:<runlevels>:<action>:<process>
#
# Note that on most Debian systems tty7 is used by the X Window System,
# so if you want to add more getty's go ahead but skip tty7 if you run X.
#
1:2345:respawn:/sbin/getty --noclear 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
#
# or on a USB serial line
#U0:23:respawn:/sbin/getty -L ttyUSB0 9600 vt100

# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

# Example for systemd-nspawn
# Only /dev/console exists inside nspawn, so we need a getty on that.
# Also make sure to comment out the gettys on tty* above.
#C0:2345:respawn:/sbin/getty -8 --noclear --keep-baud console 115200,38400,9600

That's it... I dont remember modifying it.

---

pic from 1993, new guitar day.