Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 7, 2023 22:52 UTC (Sat) by kreijack (guest, #43513)
In reply to: Hutterer: X servers no longer allow byte-swapped clients by default by ukleinek
Parent article: Hutterer: X servers no longer allow byte-swapped clients

> It seems to me, this is only a default setting and you still can enable that feature via a cmdline switch. Letting the niche users who operate a s390 or powerpc system headless add that switch to their configuration sounds OK for me. (Though there seem to be some (solvable) problems with Xwayland.)

My understanding is that the switch has to be added not at the s390/powerpc side but at the "intel" side.

Said that, I don't understand if there is a real exploit or not. And even if this is the case, I don't understand how this can be more "risky" than allowing a remote client to connect a X11 server.

Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 8, 2023 10:17 UTC (Sun) by whot (subscriber, #50317) [Link]

> My understanding is that the switch has to be added not at the s390/powerpc side but at the "intel" side.

That is correct. The switch needs to be enabled at the X server that remote foreign-endian clients connect to, i.e. on your local workstation.

Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 19, 2023 17:05 UTC (Thu) by mrugiero (guest, #153040) [Link] (5 responses)

As a general rule, where there's parsing there are exploits lurking. If you can avoid malicious actors accessing one that is not normally used (and further, not normally real-world tested) then you should

Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 19, 2023 19:13 UTC (Thu) by kreijack (guest, #43513) [Link] (4 responses)

> As a general rule, where there's parsing there are exploits lurking. If you can avoid malicious actors accessing one that is not normally used (and further, not normally real-world tested) then you should.

If you apply this "general rule", you ends to switch off the computer...

In the real world we need to take compromise between different factors, like security, availability, flexibility, productivity....

Frankly speaking I don't see any gain to preventing by default a connection from bigendian architecture.
By default X doesn't accept non local connection. These were always opt in, or enabling the tcp protocol via '-tcp' switch or using "ssh -X".

So I have to repeat my question: how more dangerous could be a bug in the "endianess-translator" than running code from a foreign system ?

Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 19, 2023 20:49 UTC (Thu) by mrugiero (guest, #153040) [Link] (3 responses)

> If you apply this "general rule", you ends to switch off the computer...
>
> In the real world we need to take compromise between different factors, like security, availability, flexibility, productivity....

That's what "when you can" means. You compromise different factors. One of them is supporting niche use cases with fragile code by default. In that case, you tilt for security: the user should know what they're doing, so they can enable it if it's a problem. It's pretty much as flexible and productive, as many people pointed out. Worst case, one reboot away. Unless you want me to believe that not only people _do_ often use cross-endian X but also that they may not know before hand they want that.

> Frankly speaking I don't see any gain to preventing by default a connection from bigendian architecture.
> By default X doesn't accept non local connection. These were always opt in, or enabling the tcp protocol via '-tcp' switch or using "ssh -X".

And yet you still would need to opt out of the mixed endian when you have to actively decide to enable TCP. Besides, big endian is so uncommon at this point that you are assuming the server is running in little endian :)
Another funny thing is that most of the defense of X is network transparency, so people should make up their minds, right? If it's so common to do `ssh -X` then you are certainly using TCP, right?

> So I have to repeat my question: how more dangerous could be a bug in the "endianess-translator" than running code from a foreign system ?

Strictly more dangerous. It's additive. The more you expose, the greater the risk. At worst it's low-hanging fruit.

Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 20, 2023 11:58 UTC (Fri) by mrugiero (guest, #153040) [Link]

> And yet you still would need to opt out of the mixed endian when you have to actively decide to enable TCP. > Besides, big endian is so uncommon at this point that you are assuming the server is running in little endian :)
> Another funny thing is that most of the defense of X is network transparency, so people should make up their minds, right? If it's so common to do `ssh -X` then you are certainly using TCP, right?

Not only that, but X11 is a viable vector for escalation of privilege (in many cases it still runs as root), so you need not only consider clients in a different machine but malicious programs installed as a normal user trying to get to root by forging big endian packets. Now the local-only case shuts down a path known to be exploitable, reducing the number of ways such a program can compromise root.

Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 22, 2023 15:05 UTC (Sun) by kreijack (guest, #43513) [Link] (1 responses)

> If it's so common to do `ssh -X` then you are certainly using TCP, right?

ssh -X doesn't need TCP. In fact I have '-nolisten tcp' as X server option, but I am also able to run "ssh -X"

> > So I have to repeat my question: how more dangerous could be a bug in the "endianess-translator" than running code from a foreign system ?

> Strictly more dangerous. It's additive. The more you expose, the greater the risk. At worst it's low-hanging fruit.

This is the point: you need to compare the gain in security versus the cost of usability. Saying "we are more secure disabling a feature", quick would ends to "switch off the computer because it is more secure".

My position is that the bigger risk is to run a program in a remote computer. Running this program over X is a lower risk (not because it is low in absolute, but because it is low related to the previous risk).

Hutterer: X servers no longer allow byte-swapped clients by default

Posted Jan 22, 2023 18:19 UTC (Sun) by mrugiero (guest, #153040) [Link]

> ssh -X doesn't need TCP. In fact I have '-nolisten tcp' as X server option, but I am also able to run "ssh -X"

I stand corrected on the use of TCP, but you're still exposing the X server, only indirectly.

> This is the point: you need to compare the gain in security versus the cost of usability. Saying "we are more secure disabling a feature", quick would ends to "switch off the computer because it is more secure".

Precisely. And the gain in security versus the cost of usability is favorable, since this feature is very, very niche. They are not disabling network transparency, nor simply dropping the feature. They're defaulting to not using it with a trivial switch.

> My position is that the bigger risk is to run a program in a remote computer. Running this program over X is a lower risk (not because it is low in absolute, but because it is low related to the previous risk).

It is, but given the particular user may need to, at least you reduce bug surface. It's not just in running the program over X, BTW, but about allowing it to execute code that is known to be both seldom used in an honest manner and prone to security bugs. If the most likely usage is exploits and the places where it is actually desirable are expected to have some kind of sysadmin or at least tech-savvy owner, then the most sensible approach is to tell them to explicitly enable it on the next update, which BTW requires the restart anyway. You are blowing the "cost of usability" out of proportion.