X.Org Server & XWayland Hit By Four More Security Issues

[guiodic]

Today I discovered that in order for Drag and Drop to work on Chromium in Wayland, I have to start it as an X11 application. LOL

[pracedru]

X11 protocol core design had the horrible idea that you would be inside single trusted business LAN. Yes core design predates WAN being used in a big way.

This is true. X11 also works very poorly on networks with high latency or package drops. Latencies above 20ms makes X11 almost entirely unusable.

[oiaohm]

I.e An application run in i.e an Xnest, Xephyr, etc with its own Xauthority file (and display socket) will be unable to access any of your other programs running on your main Xorg session.

This is not always true. You run into the problem where you use Xnest/Xepher and you can see the environmental vars displaying the other sessions and other Xauthority files. Yes you can end up with applications poorly coded with hard coded connect to display :0 and of course the Xnest/Xepher is display :1 or greater so the application connects to the wrong screen and find valid Xauthority.

This nesting for anti snooping turns out not to be as dependable as one would hope.

As I mentioned before, only applications that you give permission to (by giving them access to the Xauthority file), will be able to access your Xorg session.

That the problem is really simple to give a program Xauthority file access by mistake. XACE exists because Xauthority was declared far too course but when you use XACE you run into the problem of it being a mandatory access control system that is not designed to be changed on the fly as general desktop user actions require.

Dbus and policykit solutions being made today is kind of halfway between XACE X11 and X11 with just Xauthority. So more secure than X11 with just Xauthority and not as much of a total nightmare as XACE with X11.

[kpedersen]

You run into the problem where you use Xnest/Xepher and you can see the environmental vars displaying the other sessions and other Xauthority files.

You really don't. This is always due to dbus and other mess screwing up sessions. Giving dbus your Xauthority is where the mistake is made. Once Gnome/Wayland matures to start adding all the daft IPC features under the sun for Wayland / waypipe, you will encounter the same mess. Its not a Wayland or an X11 fault; it is a bad engineering fault for desktop developers who don't ever test on multi-user setups correctly.

One where you can see it done well (after a lot of cleaning up from Sun) is Solaris 10's JDS (Gnome 2.x) where they engineered it to be correct for VNC and Sun Ray Software.

Yes you can end up with applications poorly coded with hard coded connect to display :0 and of course the Xnest/Xepher is display :1 or greater so the application connects to the wrong screen and find valid Xauthority.

I tend to start my X instance on :2 (mostly so I can identify broken software early on). This (or randomization) should be the default.

[oiaohm]

You really don't. This is always due to dbus and other mess screwing up sessions.

Sorry to say I saw Xnest break out before dbus existed. So I have been around the Unix world for a very long time.

Once Gnome/Wayland matures to start adding all the daft IPC features under the sun for Wayland / waypipe, you will encounter the same mess.

This with Gnome is unlikely to happen. Gnome is going RDP for remote. RDP by Microsoft has a lot on controls designed in to limit what remote application can do on local machine.

Waypipe says that wayland over network is possible but since waypipe does not transport the dbus part so this results in particular intergrations breaking users are likely to avoid this and go for RDP or some other protocol like it with more fine grain controls.

I tend to start my X instance on :2 (mostly so I can identify broken software early on). This (or randomization) should be the default.

One hard reality is what ever is the default will be the one some programmer somewhere will hard code and not notice their mistake so causing end users headaches.. This is why it kind of good you connect to Wayland server and you are first given bare min privilege makes incorrect connection way less damaging.

[rrveex]

Problem major item users use that is web browsers is progressively getting more and more powerful.
[...]

Yes we do need a functional container solution for applications. Everyone on the Internet really does need it.

That's what I said. Besides, people could enable JavaScript only for "business" sites, like banking. Or use another "device" than the one they navigate on porn sites on.

Lot of ways rrveex you are being the idiot. The reality is security models always need to evolve. Modern Web browsers have made it way more simple to get untrusted programs on to your computer that can do many horrible things. People lose their bank accounts/google/youtube/... online accounts all the time due to attacks against browsers.

That's what I said too. People are idiots. People google "google.com" so they further google "firefox download", then press on the first link, which isn't mozilla.org

Then they start their flashy new troian to go to some instaporn site and press on "you are the milionth visitor, press here fill in your banking information so we give you 1 million dollars".

Fortunately (for them), the malware won't be able to take screenshots of their stupidity, because PipeWire screen-grab probably won't work because of the bugs.

olaohm, I didn't call *you* an idiot, don't really get it why you felt as if I had attacked you personally (like you did to me). Perhaps you some kind of defender of the rights of idiots everywhere?

[kpedersen]

Sorry to say I saw Xnest break out before dbus existed. So I have been around the Unix world for a very long time.

As you know, dbus is really just the current version of the same old dodgy paradigm. tooltalk / CORBA / DCOP were some earlier examples.
I doubt it was tooltalk you saw facilitating a break out from Xnest, so I am going to assume it was a Linux technology rather than Unix?

This is true. X11 also works very poorly on networks with high latency or package drops. Latencies above 20ms makes X11 almost entirely unusable.

Have you tried an alternative like VNC across that kind of connection? Turns out X11 ain't so bad. Obviously Microsoft's RDP (non-raster version) is currently one of the best solutions... annoyingly.

[F.Ultra]

Wayland is developed (in a manner of speaking since they do not write code) by a new breed of developers who never understood how Xorg worked. Historical Xorg developers like Keith Packard have nothing to do with Wayland.

Kristian Høgsberg who created the first Wayland spec worked on X11 for decades (first for RH, then for Intel and then for RH again) and created both AIGLX and DRI2 for X11, so not hardly some one new who does not understand how Xorg works.

[rastersoft]

you specifically mentioned "framebuffer"?

As I mentioned before, only applications that you give permission to (by giving them access to the Xauthority file), will be able to access your Xorg session.

I.e An application run in i.e an Xnest, Xephyr, etc with its own Xauthority file (and display socket) will be unable to access any of your other programs running on your main Xorg session.

Yes, my fault. When I said "framebuffer" I meant "the bitmap content of other windows".

Anyway, I did some tests, and enabling the security extension seems to disable, at least, OpenGL acceleration and fullscreen support.

[oiaohm]

As you know, dbus is really just the current version of the same old dodgy paradigm. tooltalk / CORBA / DCOP were some earlier examples.
I doubt it was tooltalk you saw facilitating a break out from Xnest, so I am going to assume it was a Linux technology rather than Unix?

I first saw the issue on a HPUX provided graphical tool. So a Unix then I also saw it under BSD and Linux latter. Bad X11 applications are not just restricted to Linux.

You are right tooltalk had nothing todo with the breakout. It was way the aquired X11 code in the program was written. I started with the :0 display then searched for the matching Xauth. The oldest applications I found this horrible hard cored :0 was from 1984 of course there could be old. This defect predates tooltak/CORBA/DCOP and dbus.

Yes tooltalk was Sun tech. But you need to look up the Sun presentations on XACE work you will find them list cases of applications with the same code problem I cam across in the past and the issue starts older than tooltalk new programs keep on turning up with the same defect most intentional malware where they are designed to connect if possible to the host X11 server..