Hutterer: X servers no longer allow byte-swapped clients
These days, encountering a Big Endian host is increasingly niche, letting it run an X client that connects to your local little-endian X server is even more niche. I think the only regular real-world use-case for this is running X clients on an s390x, connecting to your local intel-ish (and thus little endian) workstation. Not something most users do on a regular basis. So right now, the byte-swapping code is mainly a free attack surface that 99% of users never actually use for anything real. So... let's not do that?
Posted Jan 6, 2023 14:35 UTC (Fri)
by dullfire (guest, #111432)
[Link] (6 responses)
I know there are several distros out there that use/can-use BE, Adelie for one. I use gentoo in BE on my P9, and since my P9 is normally headless X11 forwarding from is is the norm for me. I think this use case is probably a bit less nitch that Peter believes it is.
Posted Jan 6, 2023 14:46 UTC (Fri)
by saffroy (guest, #43999)
[Link] (1 responses)
Posted Jan 6, 2023 14:50 UTC (Fri)
by dullfire (guest, #111432)
[Link]
Posted Jan 6, 2023 15:56 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (3 responses)
Posted Jan 6, 2023 16:07 UTC (Fri)
by dullfire (guest, #111432)
[Link] (2 responses)
That's a misreading of what I said. I gave a quote that seems to indicate Peter believes the only real-world use case is in conjunction with s390 systems. I gave a counter example. And further explained that there are distros (like Adelie, and BE PPC64 gentoo) that this could effect. Is it at all niche? Certainly. Is it as niche as Peter seems to suggest? Almost certainly not (and I would consider the difference between "only certain cases of s390 systems" and "PPC64/Adelie, BE gentoo, s390, +others" to be a significant difference, even if both are "niche").
Posted Jan 6, 2023 18:31 UTC (Fri)
by clump (subscriber, #27801)
[Link] (1 responses)
Posted Jan 7, 2023 13:02 UTC (Sat)
by khim (subscriber, #9252)
[Link]
I don't think it's rare. I would even say it should be pretty normal by now. Granted, it's still little-endian.
Posted Jan 6, 2023 15:31 UTC (Fri)
by dskoll (subscriber, #1630)
[Link] (16 responses)
According to the article, it's only disabled by default and can be re-enabled with a command-line option. So a good decision IMO.
Posted Jan 6, 2023 15:32 UTC (Fri)
by higuita (guest, #32245)
[Link]
Posted Jan 6, 2023 17:25 UTC (Fri)
by jreiser (subscriber, #11027)
[Link] (5 responses)
Finding and changing the invocation of the X server can be a chore because common desktop environments do not expose it. It may be necessary to wrap the executable file in a shell script which massages argv[].
Posted Jan 7, 2023 0:36 UTC (Sat)
by dskoll (subscriber, #1630)
[Link] (3 responses)
If the X server you use happens to be Xorg, you can also re-enable this in the xorg.conf config file.
Posted Jan 7, 2023 8:02 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link] (1 responses)
Posted Jan 7, 2023 19:50 UTC (Sat)
by sima (subscriber, #160698)
[Link]
So you'd need to change the default on the le client platforms/distros, which is exactly where the potential security problem is most likely.
Posted Jan 7, 2023 20:37 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link]
Posted Jan 8, 2023 18:59 UTC (Sun)
by rqosa (subscriber, #24136)
[Link]
Posted Jan 7, 2023 2:51 UTC (Sat)
by wahern (subscriber, #37304)
[Link] (8 responses)
If supporting byte-swapped clients is considered unnecessary complexity, the proper fix would be to mandate one endianness in the protocol. Then all the byte swapping code could be *removed*, which would be the perfect opportunity to *audit* each site for general bounds checking bugs. But the real potential for bugs here is probably less the byte-swapping call sites and more the sites *lacking* the byte-swapping calls; and you're not protecting those by asking a malicious peer to pinky promise not to byte-swap any fields when they first connect.
Papering over such speculative issues this way may be the worse of all the options.
Posted Jan 7, 2023 11:28 UTC (Sat)
by psychon (guest, #113278)
[Link] (7 responses)
There is a function to parse a request packet in native endian. Then there is a function to endianness-swap a packet. To handle a request of a different endian, you first call the endianess-swapping function on the packet and then the normal parse function. I bet that sending out reply packets and events works similarly.
Thus, when a native-endian client sends a request with a byte-swapped length field, the normal request parsing function will most likely have a working bounds check and reject this request.
When a byte-swapped client sends a request with an incorrect length field, then the function to endianess-swap this packet is invoked. This is a much less commonly executed code path and thus it is way more likely that no one yet noticed that there is a missing/broken length check.
Posted Jan 7, 2023 21:40 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Well, unless someone is running a BE server with a LE client that is potentially malicious. Or the LE server is potentially malicious and we're trying to protect the BE client. Do real users care about either of those problems? The latter seems really weird IMHO because usually the server is "my computer" and the client is "the other computer," and the former implies a rather unusual hardware configuration.
Posted Jan 8, 2023 10:12 UTC (Sun)
by whot (subscriber, #50317)
[Link] (2 responses)
Parts of the X protocol are written so that you don't know what to swap until you've parsed everything else before. e.g. requests with lists of items where each item is of different length (including, iirc, sometimes the length defined by some type field). So basically - you need a full X server to parse enough of the protocol to byte-swap everything. And that's a fair bit of effort that realistically no-one is going to step up to do. libxcb would probably help with that a lot, but that's been on the wishlist for at least 15 years now.
Posted Jan 9, 2023 21:14 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
Posted Jan 10, 2023 9:18 UTC (Tue)
by geert (subscriber, #98403)
[Link]
The proper way to handle this would be to fix the endianness in the protocol, and have a grace period, like we did for ext2fs (little endian) and XFS (big endian) decades ago. Unfortunately it's a bit late for that, and a short grace period won't work, as there may be clients that cannot be updated easily. Network protocol compatibility is different from file system compatibility, where you can just convert the file system once, and be done with it (there were never many big-endian ext2 file systems in the first place, as the problem was identified and solved early).
[1] None of my BE hardware is supported by contemporary X servers, as Xorg dropped the support for that "exotic" hardware a while ago. So in reality, I only care about using BE clients connecting to an LE server on modern hardware, which is fast enough to make the byte-swapping overhead unnoticeable.
Posted Jan 9, 2023 12:47 UTC (Mon)
by geert (subscriber, #98403)
[Link] (2 responses)
Seriously, this breaks interoperability with other (non-Xorg) systems. If this was Linux, it would be reverted at the blink of an eye ("Do not break userpace ABI people depend on").
Less-serious: will IPv7 be little-endian?
Posted Jan 9, 2023 13:40 UTC (Mon)
by geert (subscriber, #98403)
[Link] (1 responses)
Posted Jan 19, 2023 17:00 UTC (Thu)
by mrugiero (guest, #153040)
[Link]
Posted Jan 6, 2023 20:52 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (1 responses)
Posted Jan 7, 2023 13:06 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Of course it would! If you don't attach you machine to a network it immediately becomes much safer. And if you don't plug a power cord and don't have a battery… it would be extra super-safe! Not much useful, of course, but that's another question.
Posted Jan 7, 2023 6:58 UTC (Sat)
by oldtomas (guest, #72579)
[Link] (2 responses)
To sum up: the proposal
- complexifies the X code base (add an option to hide a feature)
...for what gain again?
If we fear hidden bugs lurking: just adding two more test cases to the test suite would add less complexity and bring in more gain, I guess.
I think it isn't a good idea.
Posted Jan 7, 2023 11:30 UTC (Sat)
by psychon (guest, #113278)
[Link]
Sorry, but: Which two more test cases would that be?
I'd rather expect this to be a job for a fuzzer since no one would want to write the thousand test cases that are needed by hand. And even if they did, with so many cases it is way more likely that one missing length check for one sub-field of a certain request was still missed.
Posted Jan 9, 2023 22:26 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
It's basically adding one "assert" + the option to turn it off. How incredibly complicated /s
> ...for what gain again?
It's called "attack surface" and based on the blog and some comments here it's apparently very big. This is due to how complex the protocol is.
I wonder how many people objecting in the comments are actually affected by this. I bet very few.
Posted Jan 7, 2023 9:08 UTC (Sat)
by ukleinek (subscriber, #56625)
[Link] (8 responses)
Posted Jan 7, 2023 22:52 UTC (Sat)
by kreijack (guest, #43513)
[Link] (7 responses)
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.
Posted Jan 8, 2023 10:17 UTC (Sun)
by whot (subscriber, #50317)
[Link]
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.
Posted Jan 19, 2023 17:05 UTC (Thu)
by mrugiero (guest, #153040)
[Link] (5 responses)
Posted Jan 19, 2023 19:13 UTC (Thu)
by kreijack (guest, #43513)
[Link] (4 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....
Frankly speaking I don't see any gain to preventing by default a connection from bigendian architecture.
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 ?
Posted Jan 19, 2023 20:49 UTC (Thu)
by mrugiero (guest, #153040)
[Link] (3 responses)
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.
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 :)
> 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.
Posted Jan 20, 2023 11:58 UTC (Fri)
by mrugiero (guest, #153040)
[Link]
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.
Posted Jan 22, 2023 15:05 UTC (Sun)
by kreijack (guest, #43513)
[Link] (1 responses)
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).
Posted Jan 22, 2023 18:19 UTC (Sun)
by mrugiero (guest, #153040)
[Link]
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.
Posted Jan 9, 2023 9:31 UTC (Mon)
by jem (subscriber, #24231)
[Link] (11 responses)
If virtually nobody is using big endian X11 clients anymore, and those who do simply re-enable the byte swapping code again (because they have to), what problem does this change really solve? If the byte-swapping code really is this buggy after all these years, what about all the other code that should defend itself against malicious input? This sounds like sweeping the problem under the carpet: "we made it impossible to send a badly formatted X11 protocol packet, because it is now prohibited to introduce yourself as a big endian client".
Posted Jan 9, 2023 22:40 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (7 responses)
So you're asking: "Why reduce the attack surface when there is some left?"
Posted Jan 10, 2023 13:44 UTC (Tue)
by jem (subscriber, #24231)
[Link] (6 responses)
Posted Jan 10, 2023 16:22 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (5 responses)
In this case, it's worth doing because Xorg runs extra code when dealing with an other-endianness client, and that code has been a great source of security bugs over the years. By disabling other-endianness clients, you get to cut out a whole pile of unmaintained code that's also rarely used.
The cases that are well-tested, and maintained, are big endian client connecting to big endian server, and little endian client connecting to little endian server. The cases that are problematic, and will now be disabled by default, are little endian client connecting to big endian server, and big endian client connecting to little endian server; these run "SProcs" - code which swaps endianness inside structures - which are not run at all if you have the same endianness on both sides of the link.
The two fundamental causes of trouble here are:
If X11 had been designed with all the knowledge we acquired in the first 15 years since its release in 1987, it'd have had a true negotiation, and the server could tell the client "I only handle little endian" or "I only handle big endian" (as well as "I handle both endian choices"), making this something we could push to the client over time. But that'd involve a time machine.
Similarly, if someone cared enough to do the work of changing all of the X11 protocol handling from hand-crafted C to machine-generated code that always did the right thing, it'd be solved. But no-one's stepped up to do that since the people working on XCB moved onto working on Wayland instead.
Posted Jan 10, 2023 20:31 UTC (Tue)
by geert (subscriber, #98403)
[Link] (4 responses)
As jem noted, 2 is still an attack surface in case no byte-swapping is done.
W.r.t. 1, I guess the number of different messages is fairly constant, as X is an old, mature protocol. As mixing little and big endian clients and servers was much more popular in the past, I expect this code to actually be mature as well.
To ensure correctness, you can use tools to generate the swapping code from the structs, or anotate the struct members, and use sparse (cfr. the __leX annotations used in the Linux kernel).
One of the key features of X11 is interoperability. It would be a real pity to make that a thing of the past...
Posted Jan 10, 2023 21:50 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (3 responses)
There's still plenty of messages that have bad SProcs, unfortunately - it's been one of the biggest attack vectors over the last 10 years. And many of the thousands of messages a modern X server can interpret are relatively new, not well-aged code.
Yes, correctness could be done with tools to generate the swapping code from the structs. But no-one who cares about mixed-endianness operation has stepped up to do the work, which is why it hasn't happened :-(
Unfortunately, if no-one's going to do the work to maintain the code, the easy option is to remove it- this is what the Linux kernel does, too.
Posted Jan 11, 2023 0:06 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (2 responses)
This is much NICER than what the kernel (and other projects) do. The kernel deletes the code, whereas this can be turned on again _at run-time_! Not even a need to recompile anything. This is closer to a "Are you sure?" dialog box than to what the kernel does.
Posted Jan 11, 2023 13:40 UTC (Wed)
by geert (subscriber, #98403)
[Link] (1 responses)
2. While technically this can be re-enabled at "run-time" instead of at "compile-time", I'd rather call it at "boot-time", as having to restart my X server causes almost as much inconvenience as having to reboot my machine.
BTW, Xorg removed Xfbdev, which was the only remaining server variant supporting non-chunky frame buffer formats.
Posted Jan 11, 2023 18:09 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Good point.
> as having to restart my X server causes almost as much inconvenience as having to reboot my machine.
You're not going to hit this issue until you upgrade the X server on your workstation and _restart it anyway_. Then it will be a one-line and _once off_ configuration change.
It is for sure an inconvenience but it is being repeatedly blown out of proportion; these complaints look more and more like bad faith.
> I guess lots of bugs (and security issues) are lurking there...
Again: "let's not reduce the attack surface because there's more elsewhere"?
Posted Jan 11, 2023 9:49 UTC (Wed)
by jamesh (guest, #1159)
[Link] (2 responses)
If the only people who have byte swapping support enabled are those who know they need it, then that greatly reduces the reach of such malware.
Posted Jan 11, 2023 13:31 UTC (Wed)
by geert (subscriber, #98403)
[Link] (1 responses)
Posted Jan 11, 2023 15:21 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Because, for deep legacy reasons, the vulnerable SProcs are for those parts of the X protocol where validation is done by the SProc for byteswapped clients. Newer part of the X server are written to do byteswapping followed by validation. Older parts do either native validation or byteswapping (which is expected to include validation), followed by processing, and it's these parts that have the security issues.
The joy of a codebase where parts date back to 1984...
Posted Jan 9, 2023 15:42 UTC (Mon)
by wtarreau (subscriber, #51152)
[Link] (13 responses)
Thinking that BE is getting dropped while the net was mostly created on it leaves me thinking quite a bit.
Posted Jan 9, 2023 16:18 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
Given that I think there are quite a few mainframe internet servers (which might well be LE), if X servers will no longer connect to them they will simply be cutting themselves off the internet.
The other thing, of course, is that the world is moving over to Wayland clients. If X servers wish to shrink their niche even further well, they're a dying breed anyway now.
(And if it speeds up the death of this archaic interpretation of "client server", that'll be a good thing too :-)
Cheers,
Posted Jan 9, 2023 21:12 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (3 responses)
All sane, widely-deployed network protocols other than X11 (whose sanity is rather debatable anyway...) have fixed endianness. Most of them standardize on big endian. In this case, it would appear that X11 is de facto standardizing on little endian instead. That's not really a problem as long as everyone agrees on one or the other. The problem, instead, is when a protocol specifies that endianness is stateful rather than fixed. The Xorg project is now taking a tentative step towards abolishing this problem, for which I applaud them. This change *is* a technical improvement over the status quo ante, because it reduces the (de facto) complexity of the protocol.
Yes, backcompat problems exist. No, they're not automatically considered blockers. *Some* projects, like Linux, require strict backcompat for their APIs or ABIs, but there is no cosmic law of the universe that says the Xorg people have to do the same.
Posted Jan 9, 2023 21:19 UTC (Mon)
by dullfire (guest, #111432)
[Link] (2 responses)
It's just saying systems with attributes A, and B, are no longer allowed to communicate. Where as previously they could.
So after this change, without overriding the defaults, some of my systems will no longer be able to communicate[1].
[1] I will of course be changing the default, but I couldn't do that on systems where I don't have root access.
Posted Jan 9, 2023 22:07 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
...send a pull request?
Posted Jan 10, 2023 17:22 UTC (Tue)
by dullfire (guest, #111432)
[Link]
I must admit that responding to someone disagreeing with a statement with: "no, you fix it some I'm right", is probably one of the most amusing rebuttals I've ever seen.
Posted Jan 9, 2023 22:35 UTC (Mon)
by marcH (subscriber, #57642)
[Link]
This change "left you thinking" but not enough to see that X11 has no defined endianness and is _already_ "leaking" endianness over the network. There would be no problem and no story otherwise.
Posted Jan 9, 2023 23:02 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
This post[1] (which is a collation of Q&A with Alan Kay) discusses how we *could* have had code slung across the network for rendering things and remote computation. It wasn't machine code, but instead a SmallTalk-like object-oriented system. PostScript is apparently a close relative of what could have been.
[1] https://donhopkins.medium.com/alan-kay-on-should-web-brow...
Posted Jan 12, 2023 19:49 UTC (Thu)
by flussence (guest, #85566)
[Link] (5 responses)
Nowadays (i.e. any GUI library introduced in the past 2 decades) everything renders client-side using OpenGL ≥ 2.0, so you're already getting opaque binary blobs in the form of prerendered pixmaps shoved over the X11 socket. Ironically that makes endianness less of an issue, because the protocol's being reduced to a dumb Unix stream of bytes.
Posted Jan 16, 2023 1:01 UTC (Mon)
by gb (subscriber, #58328)
[Link] (4 responses)
Please, have some rest with OpenGL and composition and 'everything renders opengl'.
Primary reason I am one of the people do not want OpenGL is power consumption and slowness. I want my notebook be silent while I am doing work, have longer bettering live and truly do not want any effects on my screen.
Posted Jan 16, 2023 1:38 UTC (Mon)
by pizza (subscriber, #46)
[Link]
So you gain nothing by eschewing OpenGL. Indeed you're arguably _less_ power efficient, because you're giving the CPU more work to do.
Posted Jan 16, 2023 6:14 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
To be clear, we're not talking about fancy graphical effects here - we're talking about things like "Draw a straight line" or "Move this object on-screen". If you're not doing that via OpenGL you're probably doing it on your CPU, and that's going to be slower and draw more power than doing it on the GPU would be.
Posted Jan 17, 2023 21:16 UTC (Tue)
by gb (subscriber, #58328)
[Link] (1 responses)
Another things in UI is font rendering and decoding video streams.
As i understand doing bitblt 2d model is very different to that OpenGL/Vulcan does, and one of the aspect of gl is rendering a full video frame, delay till next frame, and then draws next one.
But talking here i understand that in fact my knowledge on how it really works lucks some details which i want to know before making further comments...
The fact that you talking about OpenGL makes me very unsure that you also near being expert as GL days are over and Vulkan is much better thing ATM, and that change is very welcome, for 3d stuff.
Been very curious and now going to read how things really work =)
There seems to be very good link in 7hour video on topic mentioned here:
and i already figured out that even with composite disabled my xfce4 (which is obviously based on gtk) is not using 'blitter' engine of my intel video driver.
Posted Jan 17, 2023 23:30 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Not really. Even in the old model you have two screen buffers, where you compose your image in the inactive one and then flip it with the primary buffer. The hardware simply scans out it onto the monitor (in the olden days you could play tricks with changing data literally as it's being sent to the cathode ray tube).
Hardware blitters were not really about _moving_ data from one point to another, but about _filling_ the areas with data. It was especially useful because video buffers tend to be located on the video card RAM that is accessible through a fairly slow bus, rather than directly as host RAM.
But then you still need to draw the actual UI (text, menu bars, background images, etc.). And all this UI has to come as memory writes through the bus (which is slow). That's why 2D acceleration for stuff like drawing lines was needed.
> This in general consumes lots of electricity and processing power - on every frame.
With today's accelerators you're talking about the amount of power in milliwatts.
Posted Jan 16, 2023 0:57 UTC (Mon)
by gb (subscriber, #58328)
[Link]
But i have different question - attacks on X11? Like, seriously, anyone expose X11 to WAN?
I would say I do care about LE connecting to BE as I am working with power and sparc practically daily, but why anyone would care about 'security of X11'? isn't that something that really doesn't matter?
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
> I couldn't imagine realistic support of any kind for non-x86 architectures outside of enterprise distributions.
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
> it's only disabled by default and can be re-enabled with a command-line option
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Some display managers (including sddm and lightdm) allow custom command-line arguments to the X server to be specified in the DM's config file.
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
So this really divides the world in two distinct universes.
And if distros mitigate this interoperability problem by enabling the support by default, the attack vector stays the same.
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Niches are for dogs.
> Somehow I do not think I will be safer.
Niches are for dogs.
Hutterer: X servers no longer allow byte-swapped clients
- complexifies Wayland's code base (make it aware of that option to be able to pass it along)
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients by default
(Though there seem to be some (solvable) problems with Xwayland.)
Hutterer: X servers no longer allow byte-swapped clients by default
Hutterer: X servers no longer allow byte-swapped clients by default
Hutterer: X servers no longer allow byte-swapped clients by default
Hutterer: X servers no longer allow byte-swapped clients by default
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".
Hutterer: X servers no longer allow byte-swapped clients by default
>
> In the real world we need to take compromise between different factors, like security, availability, flexibility, productivity....
> 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".
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?
Hutterer: X servers no longer allow byte-swapped clients by default
> 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?
Hutterer: X servers no longer allow byte-swapped clients by default
Hutterer: X servers no longer allow byte-swapped clients by default
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
To be honest, I am not that acquainted with the threat models in this case, but one could assume that the vulnerabilities do not lie in the byte-swapping code itself, but deeper in the code. What does it buy us to disable the byte swapping, when an attacker could trigger bugs simply by pretending to be little endian, but sending garbage data? This is like erecting a locked gate on a field with the fence around it missing.
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
1. The SProcs code that takes care of byte-swapping messages.
2. The code that validates the contents of messages, and acts upon them.
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
From a quick glance at the remaining fbdev support code, Xorg doesn't perform any checks on the actual frame buffer layout, and treats everything like packed pixels. I guess lots of bugs (and security issues) are lurking there...
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Wol
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients
I think font rendering basically done by CPU anyway, video streams going via special api.
This in general consumes lots of electricity and processing power - on every frame.
There is no reason to render any full screen frames during normal operation of anything i could imagine i need for UI.
https://www.phoronix.com/news/XDC2016-2D-Acceleration
Hutterer: X servers no longer allow byte-swapped clients
Hutterer: X servers no longer allow byte-swapped clients