SDDM doesn't start X with -nolisten tcp?

Development Packages and features requests
1

Hello,

Requirements:

I have Searched the forum for my issue and found nothing related or helpful
I have checked the Resources category
I have reviewed the Wiki for relevant information
I have read the the Release Notes and Errata

OpenMandriva Lx version:

OpenMandriva Lx release 6.0 (Vanadium) Rock for x86_64

Desktop environment (KDE, LXQT…):
Currently IceWM, but the issue appears to be with SDDM, which has not been changed beyond the following description.

Description of the issue (screenshots if relevant):
I noticed that by default, Xorg doesn’t seemed to be running with ‘-nolisten tcp’. This was resolved after modifying sddm.conf.
The forum won’t let me embed or link, so you can find an imgur album of the before and after screenshots at https://imgur.com/a/yZtsW7M

Relevant informations (hardware involved, software version, logs or output…):
While I have been switching window managers and desktop environments, (KDE has been uninstalled), I haven’t touched the login manager - so if I’m understanding correctly, this seems like a significant security issue of default configuration.

2

Welcome.

Are you saying that sddm is not bringing up the greeter, or that you login and cannot get to your DE or WM? Please clarify.

You are going to have to provide a basis for that. We don’t tend to ship our releases with “significant security issues.”

There is also nothing that stops you from posting output of the commands we asked for in the pinned post on how to get proper help.

3

SDDM was not running Xorg with the ‘-nolisten tcp’ flag enabled by default. Please view the linked screenshots for clarification.

4

I’ll move this to Development > Packages and features requests but it should be known that no distros consider this a valid method to report security concerns. You need to provide all the info to substantiate your claim.

Asking the project to go to a screenshot you supposedly made on your PC and uploaded to a IMG sharing site is about as insecure an interaction as you can get. This is your first post, so I have to seriously question your motives if you have not been otherwise involved in participating, troubleshooting, or development for OMLx.

Perhaps someone can assist you better if you make a legitimate and concerted effort to provide us with the things we asked you to instead of saying it’s a security issue and making a poor effort to assist us in solving it. These things do not lend to the credibility of your claim.

5

I agree, being met with suspicion on my first post about something concerning when being prevented from providing the most bit-exact method of proof by the forum software’s anti-spam is also an unpleasant experience on my end.

Upon perusal, I found no procedure for private reporting of security issues. I followed the reporting template, with cat /etc/release output and all relevant points from “How to get better results when posting about problems” included. I see no other relevant pinned threads, and you have provided no information what information is missing.

I will attempt to repost the screenshots here, in the hope the anti-spam measures have deemed me worthy:

Unmodified SDDM configuration:

image
image1158×179 27.8 KB

After adding the flag:

image
image1127×125 28.8 KB

The issue is obvious from the images, and no amount of typing increases the verifiability of the claims, but for those who only parse ASCII, sddm.conf looked like this

# Arguments to the X server.
# Default value is "-nolisten tcp"
ServerArguments=

There was no flag, and the x server was not running with -nolisten tcp by default as the comment claimed.

man xserver

   -nolisten trans‐type

           disables a transport type.  For  example,  TCP/IP  connec‐
           tions can be disabled with -nolisten tcp.  This option may
           be issued multiple times to disable listening to different
           transport  types.   Supported transport types are platform
           dependent, but commonly include:
           tcp     TCP over IPv4 or IPv6
           inet    TCP over IPv4 only
           inet6   TCP over IPv6 only
           unix    UNIX Domain Sockets
           local   Platform preferred local connection method

Therefore, from the information provided, the default SDDM configuration for OpenMandriva Rock opens up the X server to remote connections, which would seem to be a significant security issue that should be directed to the community out of a desire for social good, rather than just fixing it for myself.

I’ve confirmed that other distros run with this flag enabled by default, so unwarrented defensiveness that avoids the issue in preference of unrelated accusations warrants suspicion in itself. As the pinned thread states, you’re not paid to respond, but please keep the thread on topic from now on. If there is more relevant information that either of us can provide to resolve the issue, that would be a great direction.

Thank you.

6

Those are very cute retorts. We are not other distros. What security report are you reading that suggests this flag be mitigated other than, “the distro I came from did it so…”? That’s another pinned topic you should probably get around to reading.

It took more work to do this and many other efforts to be a smartass than it would have to just cat the files and post them in Markdown.

Other than that, you can mitigate it by firewalling on your system or with an edge device, and there may be legitimate reasons people would want this feature to be enabled (such as VNC). So, unless this is heading somewhere productive and respectful, I suggest you move on.

7

For those that stumble on this post wanting to report security related claims, we have a contact email at the bottom of our webpage that would be more than sufficient.

Please make reference to the source of the claim, along with a reproduction of the security issue and its impact on the system.

8

Thanks, I’ll contact them there.

1 Like
9

While you are waiting for a reply, here is some light reading:

”Mitigation

While the fixes cover all the cases currently known to X.Org, these are not the first issues in this area and are unlikely to be the last.

Users can reduce their exposure to issues similar to the ones in this advisory via these methods:

  • Configure the X server to prohibit X connections from the network by passing the -nolisten tcp command line option to the X server. Many OS distributions already set this option by default, and it will be set by default in the upstream X.Org release starting with Xorg 1.17.

  • Disable GLX indirect contexts. Some implementations have a configuration option for this. In Xorg 1.16 or newer, this can be achieved by setting the -iglx X server command line option. This option will be the default in Xorg 1.17 and later releases.

Consult your operating system’s documentation for details on setting X server command line options, as X servers are started by a variety of different methods on different platforms (startx, gdm, kdm, xdm, etc.).”

10

I just added -iglx, thanks. Maybe we should have a pinned thread for all the CVE recommendations that haven’t been implemented out of concern for convenience?

11

That is a 10 year old mitigation that was upstreamed. You need to do more research before you just say a distro is putting out “significant security issues” both without any prior interaction, and without proof. I don’t know where you sourced that from, but it’s not a place I would trust getting information from. Especially if it’s your goal to help us be “more secure” without any other interactions. It sounds a lot like Wayland concern trolling with no other motivation or information.

12

Just to put something into a clearer context, we will probably not be interested in your contributions. I specifically asked you to provide something that substantiates your claim, and you could not do it in this many days. I found that 10 year old report from the source in under a minute on the xorg foundation website, on accident. Instead of helping us you became indignant and rude when criticized. That isn’t how we do things here.

13

While the fixes cover all the cases currently known to X.Org, these are not the first issues in this area and are unlikely to be the last.

Users can reduce their exposure to issues similar to the ones in this advisory via these methods:

I believe this satisfies your question regarding:

But regardless of any related CVEs, it is not expected behavior on any desktop operating system for remote login to be accepted by default - there is no need to ‘substantiate a claim’ when that’s what the functionality does! A firewall can obviously block that, but I discovered days later that uninstalling plasma also uninstalls the firewall! Is it unreasonable to expect one to be able to remove layers of OS without opening oneself up to demons? A separate thread, to be sure.

Also, to my understanding, remote access of X is not required for VNC programs, just one way it can be done in practice. Closing off potential security holes by default and making the configuration of specific use cases easy is obviously ideal. If the reason for deleting the flag is truly to make low-latency VNC easier while maintaining a secure OS, maybe an option in OM Welcome is the best choice?

Why are you so defensive about the mere question of why a SDDM default flag was disabled, and that it’s probably a security issue? Herd mentality is never a guarantee of correctness, but if other OS’s implement it with no complaints and it’s literally the default that OM developers changed, I fail to see how the burden of proof is on me.

14

Not in the slightest.

Yes, when you make a claim the onus is on you to provide proof, not for me to disprove it. I am not using Plasma, either. iptables is still installed.

You need to read up on what tcp ports are for. ssh and VNC kind of need them. It provides other benefits, also.

Clearly you did not understand what I quoted from the link and have chosen to project instead of having a rational conversation about it. I’m going out on a limb and saying your former distro was De/buntu. They keep around 10 year old settings because if they break their distro, half the ecosystem probably breaks along with it.

When an upstream project defaults something, you no longer need to pollute configs in the downstream with it. In fact, it can sometimes produce deprecation warnings that could be interpreted as errors in some distros. The absence of a flag that no longer needs to be set is not an indication that the default is no longer set.

Had you acted in good faith and acknowledged your ignorance on this topic, perhaps you wouldn’t need to blame me for your discomfort. It would have made for a much more productive conversation and learning experience. Sadly, it doesn’t seem like that was your intent.

1 Like
15

The forum antispam is legit, necessary, and common like at any other forum.
For the record I did increase your user level as soon as I saw your post and realized that you were a trusted user. I think it has been matter of hours if not minutes after you wrote here.

16

I understand, and thanks for that, I’d have edited the post. I don’t have much time to check back here.

TCP ports obviously work with -nolisten tcp enabled, I wouldn’t be able to post here otherwise! Are you even a developer? The issue is allowing direct access to the Xserver via TCP connections.

before:

image
image1158×179 27.8 KB

after:
image
image1127×125 28.8 KB

SDDM master has the config’s default set to -nolisten tcp.

I can see from other posts around the forum that zeroability is the biological equivalent of chatgpt hooked up to an amygdala, so I’ll respond to qualified replies from here on.

The technical ignorance I do have, which is the key to the use of a question mark in the topic, is the full consequence of the flag being omitted, given I mostly do any systems administration under duress.

Xfwp seems to be installed by default (difficult for me to confirm without reinstalling in the current state - is there a list of default packages available on the abf somewhere?)

man xfwp

The X firewall proxy (xfwp) is an application layer gateway proxy that may be run on a network firewall host to forward X traffic across the firewall. Used in conjunction with the X server Security extension and authorization checking, xfwp constitutes a safe, simple, and reliable mechanism both to hide the addresses of X servers located on the Intranet and to enforce a server connection policy. Xfwp cannot protect against mischief originating on the Intranet; however, when properly configured it can guarantee that only trusted clients originating on authorized external Internet hosts will be allowed inbound access to local X servers.

I reason as follows:

If there is no firewall

-nolisten tcp will obviously allow anyone to try logging in, brute forcing passwords, etc.

If there is a firewall,

If xfwp is installed,

this appears to give the ability to bypass the firewall and access said Xserver, depending on configuration. I’m yet unable to find any configs related to it.

from man xfwp:
“If xfwp is run without a configuration file and thus no sitepolicy is defined, if xfwp is using an X server where xhost + has been run to turn off host-based authorization checks, when a client tries to connect to this X server via xfwp, the X server will deny the connection. If xfwp does not define a sitepolicy, host-based authorization must be turned on for clients to connect to an X server via the xfwp.”

xfwp shows access control enabled, only authorized clients can connect, with my username, which seems like it will allow my user to be connected to remotely if the Xserver’s -nolisten tcp is not enabled.

if xfwp isn’t installed,

perhaps things are fine? Xserver lives inaccessible behind the firewall, in which case… why enable Xserver tcp in the first place.

For all cases, the old Xorg security recommendation appears to still apply, and the SDDM developers seem to agree.

Given the above, this all seems to do what it says on the tin, opening up the system’s attack profile.

If someone knowledgeable in such matters could take the time to reply, that would be great. Thank you.

P.S. I tried emailing contact@openmandriva.org multiple times, but I get Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command).

17

Why, yes I am. If that meets your “Appeal to Authority,” logical fallacy standards.

Oop there’s the “Ad hominem,” logical fallacy that shows up when trolls run out of correct or useful information.

How about this? You provide the proof on an OMLx system that you have a valid compromise instead of using your buddy ChatGPT to write support scenarios and terrible comebacks. Reading Wayland porn and screenshotting your settings is not a valid security report.

1 Like
18

Oh, look at that. A valid and useful contribution.

19

Starting with Xorg 1.17, released in 2015, the default state for the X server is to not listen to tcp ports. The -nolisten flag in the config files is redundant. Removing that flag doesn’t open tcp ports, the only way to do that is to explicitly set -listen tcp in your configs. The same thing applies to GLX support, the default value was changed to -iglx, so if you wanted graphical support in a remote X session you would have to explicitly define +iglx. Since sddm uses an X session itself it is already using -nolisten tcp and -iglx, and any configs that explicitly include those flags are just unnecessary.

When X11 first released the primary way to use a computer was to login to a central ‘mainframe’ from a remote ‘terminal’, so all connections had to be tunneled over udp/tcp ports. Obviously this has not been the case for a long time, up until 2015 to close this potential attack vector distributions and display managers would have explicitly defined -nolisten tcp, but since the xorg 1.17 release this is not necessary.

If you did not see -listen tcp then it was not enabled. It seems like you just noticed a lack of the -nolisten tcp flag, which you shouldn’t see because it would be redundant.

1 Like
20

:backhand_index_pointing_up:

2 Likes